Our top 5 software testing and quality assurance practices

"A problem well stated is half solved.” – Charles Kettering

There are various software test and quality assurance best 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 our top 5 software testing and quality assurance best practices:

1. Quality is everyone’s responsibility

While testers are vital and irreplaceable within a team, their role extends to facilitate best practices across the entire project lifecycle in order to achieve high quality.

This is about letting 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 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 its 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. Consolidation of 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 ways of working in collaboration with 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 all 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. Testing 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 retest.

When this has been achieved successfully, the order of development can be based on priority in order 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 have failed testing very close to the release and can potentially cause pushback on 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. Making 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. I have written a blog here for more context. When these best practices are implemented, we can make the automation suite more powerful and reliable.

5. 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, and 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 such as meetups, conferences, workshops and similar events, as it will help them become aware of the trending best practices, tools and skills in the market.

6. Bonus best practice – Proactiveness

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 being proactive, not hesitating to ask for help, to ask questions and clarify, rather than going by assumptions.

“Teamwork makes the dream work” – John C. Maxwell