“I recently attended the XP Conference in Edinburgh, UK, and wanted to share some of the insights and ideas I learned there. The conference was well worth attending.”
In a world where developers are encouraged to own the end-to-end process (development, testing & deployment), is there still a place for the traditional manual QA? In short, no.
Until recently, it was common practice for the QA team to be separate from the development team and have a heavy focus on manual testing. The QA’s were seen as “the ambulance at the bottom of the cliff”, or the team that would highlight all the problems with the software at the last minute; QA’s were seen as bottlenecks. In this Waterfall environment, projects could take months or even years to go Live and the smallest change will lead to a cobweb of change management requests and arguments over whether something is a “feature” or a defect.
Nowadays, lengthy projects are considered dinosaurs of the industry. Thanks in part to teams no longer being separated by discipline and the focus on automation, we now live in a world where companies such as Amazon deploy code multiple times a day; companies now live and die on their speed-to-market. Whenever Apple launch their latest iPhone, every major seller will have all the details on their site within hours and it would be unthinkable to wait days or even weeks to release the information due to a slow Software Delivery Lifecycle. The idea of reducing cycle times and deploying into production frequently is called Continuous Delivery (CD).
So how does a company decrease their cycle time? A good starting point could be to remove silos, helping teams become autonomous and empowered to make decisions. Teams no longer have specialists but instead everyone is a “jack of all trades”; developers that can build code, test and deploy to production. This is also known as DevOps, and coupled with Continuous Integration (CI), mean that cycle time can be drastically reduced compared to more traditional methods of delivery.
CI is the practice where developers commit their code into a shared repository and automated tests are run to see if that change has broken anything, and only if all tests pass then the code is merged. There is commonly also a large automation set of regression tests that are run before any code is deployed into Production. However, the aim is to reduce testing time to as little as possible, the CI tests should take minutes at most and the complete regression shouldn’t take more than an hour.
We want to decrease our cycle time, we want to test just enough or, in other words, do “minimum viable testing” with the key word being “viable”. We must still be covering the key functionality, things that the business cannot take the risk of not working correctly, but we shouldn’t do exhaustive testing of every feature. Traditionally these tests were run manually, which did not give the speed or repeatability that is required in the modern market. This results in the requirement of test automation.
But who automates these tests? Typically, the CI tests (mainly unit and integration level) are automated by the developers, and the regression tests (mainly end-to-end and UI driven) are automated by the QA team. However, there has been an increasing trend towards developers automating these, striving to become more cross-functional, reduce bottlenecks and cycle time.
So if the developers are automating all of the CI and regression tests, why bother having QA’s? I’m glad you asked! QA’s do have a future in technology, just not in the traditional sense of doing manual, end-of-the-line testing. There are many ways that a QA can stay relevant in this shifting market. QA’s should be working closely with the developers and in the same notion of pair-programming, could start doing “pair-testing” in order to write automated tests with the developers.
The goal of a QA should be ensuring that quality is built in from the beginning, encouraging practices such as Test Driven Development. A tester’s mind-set is very different to a developer’s, which often allows a QA to identify problem areas more easily. QA’s should be training developers to think outside the box and ensure that they’re thinking of different scenarios while they’re developing. In theory, this should mean that fewer bugs are developed, making the whole SDLC faster and more efficient.
With QA’s having a reduced workload due to developers taking on additional responsibility, QA’s can start to focus more on areas of testing other than just ensuring the system is functioning correctly. QA’s should be shifting focus onto non-functional testing such as performance and security, as well as real usability testing and facilitate crowd or beta testing to prove that you are building the right thing, and not just building the wrong thing correctly.
There is and probably always will be the need for exploratory testing in-house too, which requires a QA’s mind, but again this should be kept to “minimum viable testing”. QA’s should also look into the analytics behind what’s being developed, such as what browsers or device customers are using and then ensure that testing and development targets this. This is an area often forgotten during development that can result in poor usability if not given adequate attention. There are countless ways of improving the quality of a system, these example are just a few, and this is where a QA can truly bring value to the SDLC, improving quality, increasing efficiency and reducing cycle time.
So to answer the question, is there a place for QA’s in a world where cycle time is everything? The notion of a QA in the traditional sense is going away, and the survival of QA depends on changing and adapting their way of working to stay relevant and ensure they are providing value. Training developers to think like a QA, improving testing practices, pushing ahead with non-functional testing and striving to improve quality and efficiency wherever possible will help to ensure that the role of a QA continues to be relevant. However, there are also other opportunities for QA’s to diversify (as many developers are doing) by taking on dual roles, such as Scrum Master or Business Analyst, and the knowledge gained in working as QA can lend itself particularly well in these areas. The role of a traditional manual tester will likely go the way of the typewriter; but not a single business out there can honestly say that their software is perfect, and as long as that continues to be the case, there will always be the need for QA.
