How To Be An Active Tester?
Working in software development as a tester, it can be difficult to find time to improve the testing process when you are the bottleneck to release with lots of tickets, stories or features to test. I am currently a QA Lead at Cera Care, one of the fastest growing healthcare startups in Europe. Working in this fast moving environment is very challenging for my team, where features are prioritised over anything else and teams have up to 6 developers to 1 QA engineer.
As you can imagine this does not allow much time for activities outside of feature testing. Quality is compromised as the feature will be described as a minimal viable product (MVP). Improvements are added to the backlog to be implemented after the initial pilots or user feedback.
Before being able to tackle the quality technical debt another priority comes along meaning there is no time to revisit the feature. What has this got to do with being an active tester you might ask? Well, that’s where the testing role within my team has changed to more of an advisor and involves collaborating closely with developers, product, user experience (UX) and data.
Tester stereotype by Markus Spiske
How to break down the traditional testers stereotype
Only a short while ago, I had a conversation with a startup founder who I explained the difference between checking and testing in relation to the value a tester can provide to the development process. With a strong product knowledge and an inquisitive mindset to explore the inner workings of a system.
The tester can get involved in conversations at the beginning of the development process. In my current organisation that starts with user research to discover what the current challenges are that the user is facing. At this stage the tester can sit in on the user research sessions or read the results that are published on dovetail.
This insight is invaluable for the testers to understand how the user would interact with the feature once it has been developed. They can form realistic scenarios when they come to explore the system and run their testing tours.
Being proactive instead of reactive in testing
Building on the participation of the tester in the user experience research phase. Sometimes you need help from other people and teams to enable your productivity. Such as investigating ways to make parts of the system easier to test with developers. Or finding data to improve your test data set with the data analysts.
This can be a frustrating process of waiting for others’ time and delaying hands-on testing activities. This is where testers, by becoming an advisor, advocate or coach (however you want to describe it) can be very valuable.
Collaborating with the product team to make user stories clearer and easier to implement. Refining those acceptance criteria and improving the definition of done for development to include testing, monitoring and release documentation. This frees up testers time to concentrate on activities which refine the testing focus, increase the quality of the test data or open up almost impossible areas to test.
Getting involved in development discussions
Whether you consider yourself a technical or non-technical person (what the word technical means in terms of testing is another blog article). You can always get involved in developer discussions such as “technical refinements” (also called whiteboarding sessions).
Raising questions around testability and consistency across API specifications for example is really important to improve the quality of the application. Also at the code review stage of development, a tester can ask the developer to walk them through the feature and the tests they’ve implemented. Identify edge cases and discover any cases which aren’t covered by the automated checks. Understanding the test coverage and where to focus your testing can help identify issues quicker.
Working with data to understand user funnels
One of the most powerful collaborations a tester can make in my opinion is working with the data team. Whether that be looking at user funnels or considering data requirements in the development process. Analysing data in customer data tools like segment can help you identify the most important parts of the system for your users. Also the aim of analysing production data is to validate test scenarios and possibly identify new scenarios.
Walking through the user funnels with data analysts can help understand what the data is saying. Statistics was never my strong point, despite studying it at A Level (UK college exams) and taking statistics modules at university in my psychology degree (You can read more about my journey on my blog). The data team also provides the bridge between the business and application data. For example in my organisation, reports provided by the data team are crucial for finance to pay employees on time.
In this example, the data engineers extract and transform the data from the application databases. Meaning the data platform has no direct dependencies on the application itself, only the data in the database. This can lead to data issues downstream without any breaking changes within the application. See the diagram below to explain the complexities of what I described.
Tester participation is often a 2 way process
Tester participation is a two way communication. With all the teams involved that I described above it can feel like as a tester you are the one always asking for people to help you out. However, it’s very much a two way street, later down the line everyone will appreciate your pestering and constant asking of questions. Working closely with these teams you can develop an understanding for each representative’s specific interests in the application, enabling you to understand and speak their language.
Putting in the effort to build these relationships and understand the team’s challenges will influence the quality of the product. Though it may seem very one sided. There are many situations where the tester will be called upon as well such as reproducing live issues from product owners, developers asking testers to create some test data, UX clarifying whether the designs are still up-to-date or data analysts requesting a dump of pre-production environment to run through their data pipeline.
To wrap things up, testers pop up everywhere within the software development lifecycle (SDLC). Being curious is a key asset of the tester within the engineering function. Asking questions is another core skill to encourage conversations and discover unknown information. By participating in all the activities described here, a tester can discover interesting insights previously never discovered.
By collaborating with people across the engineering function, a tester can improve their communication with technical and non-technical people. Proactively exploring information from multiple sources helps to paint a clearer picture of the whole software development process and beyond.