Top 8 Things to Consider for Your Agile Testing Strategy

  • Post author:
  • Reading time:4 mins read
You are currently viewing Top 8 Things to Consider for Your Agile Testing Strategy
Top 8 Things to Consider For Your Agile Testing Strategy

Here are the top 8 things to consider when developing your Agile testing strategy to enable you to continuously deliver a quality working Product Increment at the end of every Sprint

1. Testing in not a phase

Testing is not a phase that happens at the end of a project and it’s not a phase that happens at the end of a sprint or at the end of a story. Testing is an ongoing activity that happens throughout and there is no distinction between programming or coding and testing. It’s just quality development.

2. Testing is everyone’s responsibility

Testing is everyone’s responsibility. The entire team works collectively to develop a quality product. Most of the automation is done by the people writing the code using an approach known as Test Driven Development or Test Driven Design (TDD). This includes unit, integration, component, and system tests. These tests verify that the application works as intended.

Functional and acceptance tests are written by testers, analysts or the business using an approach known as behavior driven development (BDD) or acceptance test driven development (ATDD). These tests verify that the system works as expected per the requirements.

3. Testing starts on day 1

Since we are trying to build quality-in instead of checking for quality later, testing should start from day 1 and is everyone’s responsibility, not just the testers.

4. Do automate all scripted tests

Any tests that can be scripted, can and should be automated. If we can map out a series of preparatory steps, followed by an action that results in an expected value or response, then this is a test that can be automated. Doing it manually is time-consuming, exhausting, inefficient, and not sustainable.

5. Developers are the ones doing most of the automation

Testing is everyone’s responsibility, but most of the test automation at the unit, integration, component and system tests are the developers’ responsibility as these tests are part of building a quality product that works as intended.

6. Do use executable documentation

Requirements and tests are just two sides of the same coin. You can’t have a user story or requirement without an acceptance criteria (test). These two meld into executable specification. Using gherkin syntax (given, when, then) we can represent requirements using examples and create specifications by examples that become automated acceptance tests. These tests should be automated by testers since they verify that the product works as expected.

7. Do not automate functional testing via the UI

Automating testing via the UI should not be used for exhaustive functional testing. Lower level tests are better suited for that. UI tests tend to be long running and very brittle and should be kept to a minimum.

8. Save most manual testing for usability and exploratory testing

Most manual testing should be spent on Usability and Exploratory Testing. These types of tests are non-scripted and thus cannot be automated. These tests need human interaction, observation, analysis, and intuition.

Also check out the entire Agile Testing series: