Testing strategy for agile projects updated

Editor's Notes

1. Prepare a SQA plan for a project - Participate in the development of the project’s software process description - Review engineering activities to verify compliance with the defined process - Audits designated software work products to verify compliance the defined process - Ensure the deviations in software work and products according to a documented procedure - Records any noncompliance and reports to senior management
2. A product is tested so that it can be judged for 1. completeness 2. fitness for purpose 3. risks
3. UAT tests at the user story level Core agile practices - CI - Test environment - Manage technical debt  technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice - working incrementally - make coding and testing part of one process - synergy between pratices
4. The quadrants are merely a taxonomy to help teams plan their testing and make sure they have all the resources they need to accomplish it. There are no hard and fast rules about what goes in what quadrant. Think through them as you do your release, theme, and iteration planning, so your whole team starts out by thinking about testing first. Most projects would start with Q2 tests, because those are where you get the examples that turn into specifications and tests that drive coding, along with prototypes and the like. However, I have worked on projects where we started out with performance testing (which is in Q4) on a spike of the architecture, because that was the most important criterion for the feature. If your customers are uncertain about their requirements, you might even do a spike and start with exploratory testing (Q3). Q3 and Q4 testing pretty much require that some code be written and deployable, but most teams iterate through the quadrants rapidly, working in small increments. Write a test for some small chunk of a feature, write the code, once the test is passing, perhaps automate more tests for it, do exploratory testing on it, do security or load testing on it, whatever, then add the next small chunk and go through the whole process again.
5. Test plan- helps to identify possible issues and dependencies, to bring risks to be talked about and to be addressed and to think about the big picture. Story sizing- sometimes testing wasn’t include in estimates of story size. Sometimes testing a piece of functionality will take longer than coding it. To identify ripple effect and to uncover hidden stories with in a story.
6. To achieve Definition of done. We have to make sure that each story is tested. Peer reviewed. Review stories from the customer and tester perspective with programmer. Look for mismatches Before the start of testing, the development team’s detailed design documents must be approved so that test case creation can start. Both coding and testing are performed incrementally and iteratively in Sprints (or iterations
7. Test automation - need to reduce repetitive work of the tester so that more time can be spent doing exploratory testing. - need to identify repetitive tasks - identify tools, - skills
8. Lowest tier made up of robust unit and component tests which are technology-facing tests that supports the team (TDD) has the biggest ROI. Other types of tech-facing tests such as performance testis may also be at unit level Middle tier includes most of the automated business-facing tests that supports the team. These are functional tests. These tests operate at the API level. Top tier represent the smallest automation effort and provides lowest ROI. They operate on presentation layer. They are much more brittle
9. Test strategy document can be used to give new employees a high level understanding of how your test processes work. Keeping the agile nature in mind, we have identified areas that we can incorporate QA activities.
10. Measuring progress- you need an idea how much work is left and whether some stories cannot be completed on time. Go for different plans as needed. Defect metrics- track what type of bugs are popping up and their root cause. Whether they could have been captured in unit test level so that training on writing unit tests. Misunderstood requirements, not enough time for iteration planning or UAT test cases are not detailed enough.
11. Whole team- team committed, daily collaborate, testers get support, get right people Agile mindset- what can we do to help deliver software successfully?, apply agile principles and values, continually improve, not the quality police , be proactive, take resposibilty Automation- drive development with tests (unit tests), design for testability Feedback- team uses feedback to improve, testers are expert feedback providers, feedback makes course correction, do reprospectives Core agile practices - CI - Test environment - Manage technical debt - working incrementally - make coding and testing part of one process - synergy between practices Customer collaboration – ask questions, work with customer to understand the true needs, identify risks so customer can make best decisions