Testing strategy for agile projects updated
•Download as PPTX, PDF•
3 likes•2,464 views
Done for company interns . an updated from previous version
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (18)
Similar to Testing strategy for agile projects updated
Similar to Testing strategy for agile projects updated (20)
More from Tharinda Liyanage
Recently uploaded
Recently uploaded (20)
Testing strategy for agile projects updated
- 1. QA & Quality Planning for Agile projects
- 2. Agenda • About QA/Testing • Some terminology • Traditional testing practices • Formulating a test strategy for the project • Iteration metrics • Success factors for quality in agile projects
- 3. What is Quality "Quality is a customer determination. It is based on the customer's actual experience with the product or service, measured against his or her requirements”
- 4. Software Quality Assurance(SQA) • Is a set of processes and methods to that is applied throughout the software process to ensure quality of products – Comply with standards (ex: ISO 9001,CMMI) – Encompasses software development process • Documentation • Reviews , Inspections • Testing • Configuration management, source control • Measurement and reporting
- 5. Software testing(quality control) • Is a process of verifying and validating that it meets the business and technical requirements of the product being developed •Also identifies important defects, flaws, or bugs in the application code that must be fixed. Essentially we check for • Completeness • Fitness for purpose • Risks
- 6. Testing types – Unit testing • Automatic test on code level run every night or after new code is added – to verify no bugs introduced – Integration testing • Testing interactions between different modules of the system – Feature testing • Performed by a QA when a feature is finished implemented – System testing • To verify whether the system as a whole meets the specified requirements – ExploratoryTesting • Exploratory testing is simultaneous learning, test design, and test execution. – Regression Testing • Test to detect side effects from changes to the system, i.e after bug fix – User acceptance testing • End user testing – Compatibility testing • Verification of compatibility between AMX applications and the different OS, office applications, browsers and databases etc that we support
- 7. How Traditional Test Practices Evolved
- 8. How Traditional Test Practices Evolved
- 9. Agile testing defined • Agile testing is a software testing practice that follows the principles of Agile software development (remember agile manifesto..) • Agile development integrates testing into the development process, rather than keeping it as a separate and distinct SDLC • Agile testing involves a cross-functional Agile team • Agile teams use a “whole-team” approach to “bake in quality” to the software product.
- 10. Role of the tester • Have an agile mindset • be an advocate to the end user – Understand the need of end user due to absence of detailed specs – Participate in scrum meetings – Absorb user stories/ ask questions to clarify • Working directly with devs, designers etc. • Cross functional • Expect changes and adapt
- 11. Test Strategy in agile • Have a test plan then get it validated and approved by whole team/ client – Scope, resourcing, risks, test types, infrastructure, test environment test data, results • Finding the right mix with testing methods. Have a right balance of • Automation – CI – Unit – UI/API • User acceptance testing(beta testing) • Exploratory testing – Systems with heavy business logic favor test automation – Consumer-facing systems favor beta testing • Building a foundation for core agile practices • Choose right people
- 12. Sample test plan
- 13. Test plan
- 15. Testing in agile • We start our testing activities at Release planning stage • Release planning – Create test plans • High level test planning • budgeting enough time – Participate in story sizing “No story is done until its tested” – Prioritizing “What stories finish by release”
- 16. Testing in agile • Each Sprint – Participate in sprint planning – Estimate tasks(QA input) – Write test cases using stories(QA) • High level test cases before coding begins- guide dev • Detailed test cases written during coding • Condition of satisfaction in user story – Unit/ Integration tests(Dev) • Automatic test on code level run every night or after new code is added. Bugs found are fixed immediately – Pair tests(Dev + QA) • Performed when a part of a feature is finished implemented. Bugs found are fixed immediately – Feature tests(QA) • Performed when a feature is finished implemented. Errors found are logged in main project in bug system and prioritized during next sprint planning. After all prioritized bugs are fixed, the feature is ready for System Test at the end . – Reviews (stories, req, test cases with customer, programmer) • Increase collaboration and communications
- 17. Test cases
- 18. Test cases deriving techniques • Boundary testing • Equivalence classes • Decision tables • State transitional diagrams • Risk Analysis
- 19. Testing in agile • Each Sprint contd… – Test automation • Automate new functional test cases • Run automated regression tests – Perform non functional testing (load, security, usability etc.) • Non-functional tests can be included as US/tasks in the sprints – Demo to the stakeholders
- 20. Agile test automation pyramid
- 21. Testing in agile • Hardening sprint (optional) – A hardening sprint can be used for bug fixes in previous sprints. Bugs that are prioritized will be considered here – Do it near the release – The end game(System test) Every member in the team is involved in this. • Mock deploy on staging • Smoke test on staging • Perform non functional testing (load, security, usability etc) • Complete regression test • Perform UAT tests • Other tests – Compatibility(DB upgrade etc) – Installation – Localization etc
- 22. Testing in agile • Release – Define Exit criteria • Testing activities (bug severity, open bugs, coverage levels, metrics etc) • Product Artifacts (user guide, installation guides, other necessary documentation are in place) – Participate in retrospectives • Start • Stop • Continue
- 23. Testing-outlined • Test strategy in agile development Release planning (test plan) Each Sprint (Sprint QA activities) Hardening Sprint (system test) Release QA activities
- 24. Metrics To enhance predictability… – Measuring progress • Burn down charts • Estimated vs. Actual time for tasks – Defect metrics • Root cause analysis • Results from defect tracking system – Traceability metrics • Test coverage (story vs. test cases) • Code coverage
- 25. Success factors for high quality agile projects • Whole team approach • Automation (regression) • Collaboration with customer/stakeholders • Adopt agile mindset • Provide and obtain feedback • Building a foundation of core agile practices
- 26. Q&A
- 27. Thank you
Editor's Notes
- 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
- A product is tested so that it can be judged for 1. completeness 2. fitness for purpose 3. risks
- 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
- 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.
- 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.
- 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
- 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
- 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
- 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.
- 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.
- 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