Key Points
This article will explore the distinctions between classical and agile testing, examining the concept of continuous testing through Brian Marick’s explanation of the quadrant. We will also discuss the responsibilities of each actor, including those of the quality manager. In conclusion, recommendations will be provided.
WHY AN AGILE TESTING PRACTICE
The testing approach we present to you has different purposes from traditional methods, which is why we call them agile tests.
Definition
Ourdefinition of agile testing: Agile testing aims to share the responsibilities of testing by automating as much as possible a collaborative specification written in the form of examples in order to deliver a satisfactory product for the development team but especially for our users.
HOW TO SET UP AGILE TESTING
THE NEW CHALLENGES OF SOFTWARE TESTING: TOWARDS A NEW WORLD
Classic approach
- Test for anomalies
- Plan test campaigns
- Specialize in testing professions
Agile approach
- Test to Specify
- Continuous Testing
- Sharing Testing Responsibilities
CLASSIC TESTING PYRAMID VS AGILE TESTING PYRAMID
CONTINUOUS TESTING
Our goal is to give maximum visibility on the progress of the product and to be able to refine and/or evolve the needs of users as quickly as possible.
So we need to have elements Done as quickly as possible, testing is part of our definition of Done.
Testing Strategy and Risk Analysis: Brian Marick’s Quadrants
Dial n°1:
- The first quadrant represents Test Driven Development (TDD)
- The process of writing tests before code helps developers design their code well. Unit and component tests are automated and written in the same programming language as the application.
- → In-house quality
Dial n°2:
- Testing in Quadrant 2 also supports the work of the development team.
- With agile development, these tests are derived from examples and they describe the details of each User Story.
- Key users use these tests to define the external quality of the product and usually participate in their writing.
- → External quality
Dial n°3:
- During the development process, several scenarios may arise:
- One of the examples used is wrong.
- The Key User forgot a feature
- Or a business rule;
- One of the examples provided by the client is misunderstood by the team;
- Etc.
- Quadrant 3 testing comes into play to address the above issues. The principle is to mimic the way a real user works with the application; These are 100% manual tests.
Dial n°4:
- The application code must take into consideration certain non-functional requirements such as performance, security, or interaction with other systems
- Technical and critical tests of the product must be considered at each stage of the development cycle and above all not wait for the end of a release.
- In many cases, these tests should even be done before functional testing.
TESTING, A SHARED RESPONSIBILITY
The traditional approach promotes the separation between testing and development activities.
On the contrary, agile methods favor an “extended team” approach
The tester is part of the Dev Team
Sharing of responsibility involves two conditions:
- A common, known and shared vision (involvement from the beginning)
- Knowledge of end-users (complement/continuity of UX practices)
DO WE STILL NEED THE TESTERS?
The activities of the tester change with the changes that IT undergoes and initiates.
We need specific skills around testing: the role of Quality Analyst
RECOMMENDATIONS
- Integrate testing by design.
- Empower stakeholders to test.
- Think of testing as a collaborative activity
- And why not use testing to produce specifications and useful code?
0 Comments