Testing Agile

I recently attended an Agile Testing course presented by internationally renowned Agile coach and process consultant Janet Gregory. Co-author of “Agile Testing – A Practical Guide for Testers and Agile Teams” with Lisa Crispin; the course focuses on the role testers’ play in agile projects and describes an Agile software development iteration from the viewpoint of a tester.

Two developers who work at KRS

Janet has helped introduce agile practices into organisations as tester or coach, and has successfully transitioned traditional test teams into the agile world. Her primary focus is working with the business users and testers to understand their role in agile projects. She practices Lean principles, Extreme Programming, and SCRUM. Her experience as a QA Manager both in traditional and agile environments gives her an understanding of the issues faced by most teams. As a tester at KRS, I am responsible for all aspects of the testing process as well as the writing of user stories, scenarios and use cases for new requirements. Janet’s testing methodology demonstrates not only the value of testers in agile projects but our contribution in delivering a continuous stream of business value.

Janet is extremely passionate about promoting agile quality processes in software development. As an active member of the Agile Testing community as well as on the organising committee for Calgary Agile Methods, Janet works closely with the Software Quality discussion group in Calgary in providing a focal point for the use of agile methods in software development. Janet helps testers find their niche on agile teams as well as the teams understand the testing process.

The Course

The course covered an introduction to how Agile fits into the testing process, the practice around release planning simulation and test planning, and finally an exercise where we worked through an actual iteration simulation.

As we went through the course material I discovered that a lot of the content covered has already been implemented in our team which reaffirmed that we, as a team, and company, are on the right track.

I thought I’d share a few examples of how we’ve already applied these processes into our own implementations:

  • Breaking the requirements down into small stories and tasks;
  • Prioritizing the stories with the Product Owner and not allowing the Product Owner to dictate the priorities;
  • Fixing bugs as they are discovered;
  • Testing through the Global User Interface;
  • Doing manual unit tests;
  • Joint testing sessions on new features with the client;
  • Everyone in the team is responsible for the quality of the feature.

My Experience

I found the course fascinating and discovered that there were still many things about the Agile testing process that I did not personally know – I couldn’t wait to return to work and begin implementing this newly acquired knowledge.

There were also certain aspects of the course that stood out for me and that some are already in practise here at KRS:

  • Automated Unit Tests – currently we do our planning from a TDD (Test Driven Development) perspective gathering requirements for RFC documentation and then writing user stories and scenarios. Breaking the user stories into tasks and then further dividing these tasks into the different scenarios helps with the development of effective unit tests. Implementing the automated unit test at task level makes for simpler implementation, coding and maintenance.
  • Testing as an Activity and not a phase – meaning that test tasks are drawn up before any development starts to assist the developer with the coding.
  • Tester and Product Owner Pairing – Testers and Product Owners pair up in order for the tester to ensure that the results of the tests performed are what the product owner wants. This also ensures that the feature does what the product owner expects it to.
  • Tester and Developer Pairing – Testers and Developers pair up when new features or stories are being developed in order for the developer to become ‘tester infected’. The developer then knows what the product owner wants and how they need to code to ensure that the product owner meets the requirement.
  • Stories are written with testing in mind – The tester needs to be included in the requirements gathering process; input as to how new requirements can be tested practically is essential.
  • Good Coding-Testing Practices – Tests should not contain logic, as the logic in the test would need to be tested to confirm the accuracy. Tests should also be seen in the same light as code, therefore it should have standards; it should be clean and should not have parts of it that has been commented out. Tests should be refactored when new features or functionality has been added to the system. Small pieces of code needs to be tested independently (a test should not be dependent on other tests) before end-to-end testing is done. Tests must run green so when tests are failing they should be fixed immediately.
  • Test Suites – Creating test suites (i.e. unit tests repository) are most beneficial.
  • Exploratory Testing – Testers need to do exploratory testing as the outcome of these tests could prevent the return of potential errors.
  • Regression Testing – 100% of regression tests must pass, all the time. The tests should be used as executable documentation and be stored in a regression suite.

About the Author:
Melissa Carelse is a Tester at KRS and is responsible for all Agile Testing processes applied on her project. When she’s not testing she’s cooking and baking agile.