Top Ten Quality Tips for Agile!

Transcription

1 Europe s Premier Software Testing Event Stockholmsmässan, Sweden Testing For Real, Testing For Now Top Ten Quality Tips for Agile! Stevan Zivanovic, Experimentus, UK

2 Top 10 Quality Tips for Agile Stevan Zivanovic EuroSTAR 2009 Listen Challenge Understand Interpret Create Private & Confidential Experimentus Ltd 85 Tottenham Court Road London W1T 4TQ T: +44 (0)

3 Agenda Introduction why bother with Quality in Agile? The top 10 tips on how to improve quality in an Agile project Conclusion why not bother with Quality in Agile? 3

4 Why Bother with Quality in Agile? Is Quality not just testing? No Why should I bother? It s a mental attitude that everyone needs to own and strive for But surely with Agile this is automatic? No. You can still get the wrong level of Quality using Agile development 4

5 Wrong Level of Quality It is easy to get carried away with being Agile however: You only listen to the end user for you requirements so what about those who support it You use inexperienced testers and end up with the wrong/incomplete tests Everybody has assumed a certain level of functionality People claim that the system is ready when it is not Errors become apparent only at the end It all gets a bit disjointed process, people, outcomes don t match expectations The same problems as last time re-appear 5

6 The Top 10 6

7 1 - Agile Measures Success on Working Software One of the four core Agile Manifesto values is: Working software over comprehensive documentation What does working software actually mean? Make sure that all of the project stakeholders agree to this Discuss and review the test levels with the stakeholders and the benefits: developer testing system testing integration testing business and operational acceptance testing Working software should ONLY be considered as WORKING once it has been fully tested and show it as such on your burn rate 7

8 2 - Good Old Static Analysis Check any requirement / change / feature before it s built It s still cheaper to catch problems before coding Boehm still lives Use development tools/techniques to check code (e.g. Pair Programming) What you can do:- Ask the awkward questions when looking at a story board ask why, how many people, in what timescales, etc Ask the obvious questions it s surprising how many of these tend to raise major problems Do code walkthroughs 8

9 3 - Design the Tests With the often short timescales and high levels of change, picking the right tests is crucial Use test design techniques: Risk Based Testing to help prioritise test types and the emphasis Equivalence Partitioning and Boundary Value Analysis to get the optimum number of tests for ranges, sets etc State Transitions use this to help identify user process states as well as system states to prioritise and optimise the test cases Decision tables particularly when you have a number of inter-related features All Pairs When you have too many drop downs on a screen, this can help optimise the number of tests 9

10 4 - The Services Team Need a Service Don t forget that your Services/Operational Support team are customers also Their requirements are as valid as the users sometimes more so! You need to consider your Non-functional/Quality tests : Responsiveness Failure Scenarios Maintainability Security etc What to do: Get the Support team involved right from the start Get your developers to test for this early Build your automated performance/load/stress tests with each cycle Consider focusing your latter cycles to these needs 10

11 5 - Developers as Testers Development testing is mandatory It needs to be repeatable It needs to be repeated often And hence it needs to be automated It needs to be thorough It needs to test what was intended to what was actually intended This is where Test Driven Development can help Also don t forget to use your testers, they can help in the test design 11

12 6 - Keep to the Rhythm The Rhythms that are often cited are there for a reason A Rhythm refers to processes and practices that ensures each element happens at the right time, identify the ones that you follow A good development process can have a number of Rhythms running along side each other, e.g.: Plan Do Check - Act Code - Use Fix Requirements Design Coding Testing Stand up Burn rate Review Test Design Test Code Test Release The Rhythms are like a tune, you break the Rhythm and the music becomes a cacophony 12

13 7 - Automate at Will Automate as many of your frequent, regular, predictable processes as possible Automate the handling of Features Automate the building of code Automate the deployment of code Automate the generation of release notes Automate the testing of code developer, system, user, performance, security etc Automate the test environment These will provide you with a repeatable and accurate system Don t forget your Agile principles in building these scripts 13

14 8 - Build Your Regression Think carefully before you start as to how you build your regression pack It will depend on: How much testing is done and by whom What is automated What is to be given over to the users and when The level of change and where The product risks You will quickly run out of time if you try to use all of your tests every time There is a real danger that you spend your latter cycles/iterations just running regression tests All of your test levels will need a suitable regression pack Automate as much as you can 14

15 9 - Talk the Talk Individuals and interactions over processes and tools This means that just using documents to define a process and what is happening is no longer true The excuse of Nobody told me is not acceptable you are in a small enough team to ask and talk to everybody Make sure that you tell others what you are doing Keep the daily stand-up short and accurate Ensure that everybody can have their say Ensure that all feedback is positively presented Listen to what people are saying 15

16 10 - Actually Learn From Your Lessons If you always do what you have always done, you will always get what you have always got Again, from the Agile Manifesto: Responding to change over following a plan Don t forget that responding to your own needs is important too Change is important: learn from past mistakes and don t repeat them Understand what went well and enhance it If it was neutral do something to move it a stuck state is not pleasant Make the changes in an Agile fashion i.e. determine what is needed, make the change and test the change, then check it again what a Rhythm! 16

17 Summary The Top 10 comprises of: 1. Agile Measures Success on Working Software - It only works if it is tested 2. Good Old Static Analysis Review what is proposed 3. Design the Tests Optimise your testing 4. The Services Team Need a Service Non-functional/Quality testing 5. Developers as Testers Unit/Component testing is vital 6. Keep to the Rhythm Set up and maintain rhythms 7. Automate at Will Automate mundane/repetitive tasks 8. Build Your Regression Plan your regression test pack 9. Talk the Talk Communicate effectively 10. Actually Learn From Your Lessons Learn from the past and make changes 17

18 Conclusion 18

19 Why Not Bother with Quality in Agile? There is nothing new here, you need to use all of your skills in a different context Benefits: High quality software the first time round Hit the timescales that you need Hit the correct budget Other benefits from a corporate perspective can include enabling certification of your processes to CMMI or TMMi and others But most of all: Satisfy your customers Satisfy yourself on a job well done 19

20 Thank you +44(0)