September, 2015

Team Work: From Waterfall Testing to Agile

Published: 10.09.2015 | 1647

It’s nice to see how your product stands out among the competitors like a rhythmic gymnast among the boodle of lawnmowers. But it’s necessary to anticipate the desires of target customers and to fine-tune the project according to them, by testing and correcting the functionality throughout the development process.


In order to have new products dancing like gymnasts at the top of their career, companies are moving from the Waterfall development and testing to Agile.

Agile is aiming more at the faster product launch and at the effectiveness of solutions provided. The strict fixation of development and testing processes, on the other hand, (which is critical for some products) is left behind.

However, people don’t like changes. Traditionally, we have everything formalized as possible – all the requirements, procedures and even responsibilities. And in some agile methodologies, the particular parts are blurred; interaction becomes more personal. If the team is accustomed to the Waterfall, the transfer might seem quite confusing. It’s especially noticeable when it comes to testing and QA.

Some companies hire specialized trainers, gurus of Agile, and others cope on their own and train the team step by step. We in Webmart QA are self-consistent, so we learned the working approaches and techniques our way. And here’s our vision on the shift from Waterfall to Agile – with steps and analysis of problems in the context of testing. Let's go!

Let's go from Waterfall to Agile!

The product development process in Agile consists from a number of cycles 1-4 week long, called iterations. Each iteration is a separate project, including planning, design, coding, testing and retrospective.

How Does It All Work:

  • Round Table

Agile development doesn’t like formalities, so the whole team takes the decisions on the project. Testers are involved in all team meetings – they sit on daily meetings, speak during the retrospective and make suggestions with alterations. Even if they work on different floors, they’re still the fulltime team members!

  • Planning

As we have said, Agile is realized in the form of iterations. For the successful completion of each cycle, the team (right, with them testers!) carefully plans a set of tasks. We believe that the test specialist’s participation in assessing the scope of works is the direct investment in the success of the project. It’s the only way to keep the testing in mind and thus to maintain the topnotch product quality.

The functionality is taken seriously. If the feature is developed, but not tested – the task can’t be closed. All team members understand it, so they thoroughly think through the iteration plan. Сollective responsibility really helps to avoid the unnecessary expanding of product’s functionality.

  • Joint Responsibility

Iteration tasks are the tasks for the whole team. Of course, the designer can hardly help the developers. But if the tester has the time, he’s ready to offer his own hands and head to the coders. And yes, this is the exact same principle as in the TDD, Test Driven Development. We’ll tell you more about this interesting practice in the following articles, so make sure you don’t miss it!

Test Driven Development practice is a creative and team way to develop software.

In turn, if the tester is swamped with work, and the end (of iteration) is near, then developers cover his back and conduct, for example, the performance testing.

