Testing has always been the poor relative in the systems development life cycle (SDLC), waiting at the back of the project queue, begging for handouts of time and budget. Many test managers has found themselves in conflict with the project manager and stakeholders because they insisted on rigorous testing throughout the life cycle, starting with requirements and unit testing through to user acceptance. No internal IT business unit or external dedicated development company will commit to this. They will claim that they apply a framework like the "V-method" or "W-method" as part of their testing regime; but in reality, testing is rarely given the attention it deserves.
In traditional "waterfall" IT projects, when the project runs out of time, the first phase of the application development life cycle (ALC)/SDLC to suffer is testing. The project manager will appropriate a few days from the time allotted for system testing or user acceptance testing and reallocate them to the design or build a component that is falling behind. This is aggravated by the sequential process. The development activity is completed before its quality assurance, that is the testing, is done.
The ramifications of skimping on testing are severe and long-term. An application with defects as a result of inadequate testing will miss the target of meeting customer expectations throughout its life. After all, a year from project end date, no one cares whether the project was on time or ran a bit late; however, faulty or inadequate features are a constant irritant and very difficult to correct once the application is in production.
The rise of rapid application development (RAD), extreme programming (XP) and many other forms of agile development have changed all that. There are several reasons for this, but those in the list below are some critical success factors:
- The product to be delivered must be as lean as possible while still functioning according to specifications.
- The customer must be involved in and committed to the project.
- Small work packets are developed iteratively and individually quality assured during the project, rather than a monolithic product that is complex and time-consuming to write and test. This favors parallel development with multiple teams.
- Acceptance criteria are clearly defined and no software is "done" until it has passed all the criteria.
- There are several forms of "quality-driven development" processes, such as "test-driven development" (TDD), where the test framework is developed before the code, ensuring that the testing is comprehensive.
Each and all of these practices have accelerated both delivery and quality of software products executed using the agile methodology. Agile development uses a proactive approach to testing, rather than the retrospective approach, especially where TDD is used.
The Lean Product
The introduction of the "Lean Startup" method for entrepreneurs brought with it the concept of a "Minimum Viable Product" (MVP). The proposed product is trimmed of all frills and "nice-to-haves," resulting in a plain but functional design that will require the minimum of development before going into production. The removal of complexity reduces time to deliver and risk of failure.
Customer Collaboration
In 2001, seventeen software specialists gathered together to pen the "Agile Manifesto," which encompassed four values and 12 principles. One of the Values was customer collaboration, which was expanded upon in the Principles. The expectation was that the customer would be intimately involved in every aspect of the development cycle, thus both assuring buy-in and no deviation from customer expectations.
Continuous Delivery: Celebrating Small Successes
While the process of software delivery varies depending on the agile approach used, the focus is on delivering features swiftly and often. For instance, in Scrum, work is packaged into "sprints," usually efforts of two to four weeks that produce one or more features which are then presented to the customers for approval. What's more, the most critical features are given the highest priority and are delivered first. This approach allows the team to start their next sprint knowing that the previous sprint is "done." This type of development calls for regression testing as each new feature is added or a sprint is completed.
The Product is Working Software
The delivery of working software (i.e. free from defect and matching specifications) is defined as the "primary measure of progress" in Principle seven of the manifesto. This is confirmed via very comprehensive acceptance criteria, which are defined ahead of the development when the requirements are gathered. This is done at a granular level: in scrum, as each "user story" (the smallest possible user specification) has at least one criterion to be met.
Test-Driven Development (TDD)
There are several variants of TDD, such as BDD (Behavior-Driven Development) and ATDD (Acceptance-Test-Driven Development). Essentially, they all emphasize designing and framing the tests prior to starting development. The team should envisage what the final product should look like and how it should behave. This is translated into a test framework, which is then executed without code, guaranteeing a fail. The code is then developed and run through the framework until the job executes without a fault. Test automation is used where possible, but the team's understanding of what should be delivered is the biggest benefit from this approach. An insightful interview with Lisa Crispin discusses the need for team collaboration on building the testing framework and illustrates how the theory is applied in an agile project.
Quality Delivery via Thorough Testing
The emphasis that agile development places on testing over coding results in an efficient, bug-free code that is aligned with the original specifications. When this is combined with test automation, applications are delivered in record time and conforming to the Manifesto description of "valuable software."
The integration of testing into each agile iteration also fosters close collaboration between testers and developers. Even when they are geographically separate, the relationship is cooperative. The days of developers "throwing the work over the wall" to be tested are gone. Even where a traditional "waterfall" project is chosen, the principles of test-driven development can still be applied to improve the quality of delivery.
Photo credit: Shutterstock / Rawpixel.com