Vojtěch Barta QA role in Agile team 1
• E-mail: bartavoj@gmail.com • Twitter: @bartavoj • Web: bartavoj.cz • QA, Testing, Agile – About 8 years – Leading QA Team in Vendavo 2 Vojtěch Barta
• Quite a lot of definitions -> Choose or Build your own • Four levels of quality – Deliver according to requirements – Deliver according correct requirements – Deliver value according to correct requirements – Deliver value according to correct requirements when all stakeholders are satisfied and happy • Quality is Satisfaction of all stakeholders What is quality?
My idea how to do it in right way 4
• Of course not! • It is a vision, target, something I aim for… • You need to know where you would like to be to go in correct direction • Each project has own challenges • It is about people!!! Do I really do it this way?
Before Project 6
• Our projects are based on SOW which defines a lot of things • Problems starts here – Our customers have different knowledge of Agile – Different experience and expectations – They do not understand process yet • Lessons learned – Never ever say Agile is easy for customer. It is not and they need to be prepared – Make sure all stakeholders understands their responsibilities – Find out where are you as soon as possible Before project
• We have good SOW (not perfect) but … – Nobody cares to much about the most important chapters • Methodology to be followed – What does it mean to work in Sprints? – What is a definition of done? – What do we expect from customers? – Everybody cares about Scope • It is not understood as wish list • Despite SOW is legal document it is hard to push to make to process real later in the project SOW
• Is kind off kick of Sprint(s) before real implementation starts • Very good idea with clear Exit Criteria – All stakeholders identified and understood – Process of working agreed (Sprints, responsibilities, etc.) – High level idea is clear – Enough User Stories to start next Sprint (ideally for next two sprints to mitigate risk of PO to be bottleneck) – Test Strategy Prepared, reviewed and agreed Foundation Sprint
• We are not strict on Exit Criteria – All stakeholders identified and understood • Testing team on Customer team – what are you talking about? – Process of working agreed (Sprints, responsibilities, etc.) • That is not how we understood SOW – we do not like that – High level idea is clear – Enough User Stories to start next Sprint • Even most important User Stories are vague, not clear, missing Acceptance Criteria, etc. – Test Strategy Prepared, reviewed and agreed • Testing is your stuff… Foundation Sprint - BUT
• Process – Help with negotiation • Requirements – Agree on the way how requirements should be captured to provide • Enough information for Devs to Develop and Test • For Testers to Test • For PO to Accept • For Customer to Accept • Test strategy – What we should do and why? – Who is responsible for what? – Preventing vs. Finding bugs QA Work in Foundation Sprint
Sprint work 12
• Sprint as Small waterfall • There is no Test Phase in Agile!!! Sprint work – Small waterfalls
• Grooming – Regular whole team activity – Go trough new / changed User Stories – PO -> Team = business understanding sharing – Team -> PO = quick feedback – Achieve team agreement about requirements Sprint work – ensuring business understanding
• Grooming – Regular whole team activity • It is not regular – Go trough new / changed User Stories • There are not enough User Stories defined – PO -> Team = business understanding sharing • Devs do not not care – Team -> PO = quick feedback • Voiceless (sleeping) team Sprint work – ensuring business understanding - BUT
• Sizing – When we are satisfied based on grooming – Set a size as relative measure – Achieve team agreement about complexity Sprint work – ensuring business understanding
• Sizing – When we are satisfied based on grooming – Set a size as relative measure • What is the middle size • Manager: I need to know it in hours – Achieve team agreement about complexity Sprint work – ensuring business understanding - BUT
• Planning – Break down US to Tasks – Each task is estimated by the one who will do it – At least one Dev and one QA task – Agree who will test what (Dev vs. QA) Sprint work – planning as personal commitment
• Planning – Break down US to Tasks – Each task is estimated by the one who will do it • Estimates are low • Estimates are guess with buffer • Somebody else provides estimates – At least one Dev and one QA task – Agree who will test what (Dev vs. QA) • Why should Devs test? Sprint work – planning as personal commitment - BUT
• Before development of Critical US starts • QA + Dev – Do we have same expectations? • QA Dev – This is how I will test it… – This is what I do expect from you to test… – What help do you need? Sprint Progress – QA Touch Points – Before
• Support Devs – This is the highest priority for QAs – Sometimes QA = Questions and answers • QA should be capable to answer the most of the questions • There is very close cooperation between QA and Dev on each task = know your developers • Product Owner is usually busy with preparation of next sprint – We do pair programming Dev + QA sometimes • Senior QAs need to be able to understand code properly Sprint Progress – QA Touch Points – During
• Test Case preparation – Test Cases should have right level of details • Steps are optional • Supporting materials (excels, diagrams, mind maps) – Are • Identification of test flows and effective way how to test them • Measure – Are not • Prove of testing • Training materials – Sometimes done even in advance in cooperation with Product Owner Sprint Progress – QA Touch Points – During
• Automation – There is no Agile success without Automation – Not necessarily QA task – Really dependent on project, architecture, etc. Sprint Progress – QA Touch Points – During
• Handover to QA – When development is finished (or more often) – Dev QA • This is how I implemented it = Demo • This is how I tested it – QA Dev • Direct feedback • Avoiding ping pong • Reduce time of testing • Testing – Yes we test Sprint Progress – QA Touch Points – After
• Good practice to have weekly Demo • QAs are a good candidates to do it • Present to the team what was done – Devs to comment on others work – QAs to get bigger picture – Product Owner to validate Sprint Progress – Internal Demo
• There have to be demo to customer be the end of each Sprint • Actively seek for feedback – Get acceptance if possible Demo to customer
• Help them with regular testing – Most of the US cannot be accepted on Demo – Further Customer testing is required for Acceptance • Customer are not test experts • In our case they do not know our product • Teach them, but do not do it instead of them • During UAT – Be onsite and help to solve problems quickly Supporting customers
• What is the reason for reports – To inform about something – Target for different audience – Do not do reports which nobody needs – Make them easy Reporting
QA as responsibility of Whole Team (синхронный перевод)