Software development is a moving target. In the continual push towards faster time-to-market, it sometimes seems that every 5 minutes there is a new acronym or portmanteau to learn about and adopt.....
These shiny new methodologies and techniques promise to hold ‘the key’ to what your business needs – faster time-to-market, quick turnaround on new features and additions, all without compromising on the quality that your customers expect/demand - and sometimes they make good on that promise (but that’s a conversation for another time!).
What this rapid pace of change does mean, however, is that roles are changing and the subject of this blog is how the role of Quality Assurance is adapting to keep up with the modern world of software development.
Testing is not the same as quality assurance
There is a traditional (read ‘old-school’) view of QA where the QA Analysts read a spec or user story, write a test script, run or execute that script and, if required, raise a bug report. All worthy tasks I’m sure you would agree; however, it is a slight injustice to say that this is all the job involves. Modern QA Analysts need to have a much more diverse skill-set than they did even 5 years ago. The sought-after technical skills such as functional test skills, non-functional, security, performance, accessibility etc are still required but also the people skills; the ability to elicit, analyse and critique business requirements are now becoming just as important.
The perceived misalignment between modern software development methodologies (read DevOps for example) and Quality Assurance come from this often not being recognised in the industry. As the software development methodologies have become increasingly user-focussed, so has the role of QA changed to not just define and judge quality based on the quality of code, but also on whether it is fit for the customer’s purpose. For a product or solution to satisfy, quality principles need to be baked in to the process from the start, regularly reviewed and reported on and, importantly, be a shared responsibility of the whole team. It’s about not just checking that the team has built the product correctly, but have they built the correct product? It’s perfectly possible for a system to be bug free and yet not solve the problem the business needs it to.
If the business desires the quicker turnaround and faster time-to-market whilst maintaining (or even improving) quality, the traditional “design it, build it, test it, ship it” needs to be reimagined. More than ever, QA has a role to play at every stage:
Planning, Discovery and Requirements Gathering – During the course of the project, QA Analysts take the role of the client or customer and become their voice. There is no reason why this should be constrained to a testing phase of the project. The earlier feedback on these issues can be given, the easier (and less-costly) they can be fixed. It will help shape the product how the client wants it from the outset. In addition, QA can help identify woolly or vague requirements or specifications helping to prevent rework to be required further down the line. This is where QA can help ensure the right product is built to solve your business problem.
Build – Test early, test often. As above, the quicker issues are raised the better. Even if bug numbers are low, is the product on track to meet the business goals? QA can help development by setting scope and coverage of unit tests and help with any ad hoc implementation decisions that are made in-build. QA System Testing will provide project stakeholders with key information on project status and quality, identify risks to the project and help show any areas that may be of concern.
User Acceptance and Systems Adoption – This is where the customers/users of the system first get their hands on the product. This can be daunting for the members involved, especially if the system is brand new and they are not from a technical background. As QA have been using the system from their point of view, QA are uniquely placed to help with the following:
- Understanding and setting the aims and objectives for User Acceptance phases
- Planning UAT (User Acceptance Testing) including allocation of resources
- Prioritising work
- Highlighting areas that should be focused on when testing
- Defining the sign-off criteria
- Providing a full handover and training on the new product or functionality.
As you can see from the above, utilising the QA skillset more thoroughly can help relieve pressure on other members of the project team, help achieve the project goals and lead to greater customer satisfaction throughout the process.
Automation is (sort of) not testing
Let me say from the outset that automation is good. I and probably most QA’s find it a useful tool, but a tool it is nonetheless. It is a means to an end, not the end itself. As the software development industry has leapt headfirst into Agile and DevOps methodologies automation has come sharply into focus and any job spec you read for QA, Software Tester or variation thereof is likely to list it as a desirable skill.
In the rush to automate everything, I believe a couple of key points have been forgotten:
Automation ‘checks’ but doesn’t ‘test’ – Automation will rarely if ever tell you something you don’t already know about the behaviour of the system. Automation relies on the QA Analyst telling a computer that ‘if you do this, then this happens’, no deviation, it’s on a set of rails and it either comes to a stop (fail) or gets to the end of the track (pass). To identify the bugs that are really tricky to find and therefore more likely to get through to production, a little skill and creativity is needed and that comes in the form of an experienced
QA team analysing the software and judging where the bugs are likely to be and how to find them. Note: AI based test automation may change this -stay tuned!
Automate ‘most’ but rarely ‘all’ – I’ve yet to work on a project where it has made sense to automate everything that I have tested. The overhead in creating and then maintaining the automated tests really doesn’t make sense for tests you’re going to run less than, say, 10 times. However, if you can automate as much as possible and as a bare minimum cover the key journeys and pieces of business logic contained within your application you are going to be in a strong position if this is done early in a project, especially if these tests can be integrated with your CI/CD (Continuous Integration/Continuous Delivery) pipeline.
QA Analysts should be working with developers and business analysts to define what the key journeys and functionality of the application are, whether they can be candidates for automation and working towards a situation where immediate feedback on these areas can be given as part of a build and deployment process. Any automation in addition to this is a bonus, but it should not be done for the sake of it – it may be more efficient to not automate a particular test or check. Projects should still include time for QA to get their hands dirty with the product and perform manual testing to find those as-yet undiscovered bugs and provide meaningful feedback on qualitative aspects of the system and to make sure that the application makes sense for the user.
These concepts aren’t particularly new, however QA or test teams that are not geared up for change and ready to adapt may find that their ways of working begin to hinder the development process and QA becomes a bottle-neck in a fast-paced development environment. Overall, I believe that the Redweb QA team are well placed to continue to play a key part in the development process at Redweb and by extension, QA or test teams across the industry can ensure they contribute equally in their own organisations and make sure they are not left behind in the rapidly changing world of software development.