Lessons Learnt in Agile Testing by Harsh Saini and Rajneesh Namta


Published on

AgileNCR 2010 conference was held in Gurgaon on 17th & 18th July 2010. This largest community driven conference was the Fourth edition of Agile NCR and was organized in collaboration with ASCI. This time the event was based on four major themes : 'Agile for newbies', ' Agile Adoption Challenges', 'Workshops and Software Craftsmanship', and ' Post Agile'.

Published in: Technology
1 Like
  • Be the first to comment

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

No notes for slide
  • Role of Tester in an Agile project : Involvement right from the project initiation Working in close collaboration with the entire team No communication gap No friction as experienced in traditional development Not a Quality police but more of a enabler helping stakeholders to make the right choices
  • The concept of one team is a very powerful one. Entails a complete change of mindset in terms of working together to achieve the common objective : Highest quality and greater customer satisfaction. Testing essentially remains the same but how it is applied in Agile is different. Every problem is a team problem/Every success is a team success. Everyone’s point of view is considered before making any decisions Team members help each other/pair/take collective decisions and responsibilities Transforms the unit into a well oiled machine geared to achieve greater efficiency and optimum utilization of resources A team with mixed skills (dev/BA/testers/Users) can add a lot of value than a team with only specific skills (like dev only)
  • No documentation does not mean that you do not know what you are doing A Test strategy will help the whole team to see the testing activity as important as well as clearly. It will help the PO to think about US or release planning in terms or testability. It will give the tester a clear path to take while testing during a sprint or a release. Test strategy will detail on a high level a testing plan for say a release with things like testing tools to be used, test automation, interaction with third party tools, interfaces, database interactions, types of testing etc. Test strategy can be anything : A piece of paper / a wiki page / a text document / a diagram on email detailing your approach Create extensive documentation only when you are able to keep it up to date else it will get stale soon. Ensure you communicate the strategy clearly and well in advance to the team so than you can incorporate their inputs before implementing the same. You will get brilliant ideas from the team as everyone would be interested in having test process in place which is helping the final cause.
  • No one knows the better use of the software that is being created than it’s actual user. Involving the end user in your test process will enable you to fine tune your test cases and find defects earlier. Customer can provide you the actual data which is a critical requirement for testing. Additionally he/she can provide you usage scenarios and other requirements such as performance benchmarks When in doubt make it a point to get it clarified from the PO rather than going to developers.
  • How do you know that you are done with your testing ? A tester is never done but we need to make a decision at some point of time to stop testing what we testing and take up new tasks. It’s a checklist which enables a tester to move a US from ‘ready to test’ to ‘Done’ Some pointers: Required functionality as described in the user story is implemented. Test data and cases (per user story) are documented in fitnesse (automated) / confluence (others). The implementation has passed the functional tests. Any open issues/bugs for the sprint are documented in bugzilla with correct prioritization.
  • It is a good practice to give concrete examples while asking something from PO, Dev. Simplify the things, don’t talk in much technical terms. Attach screenshots/movies. A query asked in plain language or a lengthy email might not get the response you need, but seeing a real example will definitely evoke positive reaction. Additionally the user might himself come up with alternative scenarios using examples which helps to disambiguate requirements. For example, in case you are testing a finance application where complex calculations are done; it would be good idea to create a small spreadsheet with calculations for diff scenarios to understand a formula rather than exchanging lengthy emails.
  • Within a sprint you can plan to test accordingly : At the start of a sprint : Requirements testing and probably automate leftovers from previous sprints As sprint progresses test the features being coded (ideally it would be faster to do it manually the first time) And at the end of sprint focus on end to end tests (workflow testing) and regression tests to ensure that what worked before works now as well. Automation can be done while moving a story form RFT to Done. Based on the context you are in make a decision to test accordingly rather than following a set plan (the key point is to be flexible enough so that you can achieve maximum coverage in the limited amount of time you have)
  • Test Automation is not only about execution of the test cases automatically. It has a much wider application w.r.t integrating your test cases with the build process, integrating toolsets/frameworks developed to test different components of the application, automatic reporting and notification mechanisms etc. A tester might be involved in the creating and maintaining most of the test artifacts but he needs the help of entire team to keep it going. Some situations might demand a in-depth technical know-how (like mocking some external interfaces or making 2 tools talk to each other) which a tester “lacks most of the times” (creating fixtures in Fitnesse).Hence the whole team is responsible for keeping the test automation going. It also gives the team (esp devs) a lot of confidence before making any changes if there is a robust framework in place which they can rely on.So its for the benefit of whole team and the whole team owns it. A tester might take the ownership of maintaining and keeping it relevant in long run but not without the commitment of the team.
  • There are 2 key terms here “Fast” and “Quality” Faster feedback is the very essence of agile development. Having automatic and other checks in place (like CI ,automated Unit testing and regression testing) ensure such that feedback is instantaneous. Additionally you do not wait for a bug to be logged and go through the entire process before its fixed and re-verified .As soon as a issue is found its good to announce it (write it on the board, ping the concerned dev or just shout).Get it fixed then and there. Quality feedback means that the one looking at the feedback should not need to spend hours to diagnose and than debug and point the exact cause of failure. Your tests/ reports/ defects should contain every possible information which helps in reducing the time required to diagnose a problem. Test/defect reports (automatic or otherwise) should be smart enough that only a glance through it is enough to know what failures have happened and probably what is the cause for it. (refer to the example of flight simulator console in the picture)
  • Reassess to remain relevant Product/features/ test assets artifacts grow in size and become complex. What strategy worked yesterday may not be relevant anymore as there have been continuous changes. Hence you need to re-visit and re think your test process to keep it relevant and up to date. Give example of iron man over the years as shown in pictures. For example you are testing a web app and you initially thought off testing it for compatibility on only 2 browsers (IE and Firefox).Now since google chrome is also being used probably you need to revisit your assumption and create some thing to test on chrome as well. Or initially you only had the business logic to test but now the client have decided to have web service interface for external clients so you need to test the service layer as well.
  • Agile is not only about working on project. You add more value to yourself, your org and your customer by constantly learning, exploring new things. You would also like to share your knowledge and expertise with others and give something back to the community (open source). Read literature Try something new (a quick POC) and probably it helps you to make things better and even if does not you fail quickly and know something which doesn’t work.
  • Lessons Learnt in Agile Testing by Harsh Saini and Rajneesh Namta

    1. 1. Lessons Learnt In Agile Testing <ul><li>By: </li></ul><ul><li>Harsh Saini </li></ul><ul><li>Rajneesh Namta </li></ul>
    2. 2. Agenda <ul><ul><ul><li>Role of a tester in an agile project </li></ul></ul></ul><ul><ul><ul><li>Lessons learnt in agile testing </li></ul></ul></ul><ul><ul><ul><li>Q&A </li></ul></ul></ul>
    3. 4. Lesson 1 “One Team One Goal”
    4. 5. Lesson 2 “You need to have a test strategy”
    5. 6. Lesson 3 “Involve the customer in test process”
    6. 7. Lesson 4 “Have a Definition of Done in place”
    7. 8. Lesson 5 “Clarify specifications using examples”
    8. 9. Lesson 6 “Test as per the context of a sprint”
    9. 10. Lesson 7 “Test Automation is a team effort”
    10. 11. Lesson 8 “Provide fast and quality feedback”
    11. 12. Lesson 9 “Regularly reassess you test process”
    12. 13. Lesson 10 “Explore, learn, innovate and improve constantly ”