Testing in agile


Published on

Testing in agile

Published in: Design, Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Testing in agile

  1. 1. Testing in Agile http://qtp.blogspot.com 1
  2. 2. Table of contents1. Traditional style QA2. Agile Approaches3. An Agile Tester4. Traditional vs. Agile5. Role Testers Play6. Testing & Testers on Agile Projects7. Question: While a developer is coding a task, it is impossible for a tester to test it (it doesnt exist yet). What then is the role of a tester at this point.8. Question: Is the tester now involved in unit testing? Is this done parallel to black box testing?9. Question: What does the tester do during a sprint where primarily infrastructural changes have been made, that may only be testable in unit testing?10. Specific Technical Skills For Agile Tester‟s Toolkit http://qtp.blogspot.com 2
  3. 3. Traditional Style Quality Assurance Process and tools are a key part of QA and Testing. QA people seem to love documentation. QA people want to see the written specification. And where is testing without a plan? So, is there a role for QA in Agile projects? Maybe, but the role is different, the tasks are different. http://qtp.blogspot.com 3
  4. 4. Agile approaches are changing the conversationabout software development Agile shifted our attention to small teams. . Incrementally delivering quality software. The old ideas about testing at the end of the coding phase no longer applicable. We need to think about the role of Quality. Assurance in Agile Projects. Definitely NOT business-as-usual. http://qtp.blogspot.com 4
  5. 5. An Agile Tester A professional tester who embraces change, collaborates well with both technical and business people, and understands the concept of using tests to document requirements and drive development. Agile testers tend to have good technical skills, know how to collaborate with others to automate tests, and are also experienced exploratory testers. They‟re willing to learn what customers do so that they can better understand the customers‟ software requirements. http://qtp.blogspot.com 5
  6. 6. Traditional vs. Agile TestingPhased Model e.g. Waterfall Requirements Specifications Code Testing Release Time Agile: F Iterative & Incremental E Each story is expanded, coded & tested D D Possible release after each iteration C C C A B A B A B A B http://qtp.blogspot.com 6
  7. 7. Traditional vs. Agile TestingTraditional AgileIn the phased approach diagram (see previous Agile is iterative and incremental (see previousslide), it is clear that testing happens at the end, slide). This means that the testers test eachright before release. The diagram is idealistic, increment of coding as soon as it is finished. Anbecause it gives the impression there is as much iteration might be as short as one week, or astime for testing as there is for coding. In many long as a month. The team builds and tests a littleprojects, this is not the case. The testing gets bit of code, making sure it works correctly, and“squished” because coding takes longer than then moves on to next piece that needs to beexpected, and because teams get into a code- built. Programmers never get ahead of theand-fix cycle at the end. testers, because a story is not “done” until it has been tested.Tests are usually created from a requirements Rather than creating tests from a requirementsdocument. document that was created by business analysts before anyone ever thought of writing a line of code, someone will need to write tests that illustrate the requirements for each story days or hours before coding begins. http://qtp.blogspot.com 7
  8. 8. Role Testers Play The role of the tester with agile methods is an area that has received increasing attention. Initially with a focus on unit testing and „acceptance‟ testing it appeared the system tester did not have a role in agile. Unit Testing Acceptance Testing & System Testers are no longer required? Typical responsibilities for testers in agile can include (not limited to):As Cem Kaner put it:„The nature of the testers rolechanges in iterative projects. • Facilitate communication between the technical & business stakeholders 1We are no longer the high-profile victims, we are no 2 • Support early validation of requirementslonger the lonely advocates ofquality, we are merely (!) • Help the business stakeholders define acceptance criteria 3competent serviceproviders, collaborating with a • Create automated acceptance testsgroup that wants to achieve 4high quality.‟ • Perform manual/exploratory tests on early-stage code http://qtp.blogspot.com 8 5
  9. 9. Testing and Testers on Agile Projects http://qtp.blogspot.com 9
  10. 10. It comes as no surprise to testers thatworking software is not the same as code –the tester clearly needs to be involved in notonly assessing the product, but in decidinghow the product is to be assessed.However, with automated unit tests in thehands of the coders, and confirmation-focused acceptance testing driven by thecustomer, testers should be aware that theywill not be the sole – or even the primary –owner of deciding what works, and whatdoesn‟t. http://qtp.blogspot.com 10
  11. 11. Testers need to be able to interact directly with designers and coders to understand the technological imperatives and restrictions that affect the software and its unit tests.Conversations and sharedunderstandings Overall less documentation will take the required place ofsome documentation http://qtp.blogspot.com 11
  12. 12. Testing will be driven by what is important to a user, rather than tofulfill a procedural requirement. It is better to have communicationbetween tester, customer and designer than to maintainindependence of the test team.In practice, it is common to find large-scale automated unittesting on agile projects, to confirm that code works as expected.The product will be judged by the customer typically bymanual, confirmatory tests, with close observation forundesirable behaviors. Testing by testers is often driven by theneed to measure the system‟s performance and to find surprises– tools are very much in evidence, but rigid test scripts andprocedures do not give the requisite opportunity fordiscovery, diagnosis and exploitation. http://qtp.blogspot.com 12
  13. 13. Testers are key collaborators with the customer, and onsome agile projects will take on much of the role of thecustomer in designing and executing confirmation-drivenacceptance tests. However, although testers traditionallymake good customer advocates, working closely with acustomer is preferable to becoming a proxy.Test strategies which lean heavily on an unchanging setof requirements (for example: designing and coding tests to bebought together with code late in the project; prioritizing tests based ona fixed risk assessment; testing only what has been agreed in thecontract; reporting bugs only against fixed requirements) may beconsidered to be fatally flawed in the light of this value.Iterative collaboration is favored over a negotiated bill ofwork. http://qtp.blogspot.com 13
  14. 14. While a developer is coding a task, it isimpossible for a tester to test it (it doesntexist yet). What then is the role of a testerat this point. http://qtp.blogspot.com 14
  15. 15. Testers can prepare their test plans, testcases, and automated tests for the userstories before (or while) they areimplemented. This helps the teamdiscover any inconsistency or ambiguityin the user stories even before thedevelopers write any code. http://qtp.blogspot.com 15
  16. 16. The tester could be working with thecustomer to fine tune the stories in thesprint. http://qtp.blogspot.com 16
  17. 17. They can often be involved in designingthe tests that the coder will write to performTDD. http://qtp.blogspot.com 17
  18. 18. If the agile team is fairly advanced then thetester would normally be writing the ATDD(Acceptance Test Driven Development)tests. These could be in a tool such asFitnesse or Robot Framework or theycould be more advanced ruby tests oreven some other programming language.Or in some cases, simple record andplayback can often be beneficial for asmall number of tests. http://qtp.blogspot.com 18
  19. 19. They would obviously be writing planningsome exploratory testing scenarios orideas. http://qtp.blogspot.com 19
  20. 20. The tricky thing to comprehend sometimesfor the team is that the story does not haveto be complete in order to drop it to the teststack for testing. For example the coderscould drop a screen with half of the fieldsplanned on it. The tester could test thishalf whilst the other half is being codedand hence feedback in with early testresults. Testing doesnt have to take placeon "finished" stories. http://qtp.blogspot.com 20
  21. 21. Is the tester now involved in unit testing?Is this done parallel to black box testing? http://qtp.blogspot.com 21
  22. 22. Don’t do Testers only test code thatTesters Unit Tests passes all of the automated unit, integration and acceptance tests, which are all written by the developers. This split may be different elsewhere, though; for example your testers could be writing automated acceptance tests. The whole point of unit tests is to test the software is correct to avoid wasting time later down the line. Its all about instant feedback http://qtp.blogspot.com 22
  23. 23. What does the tester do during a sprintwhere primarily infrastructural changeshave been made, that may only betestable in unit testing? http://qtp.blogspot.com 23
  24. 24. Testers workload will vary betweensprints, but regression tests still need to berun on these changes... http://qtp.blogspot.com 24
  25. 25. You may also find that having the testersspend the first couple of days of each sprinttesting the tasks from the previous sprint mayhelp, however its better to get them to naildown the things that the developers are goingto be working on by writing their test plans. http://qtp.blogspot.com 25
  26. 26. Ensure that project or sprint requirements areclear, measurable and testable. In an idealworld each requirement will have a fit criterionwritten down at this stage. Determine whatinformation needs to be automatically loggedto troubleshoot any defects. http://qtp.blogspot.com 26
  27. 27. Prepare a project specific test strategy anddetermine which QA steps are going to berequired and at which project stages:integration, stress, compatibility, usability, performance, beta testing etc. Determineacceptable defect thresholds and work outclassification system for defectseverity, specify guidelines for defectreporting. http://qtp.blogspot.com 27
  28. 28. Specify, arrange and prepare test environment:test infrastructure and mock services asnecessary; prepare test data; write scripts toquickly refresh test environment when necessary;establish processes for defecttracking, communication and resolution; preparefor recruitment or recruit users for beta, usabilityor acceptance testing. Write test scripts. http://qtp.blogspot.com 28
  29. 29. Ideally the tester would be working with the teamand the customer (who by the way, is part of theteam!) to define the planned stories and build insome good, detailed acceptance criteria. This isinvaluable and can save loads of time later downthe line. The tester could also be learning newautomation techniques, planning testenvironments, helping to document the outcomeof the planning. http://qtp.blogspot.com 29
  30. 30. Specific Technical Skills For Agile Tester‟s Toolkit http://qtp.blogspot.com 30
  31. 31. Automation Skills For automation to -> we need to apply succeed -> good design practices a single & We strive to keep each automated test to clear purpose Learn how to evaluate and choose the right tools, so you can help your team create maintainable automated regression tests. You can free up time for essential testing activities such as exploratory testing. http://qtp.blogspot.com 31
  32. 32. Acceptance Test-driven Development Communication skills and good domain understanding enable testers to help business experts give good examples of both desired and undesired system behavior. We can turn these examples into tests that help the programmers understand what code to write. This is called acceptance test-driven development, and it is a major step toward building quality into the code and preventing defects. http://qtp.blogspot.com 32
  33. 33. Learning Styles auditory learn by Learning learners listening Styles visual Learn by learners see pictures We all have blind spots that may prevent us from learning or triggers where we shut down and don‟t hear the message anymore. Keep your emotional “hot buttons” in mind and focus on what you can learn from instructors, material, or teammates to enhance your abilities. Mentors with different backgrounds or from other industries besides testing and software development might work best with your learning style. Don‟t limit yourself to coaches, mentors, and instructors who work specifically in software testing. http://qtp.blogspot.com 33
  34. 34. Learning Resources Examples Many good software Testing books Plenty of free material on the Internet Resources your peers can provide Communities of practice are another good place to find mentors and learn together Conferences are an obvious way to get a lot of new ideas in a very short period of time Mailing lists and social networks Testing communities, such as Weekend Testers http://qtp.blogspot.com 34
  35. 35. References• AGILE TESTING A PRACTICAL GUIDE FOR TESTERS AND AGILE TEAMS by Lisa Crispin & Janet Gregory• http://sqa.stackexchange.com/questions/1824/the-role-of-a- software-tester-in-an-agile-environment• http://searchsoftwarequality.techtarget.com/news/1243805/Role- of-testing-in-agile-projects• http://www.kohl.ca/blog/archives/000116.html• http://www.mcbreen.ab.ca/talks/CAMUG.pdf• http://newsweaver.ie/qualtech/e_article000847213.cfm?x=b11,0,w• http://stackoverflow.com/questions/1640911/role-of-testers-in- agile• LEARNING FOR AGILE TESTERS, Part 2 by Lisa Crispin and Janet Gregor, Better Software Magazine Sept/Oct 2011 http://qtp.blogspot.com 35