Getting a grip on your test maturity using the ambition chart
•Download as PPTX, PDF•
1 like•1,061 views
Agile test teams access their effectiveness every sprint. The power of retrospectives is that they, when done well, focus on improving in small achievable steps. This ensures that progress is being made and is more than just a far away dream. Despite the above, I experienced that in and around teams the proposed improvements are measured and valued against the maturity of the agile adoption. I noticed that in several situations people were judging the performance of the team and the proposed improvements against an implicit blueprint; small improvements were fine “for just now” and regarded as a “good first step”. The implication of the above struck me! We all had our own plan and expectations, but these were implicit and not transparent. In reaction I developed the ambition chart. It is a graphical one-pager that gives insight in the current state, the collective ambition and describes the next step to be taken. The ambition chart can be used to: Discus and align expectations and ambition that individual team members have and create a team goal. To break big goals into smaller steps To prioritize improvement suggestions made in the retrospective To manage dependencies between different area’s of improvement To focus on the next step that needs to be taken, without being distracted by the end goal Manage expectations that management and stakeholders have, e.g. by clarifying that the team does a lot of things very well, but address that it has identified some improvements that are not yet on the agenda. To visualize progress and tell success stories to the rest of the organization In this presentation I will explain how to make and use an ambition chart. I will explain situations in which it can be beneficial and share some examples of focus areas.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Getting a grip on your test maturity using the ambition chart
Similar to Getting a grip on your test maturity using the ambition chart (20)
More from Derk-Jan de Grood
More from Derk-Jan de Grood (20)
Recently uploaded
Recently uploaded (20)
Getting a grip on your test maturity using the ambition chart
- 1. GRIP ON YOUR TEST MATURITY Using the Ambition chart Derk-Jan de Grood, Valori 25-27 Oct- QA & Test, Bilbao
- 2. 3 Yeah, but how do we do our testing ? We are all doing agile
- 3. Agile, Continues Integration and Deployment 4 Part of Development Done = Tested Team is responsible for testing Part of Delivery Pipeline Automated
- 4. Agile testing differs Continues Involvement Tools Essential Multi Dimensional Skills Com- munication Quick Feedback 5 Nishi Grover Garg
- 5. Exploring in addition to checking How Quality is achieved in agile 6 Integration testing using virtualization Feature teams complete integrated features Testing is done in the sprint
- 6. But what is the quality of the testing? 7
- 7. Key messages
- 8. Who is responsible for the quality of the testing? 10
- 9. 11
- 10. 12
- 11. Potential problems • Teams get stuck on small daily issues • Teams have difficulties in prioritizing improvements • Teams go their own way (deviate from other teams) 13
- 12. Scaling Agile 14
- 14. Agile Test Maturity How do you measure it? 16
- 15. Feedback loops 17 Risks you want to avoid Capable of dealing with the effect Cost of error Compliency First time right Capable of detecting errors
- 16. Business can wait, but wants progress 18
- 17. AMBITION CHART THE BIRTH OF A NEW IDEA 19
- 18. 20 Subway mapping and release planning
- 20. Our End Goal 22
- 21. 23
- 22. 24 Ambition Chart for the SCRUM implementation Version 1.0 August 2015 - Valori Where dowe stand today? Release & Portfolio Management Stakeholder Involvement Informing the Stakeholder Requirements & Use Cases Testing Demo Team & collaboration
- 23. 25 Ambition Chart for the SCRUM implementation Version 1.0 August 2015 - Valori Where dowe stand today? Release & Portfolio Management Stakeholder Involvement Informing the Stakeholder Requirements & Use Cases Testing Demo Team & collaboration
- 24. 26 Ambition Chart for the SCRUM implementation Version 1.0 August 2015 - Valori Where dowe stand today? Release & Portfolio Management Stakeholder Involvement Informing the Stakeholder Requirements & Use Cases Testing Demo Team & collaboration Example of descriptions • X% of the test are automated and launched from the build server • Team has sufficient knowledge to independently develop the requested features • Stakeholders define business value for each feature
- 25. The Test Improvement plan 27
- 26. ALM RM Ambition Chart Testing Derk-Jan de Grood - Versie 0.2 November 2015 Ketentest TestAutomatisering Systeemtest Testaanpak UAT Unit Test
- 27. Typical area’s of improvement Agile Quality Strategy 31 What needs to be tested Steering committee Dashboard/ Roadmapping Auditing the test work Coaching the testing team members Organizing tests that do not fit the sprint We still need a plan to know were complete There is a need feedback and traceability (comfort & adaptivety) Testing needs be of quality to justify itself Testing needs to add value to hold up an release CI/CD requires that (in random order) 18 Teams collaborate with each other Deployment is a hands-off process Feedback loop to improve quality Features are launched frequently Acceptance criteria are clear Teams have all required skills and knowledge Tests are automated Valori-version1.2-2017 Architecture supports partial development and release Ensuring Integration Organization Component System Service Continuously(in the sprint) Occasionally(e.g. prior to arelease) General trend: Incre system (e.g from Un Systems) results in le frequent integration, b becomes harder to tes integration. This has im the time-to-market and insight might lead to targ improvements
- 28. Agile Quality Strategy 30 What needs to be tested Steering committee Dashboard/ Roadmapping Auditing the test work Coaching the testing team members Organizing tests that do not fit the sprint We still need a plan to know were complete There is a need feedback and traceability (comfort & adaptivety) Testing needs be of quality to justify itself Testing needs to add value to hold up an release
- 29. CI/CD requires that (in random order) 1 Teams collaborate with each other Deployment is a hands-off process Feedback loop to improve quality Features are launched frequently Acceptance criteria are clear Teams have all required skills and knowledge Tests are automated Valori-version1.2-2017 Architecture supports partial development and release
- 30. Ensuring Integration 32 Organization Component System Service Continuously (in the sprint) Occasionally (e.g. prior to a release) General trend: Increasing the system (e.g from Units tot Systems) results in less frequent integration, because it becomes harder to test the integration. This has impact on the time-to-market and this insight might lead to targeted improvements
- 31. Making your own ambition chart It’s easily done
- 34. But there are guidelines 36 Identify Maturity Areas Dream about the ideal situation Define small steps towards the end state Describe characteristics rather than actions Draw the "today we are here" line Forget about the end state focus on tomorrow
- 36. Testen Blije medewerkers Nieuw pand Commitment & aanhaken business Release Voorspelbaarh eid IT belang Ambitiekaart ScrumMasters Derk-Jan de Grood – Versie 1 - November 2016 Stabiliteit AanvoerAfvoerTeamorganisatie
- 37. 39 Improvement areas contributing to the same goal End goal
- 38. Application • Test Improvement Plan • Test Guild • Scrum team (or teams) • Department ambition • Personal development 40
- 39. Keeps team focus on goal rather than operational issues Expectation management toward stakeholders
- 40. Derk-Jan Valori Coltbaan 4a 3439 NG NIEUWEGEIN The Netherlands • derkjandegrood@valori.nl • +31(0)651807878 • www.valori.nl • @DerkJanDeGrood • http://djdegrood.wordpress.com 42
Editor's Notes
- https://www.agileconnection.com/article/5-ways-agile-testing-different-traditional-testing: Continuous Involvement In traditional projects, the test team works mostly in a silo, and there is little or no interaction needed with developers or other teams on a daily basis. But in agile, the test team is integrated with the Scrum team instead of being a separate unit. They need to be continuously involved in all aspects of the project, starting with the requirements and design of each feature. This makes the testers’ days busier with discussions, meetings, and interactions where they need to put forward their opinions. Agile necessitates that everybody report to the Scrum team first and their separate testing or development team later. In my experience as a part of a Scrum team, we would discuss our vacations or skill training needs first within the Scrum team, then inform our test manager afterward. Essential Tools Agile needs tool support more than traditional projects do because of the pace of development and continuous iterations. Each iteration brings along some regression work from the previous iterations that needs to be automated quickly. The same is true for test data generation, white-box testing tools, and static analysis tools, which become a necessity in an agile system. Given the time and quality constraints, performing white-box tests using control flow or data flow analysis, static analysis of code, or reviews for code and documents is no longer optional. Instead, it’s a mandate to prevent defects and ingrain quality into each work product. While in traditional projects, tools may be a luxury we might not be able to afford, in an agile project they become a necessity. Testers need these tools’ abilities in order to achieve their quality targets. When my team began our agile transformation, we had one automation engineer who would work on automation scripts for the entire project. But when pacing through the sprints, we quickly realized that one automation engineer was not able to keep pace with automating all features in all sprints. So, everybody started pitching in by scripting the features they tested, and eventually it was mandated. The automation expert was only used for framework-level implementation, and later he was absorbed as a functional tester. Due to frequent changes in the application within the sprint, we would follow an (n–1) approach to automation of our product, automating the features of the nth sprint in the next sprint, then subsequently using them for regression. But due to overload of regression building up as we progressed, it was crucial that each tester be able to perform and use the tools effectively, building up the test suites every sprint. Multidimensional Skills A traditional project has set expectations from the testers and testing activities. Each phase of testing gives set outputs, such as test design and specifications in the design phase, functional issues and defect reports in the execution phase, regression tests and retest results in reruns, and acceptance test reports in the end phase. This pattern does not leave much room for anything else because the project is already hard-pressed at the deadline. But an agile tester’s viewpoint covers not only the functional aspects of what he is testing, but also many broader aspects of the application. He need not be a performance testing expert to suggest during the design discussions that the design might not be able to support too many users. He may not be a usability expert, but he can suggest better ways to design the web form of their user story. He may not be a technical writer, but he may be required to review the installation guide steps. An agile tester has to have a broader perspective of quality in his project’s context and possess skills in all those areas. Effective Communication Agile requires effective communication among the team members at all times, and testers play a key role in establishing and maintaining that. For example, as a part of a Scrum team, a tester will be required to wear many hats: that of a requirement critic for the product owner, of a design reviewer for the developers and architects, of a functionality expert as a tester, and of a release adviser to the manager. Testers have to give their opinions and ideas at all stages of the project, which may be not required (or even much welcomed) in a traditional project. Testers act as the binding force of the team when they work in pairs with developers, sharing their test cases and ideas, as well as when they work as a quality reporter for the manager, with daily statistics and defect metrics for each sprint. The art of verbal and written communication is essential in an agile project. Quick Feedback from Testing The most important difference for agile testers is the quick feedback being given from the testing perspective at every point. The agile timeframes are shorter than on a traditional project, and testing needs to provide feedback about project quality on a regular basis. Daily stand-up meetings, design discussion or review meetings, the user story verification status, and sprint retrospectives all require constant feedback from testers. There is some additional pressure because the direction of the project gets defined by this feedback, and there is no final “quality gateway” at the end if the project does not meet the deadlines or quality goals. This keeps the testers on their feet at all times, unlike in traditional projects where testers are required only at the end of the project for a sign-off. Working in an agile environmnet can be challenging for testers coming from traditional projects, but by being open, flexible, and adaptive, they will find that an agile team is a wonderful place to be a tester.
- But is the team capable of doing good tests?
- Continues improvement is a pilar of agile
- You can do team retrospectives, which is important to improve
- Scrum of scrum like retro with the aim to watch the maturity of the Scrum implementation or the testing…..
- We do not use TPI models and trust on the feedback loops to improve our testing… e.g. Production issues
- Rather than use a checklist let the team decide and dream
- How to ensure Integration We do: CI/CD MBT UT Automated System test Automated e2e test Interface testing Manual Regression testing Integration sprints other