Everything You Should Know About QA Role in Agile Process - All in One Blog !!!
Skills Should Agile Tester Adopt
Role of QA Tester in Agile Process
Yesterday, you had to wait for the business analysts to finish the requirements phase before you could start building your test plan in detail and ensure that you had full coverage and traceability for all the requirements.
Today, things are different. Rather than waiting for the business analysts to finish their work and hand it off to you, you're part of the process of defining user stories, adding them to the backlog, and helping the team define the criteria that must be met for each story to be considered "done."
As an agile tester, you'll help estimate the scope and size of the testing effort for each user story. The estimated effort for testing is part of the overall estimation for the size of the user story, which can't be marked as "done" until it passes all the tests. After each sprint, your team will review and update the estimates of upcoming user stories based on the team's experience from the previous sprint and re-plan upcoming sprints based on the new estimates, which should be improving over time.
You'll be involved in the design of the software by working closely with developers to assess and advise on testability aspects. You'll also be looking at concerns such as whether software testing can be automated, whether components can be tested independently from the rest of the package, and how much information is written to the log files.
On an agile project, everyone on the team plays a role in testing. Each team member might have their own specialty, but everyone is responsible for delivering the team's user stories at the end of the sprint. The team will be writing functional, performance, and automated unit tests, as well as creating scripts to automatically deploy code into test environments and execute the tests. As a tester on the team, you'll be helping to design and execute automated and manual tests, including exploratory testing. As testing is infused throughout the development process, you'll become involved in testing at the component and API level, as well as at the end-to-end and feature level. You'll also be testing those nonfunctional requirements teams sometimes refer to as the "ilities": security, reliability, maintainability, scalability, usability, and so on.
In an agile development environment, there are frequent small-functionality increments at the end of each sprint, which means the software is continually changing. The frequency of change makes the speed of regression testing incredibly important, because the code should be tested every time a change is committed. This means you need to automate your tests as much as possible—manual testing simply takes too long. Look for opportunities to automate tests and deployment scripts and develop test automation frameworks for your team and the rest of the agile release train.
You'll be working more closely with developers than ever before. If you find a defect, tell the developer, and let them use your system to debug so they can find and fix the problem as quickly as possible. Don't force them to set up their own system. You're working together on the same code and user story, with the same goal of providing working software at the end of the sprint.
OK. This doesn't sound new. Yesterday, you were working on verifying fixes, too. But these fixes might have been made weeks or months ago, and you could only test them when a formal build was delivered to QA. In agile though, the aim is to fix and verify bugs within the same sprint, because otherwise the tests won't pass, and the user story can't be considered "done.
Attend daily stand-up meetings
It's important to attend and contribute to the daily stand-up meetings. To be really effective, don't just talk about what you accomplished yesterday and what you're going to be doing today. The most important part of a daily stand-up meeting is sharing the obstacles that will prevent you from making progress as a tester on the team.
Yesterday, when you were part of a QA team, you followed metrics that were important to your organization, such as the status of requirements, number of reopened defects, etc. Today, you'll be looking at a new set of metrics that you'll need to track as part of an agile organization, such as sprint burndown, velocity, and release burndown.
Yes, you're allowed to fail. That's OK.
You could even say it's your responsibility to fail once in a while, but only as long as you fail fast and learn from your failures. In traditional development, failure is not only discouraged but also often punished. In agile, failure is accepted, and the lessons learned from failures are shared with the team. Support from management to accommodate failure is critical to the success of agile in the enterprise.
Today, you get to try out the second principle behind the Agile Manifesto: welcome change. Just moving to agile itself is a big change, but now that you're agile, you must be prepared not only to expect change but also to deal with it. In a traditional setting, a disruption during development can jeopardize the whole project. But in agile, any user stories that meet the "done" criteria are good to go. Because constantly grooming and reassessing the backlog is part of the agile concept, the team can accommodate and accept disruptions. The only major casualty of a disruption in agile should be the current sprint, but because you aim for short sprints, there are only a couple of weeks' work at stake.
You've always had to keep up with the product you're testing and the technologies you're encountering, as well as the testing itself. But now that you're in an agile organization, you'll need to learn about agile itself, including what is and isn't working for you. Make the changes you need, and keep reassessing whether they're working or if they need to be refined or removed.
Conclusion of Blog on QA Tester in Agile
Agile organizations may encounter some test-related organizational risks:
Skills Should Agile Tester Adopt
- Be positive and solution-oriented with team members and stakeholders
- Display critical, quality-oriented, thinking about the product
- Actively acquire information from stakeholders (rather than relying entirely on written specifications)
- Accurately evaluate and report test results, test progress, and product quality
- Work effectively to define testable user stories, especially acceptance criteria, with customer representatives and stakeholders
- Collaborate within the team, working in pairs with programmers and other team members
- Respond to change quickly, including changing, adding, or improving test cases
- Plan and organise their own work
Role of QA Tester in Agile Process
Help define "done"
Yesterday, you had to wait for the business analysts to finish the requirements phase before you could start building your test plan in detail and ensure that you had full coverage and traceability for all the requirements.
Today, things are different. Rather than waiting for the business analysts to finish their work and hand it off to you, you're part of the process of defining user stories, adding them to the backlog, and helping the team define the criteria that must be met for each story to be considered "done."
Scope and Estimate
As an agile tester, you'll help estimate the scope and size of the testing effort for each user story. The estimated effort for testing is part of the overall estimation for the size of the user story, which can't be marked as "done" until it passes all the tests. After each sprint, your team will review and update the estimates of upcoming user stories based on the team's experience from the previous sprint and re-plan upcoming sprints based on the new estimates, which should be improving over time.
Assess testability
You'll be involved in the design of the software by working closely with developers to assess and advise on testability aspects. You'll also be looking at concerns such as whether software testing can be automated, whether components can be tested independently from the rest of the package, and how much information is written to the log files.
Design and Execute Test cases
On an agile project, everyone on the team plays a role in testing. Each team member might have their own specialty, but everyone is responsible for delivering the team's user stories at the end of the sprint. The team will be writing functional, performance, and automated unit tests, as well as creating scripts to automatically deploy code into test environments and execute the tests. As a tester on the team, you'll be helping to design and execute automated and manual tests, including exploratory testing. As testing is infused throughout the development process, you'll become involved in testing at the component and API level, as well as at the end-to-end and feature level. You'll also be testing those nonfunctional requirements teams sometimes refer to as the "ilities": security, reliability, maintainability, scalability, usability, and so on.
Automate
In an agile development environment, there are frequent small-functionality increments at the end of each sprint, which means the software is continually changing. The frequency of change makes the speed of regression testing incredibly important, because the code should be tested every time a change is committed. This means you need to automate your tests as much as possible—manual testing simply takes too long. Look for opportunities to automate tests and deployment scripts and develop test automation frameworks for your team and the rest of the agile release train.
Collaborate
You'll be working more closely with developers than ever before. If you find a defect, tell the developer, and let them use your system to debug so they can find and fix the problem as quickly as possible. Don't force them to set up their own system. You're working together on the same code and user story, with the same goal of providing working software at the end of the sprint.
Verify fixes
OK. This doesn't sound new. Yesterday, you were working on verifying fixes, too. But these fixes might have been made weeks or months ago, and you could only test them when a formal build was delivered to QA. In agile though, the aim is to fix and verify bugs within the same sprint, because otherwise the tests won't pass, and the user story can't be considered "done.
Attend daily stand-up meetings
It's important to attend and contribute to the daily stand-up meetings. To be really effective, don't just talk about what you accomplished yesterday and what you're going to be doing today. The most important part of a daily stand-up meeting is sharing the obstacles that will prevent you from making progress as a tester on the team.
Track different metrics
Yesterday, when you were part of a QA team, you followed metrics that were important to your organization, such as the status of requirements, number of reopened defects, etc. Today, you'll be looking at a new set of metrics that you'll need to track as part of an agile organization, such as sprint burndown, velocity, and release burndown.
Fail
Yes, you're allowed to fail. That's OK.
You could even say it's your responsibility to fail once in a while, but only as long as you fail fast and learn from your failures. In traditional development, failure is not only discouraged but also often punished. In agile, failure is accepted, and the lessons learned from failures are shared with the team. Support from management to accommodate failure is critical to the success of agile in the enterprise.
Embrace change
Today, you get to try out the second principle behind the Agile Manifesto: welcome change. Just moving to agile itself is a big change, but now that you're agile, you must be prepared not only to expect change but also to deal with it. In a traditional setting, a disruption during development can jeopardize the whole project. But in agile, any user stories that meet the "done" criteria are good to go. Because constantly grooming and reassessing the backlog is part of the agile concept, the team can accommodate and accept disruptions. The only major casualty of a disruption in agile should be the current sprint, but because you aim for short sprints, there are only a couple of weeks' work at stake.
Learn
You've always had to keep up with the product you're testing and the technologies you're encountering, as well as the testing itself. But now that you're in an agile organization, you'll need to learn about agile itself, including what is and isn't working for you. Make the changes you need, and keep reassessing whether they're working or if they need to be refined or removed.
Conclusion of Blog on QA Tester in Agile
- Understanding, implementing, and updating the Agile Test Strategy
- Work with Product Owners to define Acceptance Criteria and the Definition of Done.
- Measuring and reporting test coverage across all applicable coverage dimensions
- Ensuring proper use of testing tools
- Configuring, using, and managing test environments and test data
- Writing and executing automated checks and reporting back to the team
- Reporting defects and working with the team to resolve them
- Coaching other team members in relevant aspects of testing
- Ensuring the appropriate testing tasks are scheduled during release and iteration planning
- Actively collaborating with developers and business stakeholders to clarify requirements, especially in terms of testability, consistency, and completeness
- Participating proactively in daily standup meetings, story grooming sessions, team retrospectives, suggesting and implementing improvements
- Within an Agile team, each team member is responsible for product quality and plays a role in performing test-related tasks.
Agile organizations may encounter some test-related organizational risks:
- Testers work so closely to developers that they lose the appropriate tester mindset
- Testers become tolerant of or silent about inefficient, ineffective, or low-quality practices within the team
- Testers cannot keep pace with the incoming changes in time-constrained iterations
No comments:
Post a Comment