I still remember the day when our delivery manager announced that from the next phase, the project is going to be Agile. After attending some training and doing some online research, I realized that as a traditional tester, moving from Waterfall to agile testing team is one of the best learning experience to boost my career. Testing in Agile, there were certain challenges, my roles and responsibilities increased a lot, 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.
How Testing In Agile Is Different From Traditional Testing?
The first thing testers learn while moving from Waterfall to Agile project, is the clear-cut difference between traditional testing & 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.
Basic Ideology
In the traditional software development life cycle, the main principle of the project is to release the application only after the defects has 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 evident to speed up the testing in Agile.
How the Process Works?
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 in case of development team extends their deadline, the testing duration gets shorter, skipping some important testing phases.
However, while testing In Agile, development & 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.
How The Team Works?
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 he communication across everyone onboard in the project. 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. Here are top 17 skills of highly effective software testers.
How The Software Release Becomes A Success?
The success or failure matrix of software depends on how the testing goes. If in any case, 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.
What I found Out When I Started Testing In Agile?
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.
Daily Standup Meetings
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.
- A standup meeting usually takes place for 15 to 30 minute every morning.
- The duration varies based on team size.
- Each team member is asked 3 questions
- What did you do on the previous day?
- What will you do on the current day?
- Are there any roadblocks blocking your deliverables?
- Participates include the entire team, including the stakeholder and the scrum master.
- The main objective of the meeting is to get a clarity of the entire team’s progress as well as to eliminate any hurdles.
- To resolve any hurdles, the scrum master must take responsibility. If it is outside his scope, he should ensure that someone else must take responsibility.
Testing Procedure Was Divided Into 4 Quadrants
The thing that surprised me the most while moving from Waterfall to Agile was that the entire testing procedure was divided into 4 quadrants.
Quadrant 1
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
- Unit testing to check whether a piece of code satisfies the requirement.
- Testing of component architecture to ensure that they work when combined together.
Quadrant 2
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
- User experience testing of the wireframe or prototype.
- Testing the examples of workflows and possible scenarios.
Quadrant 3
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
- Collaborative testing
- User acceptance testing
- Exploratory testing
- Usability testing
- Pairwise testing including the stakeholders or customers.
Quadrant 4
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
- Testing the infrastructure and data migration
- Testing load and scalability
- Testing the infrastructure
- Performance and stress testing
- Security testing for ensuring authentication and preventive measures for hacking.
Strategizing Is Key For Testing In Agile
As we plan for moving from Waterfall to agile testing, it is imperative to keep a sound strategy to help things go ahead in an organized manner. The Agile testing strategy usually consists of 4 stages.
Iteration 0
During this stage, the initial setup task is completed. This includes installation of tools, requirement analysis and identifying the resources to perform specific tasks.
- A business case is established
- Requirements are analyzed and use cases are created.
- Risks analysis is concluded
- A preliminary project is prepared after calculating the cost estimation.
Development Phase
This is the most important part of the project since most of the testing procedures are executed in this phase.
- In each sprint, the team implements Agile modeling, Scrum, Agile data and other Agile practices.
- Requirements are sorted according to priority and the team executes the most prioritized testing in each sprint.
- Testing is done in 2 phases. Developer testing which is done by the developers once they finish coding. They verify service integration testing and unit testing. Agile acceptance testing is carried out by the testers.
- In Agile acceptance testing, not only the testing team of the project but also testing team from the stakeholders execute the test cases together.
Product Deployment
The product is deployed into production. The team carries out several activities like
- Training the end users
- Back up the data
- Marketing the release
- Documentation of the finalized user and system document.
Production Support
The product moves to the production stage where
- Regular testing is carried out in case there is an addition of any new module.
- In case of any bug or user queries, the issue is handled by the production support team.
Becoming A Part Of The SDLC From The Beginning Is Integral For Testing In Agile
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
- 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.
- After the completion of the development phase. We had to test the modules and report the bugs in a QA tool.
The main disadvantage of this was improper collaboration & narrow test windows.
- There was no collaboration or proper communication among developers and testers. Testers were some guys whose job was to find errors in the hard work done by the developers.
- Testers were not given any proper time frame. If the development team extended their deadline, testers had to reduce theirs and skip some important testing phases.
Testing in Agile, however, demands testers and developers to work together since the very beginning and both have to do partial work of one another.
Step Up With Automation To Speed Up Testing In Agile
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, Appium etc. 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.
Better Understanding Of The Business Logic
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 development team. I became more familiar to development terminologies, explored and get better clarity of the architectural diagrams as well as help in creating 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 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.
Prerequisites Before Moving From Waterfall To Agile Testing
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.
Automation Tools
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
- Selenium WebDriver – The ultimate, open-source test automation tool for minimizing challenges of automated website testing.
- HP UFT – For performing functional testing
- Appium – For testing Mobile applications
Also. unit testing and BDD testing tools like JUnit, Pytest, JBehave, Cucumber, etc.
Project Management Tools
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 top collaboration tools that help in bug reporting as well as project management like
- Slack
- JIRA
- Mantis
Cross Browser Testing Is Pivotal For Handling Browser Differences
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.
However, there are cloud-based browser compatibility testing tools like LambdaTest using which you can perform your testing across 2000+ real browsers running on various devices. LambdaTest also offers Selenium based automation testing through their on-cloud Selenium Grid to help you maximize your test coverage of your application across hundreds of browser-device-OS combinations.
Challenges Which I Faced During Agile Testing
Well, 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
Learning The Programming Languages & Development Procedure
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.
Small Deadline
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.
Frequent Changes in Requirement
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 case, 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.
Seamless Coordination
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.
Conclusion
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.
Published on Java Code Geeks with permission by Arnab Roy Chowdhury, partner at our JCG program. See the original article here: What I Learned While Moving From Waterfall To Agile Testing? Opinions expressed by Java Code Geeks contributors are their own. |
