Evolution of QA
The way software is written has changed a lot over time. Not only because the hardware or the expectations of the consumers demanded it, but also the spirit has changed. Agile is the keyword of our time. The days are gone, where software is nearly finished before seeing its first dedicated tester. Naturally, testing had to develop, too.
These changes made it necessary to include testers more in the development process and therefore in the development team. It is not very practicable anymore to have this separate testing center or group with a release coming up every two weeks. Also project managers or even clients will quickly find themselves not being able to hold up with this fast development cycle anymore, trying to test stuff themselves. Often developers were misused as testers. And while of course every developer should test their code, whenever you work concentrated on a task, you will start developing tunnel vision at some point. So a fresh pair of eyes is always better to double check. It also cuts away development time and will in the long term extend the time till release. Especially if you consider that continued development also raises the risk of breaking already released features. To prevent this, regression testing is a fundamental necessity.
A dedicated software tester brings a lot of benefits to a development team. New features are tested right after development. Hence, if something isn’t working as expected, the developer can work on it right away, while still in the flow of these new features or fixes. Tester and developer have a short communication way and eliminate ambiguities very fast. The QA engineer is also responsible for checking that all the new features and fixes play well together in the delivered product by performing a manual test of the new features from a user’s perspective.
So instead of getting a nearly ready product and test based on the documentation, which we all know can vary in quality, testers now work with the same tickets developers are working with, and are fully integrated into the feature context of the development team. This way they have the same acceptance criteria documented like the developers to check against. Developers already create automated tests for their features and fixes. But those tests are mostly written from a technical perspective and check in depth whether the feature is working; sometimes at paths in the code an end user cannot reach. Besides checking for the expected functionality to work, the QA tester also checks the connections to other features and tries to provoke errors that haven’t been covered yet, by applying an end-user perspective without knowing in detail how the underlying code actually implements the feature. At this point the integration of a dedicated tester into the development team can really shine, as at this state destructive testing is much easier than when the product is nearly finished. Testing for edge cases and loopholes often makes the difference between a dedicated tester and a project manager or developer forced to test besides their actual tasks.
When we finally reach a new release it is time for regression testing. This field has probably benefited the most from the involvement in testing software over the last years. When confronted with software testing in the past, a lot of people thought it is just a bit of button clicking which does not need a lot of skill. But with the rise of automation tools with fancy UI implementations and dashboards, automatic test scripting became alive for people not so deeply involved in the code. Being able to code automatic tests that produce meaningful reports outside the terminal environment got a lot of attention. When releasing a new feature, automatic tests can quickly check if old functionality still works as expected. A high test coverage is now a quality factor not to be underestimated.
With apps and websites getting more and more complex and the need to be accessible for a wide range of devices, automated tests grow in importance. The possibilities to simulate user behavior and different environments are growing constantly, so does the knowledge testers need to have. It is now clearly more than clicking a few buttons. To set up a working automation framework and writing tests that deal with API endpoints, user authentication, dynamic data input and on top different browsers, viewpoints and devices is nothing you do on the side. With all these tools and the growing complexity of automated testing, it is as easy to write bad automated test code as it is to write bad code that goes into production. Nowadays testers are developers responsible for maintaining the quality of complex acceptance test suites that need to grow constantly at the same rate as the production code grows when new features are added. Testers also need to have the product architecture in mind and sometimes deal with complex architectural challenges of testing different services together, testing third party integrations, or testing asynchronous event based architectures.
It should also be clear that writing tests is not a one time job. As long as the software gets developed you need to add new tests or adjust existing ones. And even if the development has ended, testing will not. New updates for operating systems, depencies or browsers can break existing features. Ideally you want to find those bugs before your customers do.
Maybe because test automation has a high complexity and needs people with experience in software development and software architecture, or because fully manual testing seems to be “the usual way”, many companies still go down that road of manual button clicking and including testers late in the process. This road might lead to the assumption that almost anyone could act as a tester, which might be true for the simple cases and would still need an enormous amount of people as the product grows, but is not sufficient for complex cases or even automation.
I read a lot that testers don’t feel appreciated and are more like second class people behind developers or project managers. Personally I can not confirm that. At WTL, the QA is an important part of the development process, working closely with product management and developers. Team members are glad they have a dedicated tester, which gives them more confidence in their work too. In our teams developers usually write unit and integration tests when working on a task. QA employees implement acceptance tests of the whole product and test the new implementations against the acceptance criteria of a certain ticket. Developers in the team still have access to these acceptance tests, are able to read and review them, and touch these tests in some cases too.
Before a deployment, we run our automatic regression tests in a dedicated test environment to validate the success of the deployment. Before each release, we also run manual tests. Both manual and automated test results are collected in TestRail, a testing management software. QA and developers are working together to raise the test coverage of the product, so our clients can present high quality software to their customers.