But the most important is the overall end result, which appears in the effective interaction of:

  • Designer and developer (applied new look).
  • Developer and tester (stable function or new feature).
  • Developer, tester and manager (assembled stable version).
  • Product owner and project manager (relevant information, timely management of requests and requirements, feedback).
  • And to make the final product pop, it’s important to move from traditional methods of development and testing to something more flexible. Here’s our vision on the shift stages.

    Waterfall to Agile In 5 Steps:

    1. Meetings

    The first and most effective step is the implementation of daily 15-minute stand-up team meetings. The essence of the meeting is each participant reports his closed tasks and results achieved along with goals for current day. The team also discusses any difficulties arising to find a perfect solution, and the manager confirms one or another realization plans.

    Meetings are essential for the Agile testing and development

    2. Reassessment

    Then, the project manager changes the approach to the assessment of development requirements. He divides the entire project’s life cycle on 1-4 week iterations, which are filled with the appropriate tasks for the successful release of the final product. The mandatory tasks are implementation of the requirements, testing, stabilization, demonstration/retrospective and release. Planning each iteration effectively requires high skills from both the project manager and development /testing leads.

    3. Defectology

    Now we’re changing the system of tracking the tasks and errors. Each requirement or task is assigned to a specific version of the product, build, program and app. The team is involved in the planning of the timing and scope of work. That makes a big change in the task and bug tracking along with the team informing process.

    4. Roles

    It’s time to edit the individual responsibility for the team results. Assign each activity to the one main doer. One of the main criteria of efficiency is when you don’t have the situation of overloading one person with responsibility while underloading other. Therefore, the project manager will have to learn how to juggle people and tasks.

    5. Documentation.

    In accordance with the iteration plans, all the requirements, alterations, tests and debugging sessions are also planned in conjunction with the product version (or the particular iteration).

    Use the light form of documentation

    After completing this series of steps, you will be able to have a flexible approach to planning, volume and timing of the issuance of business-critical results of the whole team. If we talk about outsourcing, the end customer will be very happy to see how his product turns into a real artistic gymnast. However, since the difference between the two methodologies is huge, the team might encounter certain difficulties.

    Waterfall to Agile Shift Problems:

    • Documentation Amnesia.

    The fact that the Waterfall development is actually based on all kinds of documents is a common knowledge. However, Agile also requires the standards, templates, test plans and test cases!

    That’s a huge part of the work on quality assurance (QA), and we don’t advise to ignore it. The standards help bringing the processes, requirements and criteria to a common ground. Just use the documents in the lighter form, then you won’t get that feeling like, “we sort of working in Agile, but here’s a bunch of papers again”. You don’t need a lot of docs, try to summarize your meetings and each iteration in writing – this will help to determine the direction in which you go and compare it with your goals.

    Create the team-accessible documents on the cloud drive or with tools like OneNote and organize the whole team to participate in the task and bug tracking. In addition, make sure you use the one single system for all the workflow processes, including the incorporation of requirements.

    • Cyclic Testing.

    Waterfall implements the testing phase right before the launch. Before it began, testers may not have a clue about the functionality and purpose of the created software. However, Agile includes testing in every iteration. It helps going into all the details and immersing in the project. But testers need to get used to it. While there is nothing to check yet, the specialists study the requirements, write the test cases and develop the auto tests.

    Automation is very important in Agile, because the short time intervals require frequent testing. We recommend spending some time on creation of new and modernization of existing tests during each iteration. Then each new build along with all the features is tested for survivability. Testing is an ongoing process here.

    And no one tries to put new features and functions in the build 2 days before the end of the iteration. This gives enough time to test the product version, so the project owner will see only the working prototype on the last day of the iteration.

    • Lack of Discipline.

    Joint responsibility, unfortunately, doesn’t always lead to a common discipline. And we think that it is important for the entire Agile team to sit down and think out the DOD parameter – Definition of Done. This will determine the task’s percentage of completion. Herewith, every occasion and every team has its own unique DODs!

    As for testing, you can determine the readiness, for example, like this:

    For the Task:

    • Main points are covered with auto tests
    • Tests are passed

    For the Function:

    • Acceptance auto tests are ready
    • Non-automated tests are added to the checklist
    • The feature has a Validated status

    Testing team is happy about the task Validation

    For the Iteration:

    • Build passed the testing and didn’t crash
    • The project owner liked the build on the demonstration
    • Required features are added
    • All documentation is approved

    And so on. Pointing out again, this is just an example. The whole point of DOD and its purpose is to discipline your team, so the each member agrees with the readiness criteria and applies them to his workflow. Thus, collective responsibility will be on the highest level.

    Turns out, the shift from Waterfall to Agile is unlikely an easy path, it takes a lot of communication, conflict resolving skills and strong mutual responsibility feel. However, it all pays off handsomely, as:

    1. The product will continue to evolve and you will receive the successfully implemented functionality every 2-4 weeks.

    2. You can control the amount of work, increasing and decreasing the task scope, planned for the version.

    3. The project team will not become a few competing departments, it will form a big happy family, focused on common objectives within the iteration and the entire project life cycle.

    4. Testers will constantly work with the project, thus actually provide and control its quality.

    5. Accordingly, the product’s quality won’t put the end user to a standstill.

    6. Your software will be used, bought and advised to friends.

    7. PROFIT!

    Share your experience in the comments. Did you change the testing model, how did it go, were there any problems, slowing down the development of new products, and how you dealt with them? We’ll also join this discussion ;)