Why ‘testing’ might be holding back the quality of your software
Testing or Software QA, has traditionally been the last piece of the software delivery puzzle. Testing and finding bugs at the end of a release cycle was the norm. However, fixing those defects, changing designs and redeveloping the features lead to more work done twice, more time spent on retesting and loads of regression. So, this approach meant testing held you back from your final goal of software quality assurance.
Being the last phase of the development process and mostly being stretched for time and resources, testing has been seen as a hold up for final delivery to market.
With the advent of Agile and DevOps the thought process has changed and the focus now continues to be more on software quality assurance throughout the development lifecycle. Testers today need to focus more on assuring quality than finding bugs.If testing prevents you from delivering on time and you become a bottleneck at the end of a release, you need to focus your efforts on other quality assurance activities, which may or may not be a 100% testing but are surely related to overall quality of your software.
In my article for PractiTest QA Learning Centre, I talk about how to overcome this. https://www.practitest.com/qa-learningcenter/thank-you/software-quality-assurance-bottleneck/
Training Developers how to test their code better
We rely on testers to test the software, which mostly happens post development. Even if we have a process around unit testing the code, developers generally write very basic unit level tests to touch upon the code, mostly just enough to meet the coverage criteria set for them.
If we train our developers to think beyond the basics and write more unit tests, it will exercise the code in various new ways and catch more potential defects earlier. A more exhaustive unit test suite will also reduce reliance on black box functional tests, and reduce regression loads at the end.
Also, beyond unit testing, we can train our developers to run some functional tests when executing the code before packaging and sharing for testing. For this, we can get assistance from the testers to share their basic test scenarios with the entire team.
Everyone in the team is responsible for quality, and hence everyone including developers, BA and Scrum Master can ensure that the basic test scenarios never fail and hence a basic level of quality is forever maintained.
Reviews as checkpoints
To ensure a benchmark of quality is achieved at software delivery, we must set up some quality assurance practices related to everything we do within the development lifecycle. To ensure these practices are followed, we must also enforce some process, tool or exit criteria for them. Some examples can be –
- Every developer needs to get their code reviewed by their peer or senior developer in the team. So, for each feature or user story development task, we have a corresponding code review task, assigned to the reviewer developer and blocking an hour of his time for it.
- The test cases that a tester creates for any feature must be reviewed by the entire team. So, testers create their tests early and share it across with the entire team. If any feedback, suggestions or changes come their way, they accommodate it even before beginning to test. But if no responses come in, it is assumed that tests are as expected and then no conflicts will arise later on how the feature was tested.
- Testers need to be included in all requirement and design discussions. For this, we ensure that all meeting invites are sent to the entire team and testers are encouraged to focus more on activities like design reviews, requirement analysis and giving more inputs in those phases, so that the numbers of defects found, decrease over time.
By enforcing these practices, we are setting up more checkpoints along the way of our software creation rather than having a big blocked gate at the end in form of a testing phase.
Customer Focus Groups
Though companies mostly have a customer support team to respond to customer issues or production server problems, it would be beneficial to set up a core customer focus group within the development team. Including a few developers and testers along with the BA, this core focus group can keep track of all inputs that come from the customers including issues, suggestions or queries about new features. These can be great insights for the team to keep the focus on the real user’s needs and see their perspective.
The focus group can also:
- Keep an eye on the production data and set up similar ones for internal tests
- Keep a count of support tickets and try to help close them quickly
- Monitor the servers and keep track of error messages received
At regular intervals, this focus group can publish their findings and observations in relation to the customer’s responses and help the entire development process get more aligned towards reaching maximum customer satisfaction.
Change in team’s Mindset
We need to train our testers to think beyond defects, test case counts, and coverage measures.
Focusing solely on executing tests at the end of the development phase is not the way to achieve quality and provide real value to the team. The focus should not be “finding bugs” but “assuring quality”.
For this, we must encourage testers to work in pairs with the developers on their assigned features or user stories. The team must not have a developer – tester divide. Instead, they must have a collective ownership for the success of their feature/ user story/ sprint or release.
To set up such software quality assurance practices, we also need the correct tool support. Here are a few features and practices to look for in any Software QA tool:
- End to end traceability of requirements, user stories, their designs, tests and corresponding defects
- Functionality to encourage testers to go beyond scripted tests and focus also on Exploratory Testing. This also exposes any defects earlier and hence reduces the cost of defect fixing in the long run.
- Generate informative and professional visibility via dashboards and reports to share with the team and stakeholders. Try to share the relevant data to each stakeholder.
And most importantly, we must always select a tool which is easy to integrate within our ecosystem and hence can transmit information and work with all various tools we have set up in our development lifecycle.
If you feel testing is holding you back from right time deliveries and turning your team into a bottleneck at the end of the release, you need to focus your efforts more on quality assurance activities that are related to the overall quality of your software – and less on the actual execution of your tests. Hope the tips shared here will help out you and your team achieve the quality levels we dream of!
Thanks for reading!