What is Quality Assurance (QA)?
There’s a common perception that people in Quality Assurance (QA) are out to break things. While that is one part of it, it’s not the aim. The aim is to find things before users get a chance to. I often say “I don’t break things; I just point at the things that are already broken!”.
Attention to detail is therefore a big part of the process, and a lot of organisation is involved too. There are of course many different types of testing: functional, integration, unit, system, automated etc., but it’s usually only in really large institutions that these disciplines will be fully separated. In the majority of cases QA people will need to be adaptable, carrying out whichever type of testing is needed. It’s difficult to have a dedicated, locked-down QA strategy that you use for every project and every client.
What does QA test?
Ideally, QA should be involved in every stage of the development process. This isn’t always possible given time and resource constraints but it’s a good goal to aim for.
This starts with looking at the documentation at the beginning of a project, including technical specifications, user stories and wireframes, making sure they’re complete enough to use as a test reference later on. Once development starts, try to test every aspect of the product. This could be the verification of new features or something much more specific, such as the connection to the database and rounds of data migration checking. Usually though, it’s anything & everything.
We can also test any documents produced at the end of a project for the user, whether this is online help, manuals, or FAQs. And of course the site should be tested again once it’s live, to see how a user will experience it in a more general sense.
It’s always crucial to use your own common sense when testing and remember to look at the product from a user’s perspective, seeing not only what makes sense to you but also what drives you mad.
QA & Agile
It’s obviously important to test individual parts of the system in isolation, which we do alongside developer unit testing and, at Box UK, with heavy involvement from our Developers-in-Test. It’s also essential however that these smaller components are tested within their larger parts, and then again within the whole system, to ensure you’ve checked the product as a whole before it’s released.
This is where Agile can really support the QA process. QA has many similarities to Agile – the process of reporting bugs, getting a new version, regressing those bugs to check they’re fixed and then finding new bugs is cyclical. Any new code can potentially spawn new bugs, with one fix producing two somewhere else for example, so you have to have a process that can be easily repeated. Agile helps to make this process more formal for the whole project team and important bug fixes can be scheduled into an upcoming sprint. In a non-Agile process, a bug might not be looked at for several weeks.
Oiling the machine
The continuous cycle of the QA process can oil the machine and help keep the project moving, making it really important to have QA as involved as possible at every stage of a project. It really is vital to collect as much information as you can and this requires that you have a good relationship with everyone in the team. Anything you can do to lower the walls between departments is a good thing, and at Box UK our QA Engineers work closely with Project Managers, Account Managers, Product Managers, Business Analysts, UX Consultants, Developers and more to enable this process.
Each project team also has its own dedicated tester who sits within the team itself. However, while this does greatly help ensure a good working relationship, it doesn’t guarantee project success and must be supplemented by quality communication within the team. A big part of being good at QA is finding the right way to describe bugs so that the Product Manager, Business Analyst and Developers can look at a ticket, know immediately what you’re talking about, and be able to reproduce it easily and resolve the issue.
This goes right down to the ways things are referred to and even spelled; this may seem unimportant, but it’s vital to be able to find an issue quickly in the database, and the longer the project goes on the more important it becomes. I will often ask developers how they refer to things; it may be a “feature”, a “widget” or something else entirely, but by building up a shared vocabulary we can keep things consistent for greater efficiency and precision.
Conclusion
People often confuse QA with “Q&A”, in that they leave it to the QA team to be the expert on the whole system. While we may eventually end up with an in-depth understanding of the requirements and functionality of a product, if we’re the only ones who know the entire system end-to-end it’s probably the sign of a bad project. Instead, QA activities should be integrated into the process from the very beginning, with regular, clear communication that ensures everyone has a full picture of the project’s progress and that all work remains aligned to the client’s objectives and vision, to ultimately produce higher quality end products that meet the demands of both the business and the user.
At Box UK we have a strong team of bespoke software consultants with more than two decades of bespoke software development and software testing experience. If you’re interested in finding out more about how we can help you, contact us on +44 (0)20 7439 1900 or email info@boxuk.com.
