2. Test StrategyTemplate
■ Reminder
■ Where Quality begins
■ Why?
■ Test Pyramid
■ TestTypes
– Unit testing
– API / ServiceTesting
– AcceptanceTesting
– RegressionTesting
– ExploratoryTesting
■ Discussion & Questions on test types
3. Reminder (Agile document)
“To Constantly DeliverWorking Software that
Meets Customer’s Requirements by means
of Providing Fast Feedback and Defect Prevention,
rather than Defect Detection”
“In SCRUM (agile) 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 (or maintaining old)
products”
- No code may be written for a story until we first define its
acceptance criteria/tests
- A story may not be considered complete until all its acceptance
tests pass
4. Where Quality begins
■ Requirement
– Must to be clear (and understood) to all team members
■ User Stories
– Should be INVEST (Independent, Negotiable, Valuable, Estimable, small & Testable)
– Understanding the [benefit] part of user story
■ Acceptance criteria
– possibly the most important element which encourages communication with
different members of the team
■ Development
– Engineers working together to produce a working software…
5. Why?
Most common cause of software development failure is due to
unclear requirements and different interpretation of requirements by
different members of the team
7. ■ IsolatedTests (unit , component, Integration)
– Contract and Collaboration testing strategy
■ API / ServiceTest
■ AcceptanceTest
■ Regression / System / UATTest
■ ExploratoryTest
Type of tests?
8. UnitTesting (IsolatedTests)
■ WHY: To ensure code is developed correctly
■ WHO: Developers
■ WHAT: All new code + re-factoring of legacy code as well as JavaScript unitTesting
■ WHEN:As soon as new code is written
■ WHERE: Local Dev + CI (part of the build)
■ HOW: Automated
9. API / ServiceTesting
■ WHY:To ensure communication between components are working
■ WHO: Developers /TechnicalArchitects
■ WHAT: New web services, components, controllers, etc.
■ WHEN:As soon as newAPI is developed and ready
■ WHERE: Local Dev + CI (part of the build)
■ HOW: Automated, Soap UI, Rest Client
10. AcceptanceTesting
■ WHY:To ensure customer’s expectations are met
■ WHO: Developer / SDET / ManualQA
■ WHAT:Verifying acceptance tests on the stories, verification of features
■ WHEN:When the feature is ready and unit tested
■ WHERE: CI /Test Environment
■ HOW: Automated (Cucumber)
11. RegressionTesting (Integrated test✶)
■ WHY:To ensure the whole system works when integrated
■ WHO: QA / SDET*/ BusinessAnalyst / Product Owner
■ WHAT: ScenarioTesting, User flows and typical User Journeys
■ WHEN:When Acceptance Testing is completed
■ WHERE: X Environment
■ HOW: Automated (e.g. WebDriver), Manual regression testing
* Software Development Engineer inTest
✶ Integrated test is any test whose result (pass or fail) depends on the correctness of the implementation of more than one piece of non-trival behavior
-J. B. Rainsberger
12. ExploratoryTesting
■ WHY:To use knowledge and experience to predict where and under what condition the
system might behave unexpectedly
■ WHO: QA /Tester / SDET/ Developers / Business Analyst / Product Owner
■ WHAT: System, Domain knowledge,Testing experience
■ WHEN: During development and / or after all automated test passed
■ WHERE: X Environment
■ HOW: Exploratory the SUT (system under test)
14. ■ IsolatedTests (unit , component, Integration)
– Contract and Collaboration testing strategy
■ API / ServiceTest
■ AcceptanceTest
■ Regression / System / UATTest
■ ExploratoryTest
List of test types we may want to discuss
Notas del editor
User story: as a [role] – I want [feature] – so that [benefit]
Each Acceptance Criteria should have a number of Acceptance Tests presented as scenarios written in Gherkin format, e.g.
The benefits of the tests
As a developer- behave as if you don’t have any QA in the team or organization. It is true that QAs have different mindset but you should test to the best of your ability.
You think you are saving time by quickly moving on to the next story, but in reality, when a defect is found and reported, it takes longer to rectify the issue than spending few minutes making sure the feature works well.
Any new code and/or refactoring of legacy code should have appropriate unit tests that will be part of the unit regression test.
Automated acceptance tests are usually written in Gherkin language and executed using a BDD tool such as cucumber.
I have to mention that unit testing you code don’t detect errors in your code but also in designs
It helps you improve your implementation.
Full Regression: not more than 1 hr
Smoke test: not more that 15 min if we have them
Not expecting to find many defects. Their purpose is only to provide feedback that we haven’t broken major functionality. There should be a very little amount of manual regression testing
Full Regression: not more than 1 hr
Smoke test: not more that 15 min if we have them
Not expecting to find many defects. Their purpose is only to provide feedback that we haven’t broken major functionality. There should be a very little amount of manual regression testing
As a developer- behave as if you don’t have any QA in the team or organization. It is true that QAs have different mindset but you should test to the best of your ability.
You think you are saving time by quickly moving on to the next story, but in reality, when a defect is found and reported, it takes longer to rectify the issue than spending few minutes making sure the feature works well.
Any new code and/or refactoring of legacy code should have appropriate unit tests that will be part of the unit regression test.
Automated acceptance tests are usually written in Gherkin language and executed using a BDD tool such as cucumber.