Working on a Project as the only Software Tester: The Journey and Lessons
Earlier this month, my team launched version 1.0 of our customer-facing app after about eight months of active development. The app is designed to help customers remotely control and monitor their alternative energy sources on their mobile devices. The app was developed for both Android and iOS users using Flutter.
My team comprises of Backend developers, Platform engineers, Flutter developers, a Product owner and myself as the QA engineer. Due to the purpose for which the app was being built, I had to go beyond testing the mobile application functionality. API testing and end-to-end testing was carried out to test integrations from the firmware, APIs and all the way to the mobile app.
The period of development involved having weekly ‘Refinement meetings’, a couple of ‘Polish weeks’ and a few demo sessions. The refinement meeting involved discussing and triaging new features and improvements slated to be implemented during the week. Dependencies needed, acceptance criteria and potential blockers were discussed during this refinement meeting. Occasionally, a week was dedicated to focus on team-wide cleanup efforts e.g, software or infrastructure upgrade/maintenance, code quality improvements etc. This was what we referred to as Polish week.
These efforts were put in place to ensure the quality of the product through standard processes.
Lessons Learned being the only QA Engineer
- No Script, More Bugs: After every six-eight weeks of development on the app, I took time out to do general exploratory tests looking for more bugs. This was done in addition to the testing efforts during sprints. During such times, I attempted to break the app without using any prepared test case. I tried as many scenarios that came to mind, observing the outcomes closely while recording and investigating scenarios where things seemed unclear. This way, conducting periodic exploratory/unscripted tests helped uncover more bugs. It was a very deliberate attempt which was very productive.
- Sharing is Caring, Sharing is knowing! On a few occasions, I was required to explain a bit of the technical intricacies of the system to both technical and non-technical colleagues. I recall having to refer to the technical documentation for the first time because I was unable to answer a colleague’s question exhaustively. It was a pointer that I probably didn’t understand it well enough. By the third time, I did better at explaining. I would intentionally attempt to explain new concepts so I can better understand them. Sharing knowledge about technical architecture with someone is a great way to test and ultimately perfect one’s understanding of the system.
- Also, sharing knowledge about how the app works with the non-members of the software team is a great opportunity to get new ideas. Valuable information such as thinking patterns of potential users, clarity about wrong assumptions and salient details missed out are brought to one’s attention. I recall how we got a better alternative to our current customer onboarding setup while I was only explaining to a seat-mate about the work done so far.
- Developers, my BFFs: I learnt early that attempting to attain high product quality all alone was an impossible feat. Collaborating with our developers during testing was one of the best initiatives I took. In many ways, they helped in providing suggestions on test strategies, especially for backend improvements. On different occasions, they helped prepare test environments, investigated bugs and unexpected behaviour and suggested improvements. Some might say that these should ordinarily be done by developers but what if they don’t? I chose to see their kind gestures and was always thankful for it. Our developers were truly an asset throughout the journey. This was a confirmation to this popular quote “No one can whistle a symphony. It takes a whole orchestra to play it.” — H.E. Luccock
- Learn to laugh over ‘spilt milk’ quickly: It wasn’t always a bed of roses. Expectations were high and the workload was heavy. The fact that both the Android and iOS apps were built at the same time was a bit challenging. I had to re-run tests separately for each platform especially for push notifications and other in-app actions that may behave differently in both Operating Systems. There were also times things didn’t go as planned. I learned that it was more beneficial to be quick to identify these problems and their causes and solve them promptly while learning from them.
- Choosing my battles wisely: It is good as a QA engineer to always insist on certain standards when testing the functionality of the app. But it is wise to know when to draw the line on things you won’t compromise on and focus more attention on these than focusing on everything. Irregularities that do not affect the flow of the product, performance or usability of the app should have lower priority than bugs that are showstoppers. This way, everyone’s effort (and not just yours) is focused on the important things and your team members appreciate your contribution all the time. Our customer app had a demo mode only visible on the Staging environment. There was an instance that I discovered a button was displayed within this demo mode which should only be present in the Live mode. I chose to assign such bug a very low priority and focus on other constructive bugs because the demo mode is only seen by the development team.
- Avoiding testing complicated features on Fridays: Honestly, this is not a rule of thumb or law in Software Testing but a decision I personally made from my experience so far. I preferred to update documentation, raise bug tickets and do bug fix verification or confirmation on Fridays. Don’t get me wrong. Testing new features on Fridays are not wrong. I only deliberately chose not to test intricate features that require a lot of patience, critical thinking and investigation etc on Fridays. This is simply because everyone was always eagerly looking forward to starting the weekend. Anything worth doing was worth doing well and so I preferred to give my best especially for such complicated features.
So far, I have received much positive feedback about the app but it was not a piece of cake. I had to be proactive and take ownership of many things. I applied my experience from my previous team in championing similar tasks. I was also open to receiving bug reports and suggestions from other colleagues outside the team.
I couldn’t have achieved a quality app singlehandedly without the support of my colleagues and I am really glad to have been part of this journey. These lessons are invaluable and I would recommend you try them out. Happy testing!
This article was originally taken from familonitomi.com
