Our top five software testing and Quality Assurance practices
Our senior QA Analyst, Sakina Abedi, describes our approach to testing and Quality Assurance.
There are various software test and quality assurance practices. At Symbiote we tailor a combination of these to suit the web development services we offer our clients across various projects in order to improve the quality of products that we ship during each project lifecycle.
Here are five concepts we keep in mind when it comes to software testing and quality assurance:
Quality is everyone’s responsibility
Testers are vital and irreplaceable within a team. They facilitate best practices across the entire project lifecycle in order to achieve high quality results.
We need to let go of the common misconception that only the testers are responsible for quality, and that testing is done only during the testing phase by the testers.
Everyone in a project contributes towards quality since we recognise that every team member brings a unique set of skills and has exposure to various best practices in the software industry. Anyone can introduce a best practice as long as they can discuss why it is important and how its adoption will improve the quality of the software that we deliver.
Introduction of best practices requires time and effort. Once we have the starting point of what the best practice is and why it is important, the entire team comes together to discuss and flesh out the specific steps to be carried out, overcoming any challenges encountered, distributing the deliverables across the relevant members of the team and the implementation itself.
Different roles play significant parts in actualising the best practice from an idea to implementation. An example would be the approval from management to subscribe to, or access, a new tool or software.
When everyone takes ownership of the quality that we deliver, we can work together to improve it. Every person contributing towards a project with their piece of work can ensure that the requirements specified for that piece of work have been met, all the relevant types of tests have been written and executed and any test evidence can be attached to reflect the same.
2. Consolidate Ways of Working (WoW)
We understand that every team member working on a new project will have a slightly different perspective on what the ways of working should look like.
Hence, at the beginning of each project, it is a great idea to establish the ways of working in collaboration with the clients.
This could include the following:
what the various meetings involved would be, their agenda and schedule
what the structure of the tickets looks like in the project management tool like Jira, what the board looks like, the various swim-lanes and how the tickets will be navigated across the various swim-lanes
the location and structure of the documentation captured in tools like Confluence
how the team(s) will collaborate and communicate etc
the structure of requirements
the location and structure of test results, the structure of reports and so on.
It is about having clarity about everything involved in the project, so that when the project unfolds, everyone is on the same page and the quality of the work that we deliver reflects consistency, rather than trying to figure things out when we’re already under the pump.
Next comes clarity of requirements. It is about thinking from the end users’ perspective, implementation perspective, testing perspective and so on. It is about not hesitating to ask questions, and clarifying ambiguities.
Another crucial part is facilitating visibility for everyone involved in the project. Once there is clarity, providing constant visibility becomes a lot smoother.
We need to encourage open communication and then ensure any changes made to the requirements are updated, when applicable.
3. Test each piece of functionality in isolation
This is also known as feature branch testing.
The main goal is to test each piece of functionality before the code is merged to the main branch.
The flow looks like this:
The requirements are shared by the client
The piece of functionality is built
The code review step passes
Now, instead of merging the code to the main branch, the owning developer deploys the code to an isolated testing environment and then assigns it to the tester for testing
The code is merged once testing passes
If testing fails, the test results are shared with the owning developer as early feedback instead of being logged as a defect
The dev then makes the fixes and re-deploys the same branch to the test environment for retesting.
When this has been achieved successfully, the order of development can be based on priority to make the most of this practice. This ensures that the most critical features are built and tested first.
This best practice also reduces the bottleneck during the testing phase since each piece of functionality can be tested as soon as it is ready, rather than having to wait for multiple pieces of functionality to be deployed to the test environment at once.
When regressions have been discovered, this best practice reduces the ambiguity about which piece of functionality has introduced it.
Under the exceptional circumstances that one or two pieces of functionality fail testing very close to the release and could potentially push back the expected release date, we have the option to hold back just those pieces of functionality from being deployed, instead of holding back the entire release.
4. Make the most of automation testing
We can harness the power of automation testing by:
Utilising the automation testing suite, to be executed as early as possible, ideally on the CI/CD pipeline in order to find out if any regressions have been introduced even before manual testing begins. This also means not having to wait until the final deployment on the pre-prod environment.
Executing the automation suite as frequently as possible, at least every time the code change has been deployed for manual testing.
Doing an impact analysis ahead of time, of the tests that might be affected by the changes being introduced and being prepared to fix them as soon as possible, rather than towards the release date, when we are already under the pump.
Improving test coverage by getting as many team members involved in automation testing, in collaboration with the testers, so that the testing mindset and context is preserved.
Automation testing has best practices of its own, quite different to those followed during development. You might like to read this Insight I wrote for more context: Best practices for the automation of integration testing.
When these best practices are implemented, we can make the automation suite more powerful and reliable.
5. Remember that implementation of best practices is a journey, not a destination
Once we have implemented a few best practices, it is not the end of the story. It is an ongoing effort.
Regular retrospective meetings are a great opportunity to introduce new best practices, discuss or even discontinue something that doesn’t work for us. This allows the implementation of the newly introduced best practice(s) to kick off soon after the meeting wraps up, whenever practical.
The testers, and other team members can make an ongoing effort to be actively involved in the tech community by attending meetups, conferences, workshops and similar events, as it will help them remain aware of the trending best practices, tools and skills in the market.
6. Bonus best practice – be proactive
Each team member recognises that we’re all working towards a common goal.
Team members can ask each other about where a particular task is at, when we can expect it to be ready for testing, or when testing is likely to finish, and so on.
Whenever anything looks ambiguous, after making an effort to figure it out, we all feel comfortable to be proactive – not hesitating to ask for help, to ask questions and clarify, rather than making assumptions.
“Teamwork makes the dream work” – John C. Maxwell
