I still remember the day when our delivery manager announced that from the next phase, our project was going to be Agile. After attending some training and doing some online research, I realized that as a traditional tester, moving from a Waterfall to an Agile testing team is one of the best learning experiences to boost my career. While testing in Agile, there were certain challenges, my roles and responsibilities increased a lot, and the workplace demanded for a pace which was never seen before. Apart from helping me to learn automation tools as well as improving my domain and business knowledge, it helped me get close to the team and participate actively in product creation. Here I will be sharing everything I learned as a traditional tester moving from Waterfall to Agile.
The first thing testers learn while moving from Waterfall to Agile is the clear-cut difference between traditional testing to testing in Agile. The differences can be clearly seen in project planning, execution and the participation of the tester in the team. Let’s see the differences in details.
In the traditional software development life cycle, the main principle of the project is to release the application only after the defects have been fixed. Agile, however, deals with an iterative approach, where at every iteration, the tester has to check the quality criterion. Recently, the adoption of shift-left testing has been used to speed up the testing in Agile.
In traditional Waterfall methodology, testers work at the beginning of the project for requirement gathering, and once again at the end when development gets completed. The deadline remains fixed and if the development team extends their deadline, the testing duration gets shorter, skipping some important testing phases.
However, while testing in Agile, development and testing are incorporated in every phase. Testers work along with developers at every sprint and since it demands faster delivery, manual testing is replaced in many scenarios by automation testing.
Waterfall methodology depends a lot on the documents specifying the requirements. Acceptance testing is usually done by the stakeholders or the end users.
Agile, on the other hand, is highly dependent upon communication of everyone onboard. Acceptance criteria are defined in the user stories and thus, acceptance testing is done by the testers. Testers have to be skilled in multiple domains apart from only manual or automation testing.
The success or failure matrix of software depends on how the testing goes. If some critical defects arise, the project has no option but to go in the red zone.
In Agile, constant feedback is provided and demos are scheduled with the stakeholders, reducing the scope of any critical dependencies when the deadline gets closer.
Apart from a new work culture and learning lots of new things apart from testing, there were many other things which I found new when I moved to an Agile testing team.
In my previous projects, daily or weekly meetings were often carried out regarding goals discussion, any new changes in the team, or if the manager wanted to share any information with us. In Agile, the thing on which I was most impressed is daily standup meetings.
The thing that surprised me the most while moving from Waterfall to Agile was that the entire testing procedure was divided into 4 quadrants.
This acts as an initial safety testing procedure that checks the code quality. The testers provide instant feedback and based on that, developers continue their work. It consists of
The second quadrant is mostly business-driven. Testers get the requirement so that coding can be started without any roadblocks. Developers start their work keeping in mind the business objectives. It consists
The purpose of the third quadrant is to fulfill the objectives of Q1 and Q2. Automation testing is used for evaluation, keeping in mind the realistic usage of the product. Even though the product is unfinished, demos are scheduled to ensure that development is done based on business requirement. It includes:
This mostly includes testing the nonfunctional specifications like security, performance, etc. Testers check the expected nonfunctional qualities using this quadrant before finally delivering the finished product. It includes:
As we plan for moving from Waterfall to Agile testing, it is imperative to keep a sound strategy to help things go along in an organized manner. The Agile testing strategy usually consists of 4 stages.
During this stage, the initial setup task is completed. This includes the installation of tools, requirement analysis, and identifying the resources to perform specific tasks.
This is the most important part of the project since most of the testing procedures are executed in this phase.
The product is deployed into production. The team carries out several activities like
The product moves to the production stage where
When I worked in a project that followed the Waterfall model, testers were kind of left behind in everything. They were only involved in the project during the requirement gathering phase, before the client, delivered the final software requirement specifications. Once that was delivered, we had to analyze the requirements and contact the stakeholder or the BA in case of any doubt. They were also consulted after the completion of the development phase to test the modules and report the bugs in a QA tool.
The main disadvantage of this was improper collaboration and narrow test windows.
Testing in Agile, however, demands testers and developers to work together since the very beginning and both have to do the work of the other.
Agile development is all about developing the right product and reducing the risk associated while developing it. Changes are always welcomed and to keep the time complexity within check, testing in agile demands automation. Apart from visual regression testing and usability testing, most other testing procedures like unit testing, functionality testing are now being automated.
This leads us to learn new tools like Selenium, UFT, and Appium. The testers also have to learn CI/CD tools like GitLab, Jenkins, Codeship, and others to stay ahead in the industry. This made me realize that as I was moving from Waterfall to Agile, testing became more challenging giving me a chance to hone my skills as a tester.
For writing effective test case scenarios, especially when it comes to exploratory testing, a good Agile tester must have proper knowledge and understanding of how the domain application works. When I became part of an Agile team, I was able to work more closely with the development team. I became more familiar to development terminologies, explored and got better clarity of the architectural diagrams, and helped in create innovative business case scenarios.
For creating fewer test cases that have more coverage, testers eventually need to have a clear idea of the business logic. That requires a timely discussion with developers and business analysts, reading the specs, and playing with the application as well. Eventually, this increases not only their technical knowledge but also their knowledge of domain and business.
Apart from a willingness to learn and ready to take a deep dive into business, there were few things I needed to learn before moving from Waterfall to Agile testing.
Agile demanded speed. I could no longer afford to waste time on performing repetitive tests each day, each week, or each sprint. There was a call for pacing up the rigorous regression testing. I realized for successfully moving from Waterfall to Agile testing, I had to learn automation tools such as:
Also. unit testing and BDD testing tools like JUnit, Pytest, JBehave, Cucumber, etc.
Gone were the days when HP Quality Center was used to report and track bugs. Before moving from Waterfall to Agile testing we had to learn collaboration tools that helped in bug reporting, as well as project management like:
As the development incorporated with testing for every sprint, I realized that a website may look different from one browser to another. Testing across hundreds of browser could be very time consuming and could cost a heavy infrastructure and bandwidth.
Since the methodology is different, there were quite a lot of new things to learn and learning those and implementing them came with certain challenges for me.
In Agile, there is no specific term called testers or developers. Developers have to do partial testing and testers have to do partial development as well. Since Agile demands fast delivery, there was very little scope for manual testing. We had to learn lots of automation testing tools along with programming languages like C# or Python based on the project. Testers also had to learn using deployment and integration tools like Git, Jenkins, etc.
Faster delivery meant smaller deadlines. Each sprint and user story had a very strict deadline within which the team had to complete development, perform the required testing scenarios as well as schedule a demo with the stakeholder or the management. Even after satisfying all requirements, if the stakeholders were not satisfied, we have to take care of their concerns and fix the issues.
Agile is flexible for the stakeholder because it gave them the liberty to change the requirements if they were not satisfied with what the team delivered. However, this is, in some cases, disadvantageous for the team that is working on the product.
Let’s suppose a website is being developed and interactive navigation is created according to the requirement. However, when the demo is scheduled, the stakeholder says that it does not look good and they want a parallax-powered navigation. In that case, the development team has to spend some extra hours in creating the navigation system and the testers have to test it. Ultimately leading to waste of their previous efforts.
With multiple teams delivering various aspects, simultaneously into the project. Coordination turns out to be the key to unleashing the maximum potential out of every team. Coordination helps to push development and testing at a faster rate with better transparency among the team.
As a tester, moving from Waterfall to Agile testing could be challenging and may look a bit scary at first. However, it empowers you with immense learning. If you are testing in Agile, then each day in the work presents you lots of things to learn, scopes to suggest and implement your innovative ideas and eventually, moving ahead in the industry. Just like me, if you are new to Agile testing, don’t be scared or confused. Embrace the opportunity and learn from every opportunity. Show your skills and innovation in the project and it will help you to propel your career as a skilled manual as well as a skilled automation tester.