Guest Post by Andrei Hardzeyeu
We’ve recently discussed a realistic QA process and its importance for any IT project. However, one point went uncovered: how the QA process works in Agile and Waterfall, the two basic development methodologies.
As HP online survey of IT professionals (2017) says, Agile covers 91% of IT projects for a wide range of industries, and Waterfall with 9% coverage is mainly used in projects for regulated industries with the requirements strictly defined from the project onset. So let’s dive in and explore QA in both of them.
QA in Agile: specifics, key quality risks and a risk management strategy
From the QA perspective, an Agile iteration seems like a smaller version of a complete project. A project team follows regular SDLC stages for delivering the iteration functionality.QA specialists revise the project requirements to nip the possible sources of rework in the bud. Developers study the available requirements, write code and pass it on to testers. Testers plan to test according to the existing requirements, prepare test
cases and execute them. Then submit bugs to developers and test the bug fixes. Meanwhile, the PM monitors the project process. If everything works well, the team delivers functional software at the end of each iteration.In Agile, the exact project result is not known until the final iteration, as the project requirements may change significantly from iteration to iteration. So, the first-iteration delivery may have very little in common with the final product. This means that the scope of rework may be large, which lays the ground for the two quality risks we describe.
Risk 1: Growing technical debt
Agile projects are often commended for swift deliveries of a functional product. However, from the point of view of QA in Agile, the reverse side of speedy deliveries is the incremental growth of technical debt, which reaches a spectacular scale in relatively long Agile projects. This happens due to the use of so-called ‘crutches’, or temporary code improvements, instead of deep refactoring. Project teams often resort to the ‘crutches’ to provide speedy deliveries. Though they plan to replace them as soon as possible, new iterations bring new tasks. So the ‘crutches’ add-on till the whole construction breaks requiring complete redevelopment and retesting. This inevitably increases the time and efforts needed to deliver a fully functional product again. Growing technical debt also paves the way for the 2nd Agile project risk – quality worsening.
Risk 2: Quality worsening
The number of iterations in an Agile project is high (20+), and so is the number of the scope changes. In initial iterations, these changes are not too difficult to manage, but as software develops, the range of changes and their effect on the adjacent application areas increases. In case the recent changes break the already existing functionality, quality regression happens.
With the two quality risks from above, Agile teams seem to be in a deadlock. However, a proper risk management strategy makes the Agile quality risks addressable. Below we discuss this strategy in detail.
QA best practices in Agile: Risk management
Luckily, QA in Agile has a powerful quality gatekeeper that provides for assessing the quality of a particular stage of SDLC. It is regression testing or, better say, an adequate approach to regression testing.
There are two basic approaches to regression testing in Agile projects:
Two-level manual testing that breaks regression testing into two cycles:
# Iteration regression that centers on changes made during iteration and on the application areas adjacent to those changes.
# Major regression that features a complete regression test suite. This type of regression testing is to be run before major releases.
This approach helps to improve the quality of interim releases and save testing time and efforts in major releases. Nevertheless, project teams rarely go for it and stick to short regression testing sessions within iterations. They prefer to avoid major regression testing often associated with postponed releases.
Regression test automation:
It’s a reasonable technique that reduces time and effort spent on this type of testing. However, there’s a trap here. Going for time and effort reduction, PMs often believe that automation will also reduce the price of testing. In fact, it’s just the other way round: automation is a rather pricey effort. However, it is still possible to make automated regression testing efficient and worth every cent. Here are some points to keep in mind:
$ Feasibility: Automation may be impractical in the following cases:
# Short-term projects: Regression testing automation makes sense when the cumulative cost of manual regression testing exceeds the cost of regression test automation. This is mostly the case in long-term projects (over 1 year).
# Application instability: In case the application functionality is still changeable, automating regression testing will only result in the increased time needed for testing, which in its turn may cause missed deadlines.
$ Maintenance efforts: An automated regression test suite has its expiry date, so testers should regularly review it to remove outdated scripts and add the ones that reflect the current functionality. Besides, the same script can be rewritten many times due to the changes in UI.
$ Limited use: While test automation works perfectly for functional regression testing, UX regression testing can’t be automated.
As a rule, testing teams combine both manual and automated approaches to regression testing. The exact combination fully depends on the project nature and specifics.
QA in Waterfall: specifics, key quality risks and a risk management strategy
Unlike in Agile, in Waterfall, project teams know the project outcome in advance. The QA process in Waterfall looks as follows.
QA specialists start with documentation testing. As the requirements in Waterfall don’t change when accepted, this is the only opportunity to sort out inconsistencies or errors and minimize quality risks. When it comes to testing as such, testers work with already revised and bug-free documentation and the ready-to-use code-freeze software. This change-free approach significantly reduces technical debt. In Waterfall, technical debt equals a serious flaw in the architecture or the code that requires complete rework, expensive and tiresome. As a result, such mistakes are uncommon as project teams check and double-check everything before implementation.
However, Waterfall projects aren’t immune to overall quality deterioration either. The main quality risk in this rigorous methodology boils down to generating additional bugs in the process of bug fixing. This brings us back to regression testing as a key measure to secure the product quality. In this case, regression testing involves retesting the previously buggy application areas and the adjacent points. A good QA process helps efficiently organize regression testing and gradually lower the number of regression bugs so that the end product fully meets customer requirements.
No methodology is bullet-proof and fault-free, so quality risks are always there. In Agile, they include growing technical debt and quality deterioration. In Waterfall, these particular risks are considerably lower due to the rigid character of the methodology and its immunity to spontaneous changes. However, Waterfall has a quality risk of its own: a lengthy testing–bug fixing–retesting cycle. To address the quality risks, both Agile and Waterfall teams need to develop a good QA process that provides for effective risk management. QA best practices in Agile and Waterfall involve adopting a suitable approach to regression testing as a key quality goalkeeper helping to fight quality deficiencies.
Meta: We look into quality risks in Agile and Waterfall and offer risk management tactics to address demand create a mature QA process.
About the Author: Andrei Hardzeyeu is Senior QA Consultant at ScienceSoft headquartered in McKinney, Texas. Andrei has 10+ years of experience. Working in large Agile and waterfall projects, Andrei has demonstrated the ability to invent and establish the process according to the project specifics.
Contact the Author: Twitter: @hardzeyeu