Testing Strategy —1/3— explained

The purpose

Reader’s guide

Testing Strategy

Rules

  • No code may be written for a story until we first define its acceptance criteria/tests. This is the entry condition of the developer’s space, as part of the definition of ready (DoR).
  • A story may not be considered completed until all its unit tests and integration tests pass, the code has been reviewed by peers. This is the exit condition of the developer’s space, as part of the definition of done (DoD).
  • A story may not be considered completed until all its acceptance tests pass. This is the exit condition of the development team’s space, as part of the definition of done (DoD). This includes automated and manual tests.
  • A product increment may not be considered delivered until all tests pass in the continuous integration pipeline. This shall also include manual exploratory tests, as part of the acceptance criteria. This is the definition of release and deployable (DoRD).

Quality Assurance

  • QA is a set of activities intended to ensure that products satisfy customer requirements in a product with a certain level of quality at every stage of the process aiming to deliver a software to production.
  • QA is the responsibility of everyone, not only the testers. QA is all the activities we do to ensure correct quality during the development of new products.
  • There may be a dedicated member of the team to assume that QA role to ensure that the Testing Strategy is executed accordingly.

Software Quality Life Cycle

The Test Pyramid

The “Test Pyramid” is a concept developed by Mike Cohn.
  • High level end-to-end (around 10%)
  • Mid-level integration tests (around 20%)
  • Low-level unit tests (around 70%)
The anti pattern vs the ideal automation pyramid

Define the 5WHs

Unit Testing

  • WHY: To ensure code is developed correctly
  • WHO: Developers
  • WHAT: Business Code
  • WHEN: new code is written
  • WHERE: Local Dev + CI
  • HOW: Automated

Integration Testing

  • WHY: To ensure a group of components is working together
  • WHO: Developers/Tech Leaders/Architects
  • WHAT: web services, components, controllers, database, message bus, etc.
  • WHEN: a new component is developed
  • WHERE: Local Dev + CI
  • HOW: Automated

System Testing

  • WHY: To ensure the whole system works
  • WHO: QA/BA/PO
  • WHAT: Scenario Testing, User flows and typical User Journeys, Performance and security testing
  • WHEN: the codebase is changed
  • WHERE: CI + Staging Environment
  • HOW: Automated, less manual tests

Acceptance Testing

  • WHY: To ensure customer’s expectations are met
  • WHO: QA/PO/End-users
  • WHAT: Verifying acceptance tests on the stories, verification of features, performance, sanity
  • WHEN: the feature is ready
  • WHERE: CI + Staging Environment
  • HOW: Manual, some automated tests

Development

Developer Testing

Automated Acceptance Tests and Non-functional Testing

Regression Testing

Sanitary Testing — Should be no more than 15 mins

  • Product Search
  • Product Review
  • Purchase Item
  • Account Creation / Account Login

Full regression pack — should be no more than 1 hour

UAT and Exploratory Testing

Unlisted

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kong To

Kong To

Developer, Coder or Craftsman, but code quality matters. Technical writer @wesquad @wemanity