Exploratory testing (in agile projects)

Imagine the following scenario: You are developing the "CarConfigurator" software for configuring new cars for an automotive manufacturer. You have already automated all regression tests, both module tests, integration tests, acceptance tests and even the end-2-end system integration tests. Everything runs in an exemplary Continuous Integration environment and is automatically tested through with each new release. Actually, it should now be ensured that no new errors can creep in at your end. Nevertheless, "obvious" - not to say "stupid" - errors show up in productive operation. For example, a changed text is only partially displayed, and a button has such inappropriate colors that the label is difficult to recognize. This carries the risk that the user will also associate the poor quality of the software with poor quality of the new cars. You can avoid this with exploratory testing: By testing with experience-based glasses, many obvious, but also hidden and unusual errors are found before release.

In systematic testing, one follows the previously created test plan. With precise plans, there may be too little room to react to new findings. If everyone is just reacting, there is a risk of no longer following a common strategy.

Session-Based Test Management (SBTM) offers the possibility to react to new findings on short notice and to develop a common strategy at the same time. It is usually called Session-Based Testing. SBTM relies on the experience of agile team members and assumes that they are good at making assumptions. In our example with the vehicle configurator, such a conjecture could arise from the fact that there have often been problems with invisible texts in the info boxes of an equipment package. These assumptions are condensed into clear goals for the execution of a session, the test charters. Test charters provide time-constrained, intensive testing activities with clear test objectives and, therefore, a clear sense of purpose. Test charters are guideposts for the testers as to which test element they should investigate and what specifics should be considered. It is easiest to compare the test charter with a clear mission for the session.

In our example, the test charter formulates the goal of describing new text box elements for equipment packages in the vehicle configurator with overlong texts. This test charter is taken over by a developer in the test execution, who knows which GUI elements have been newly created in the framework, together with a tester within a period of 90 minutes.

In this way, the supposedly random experimentation on the test object becomes a targeted experiment (= explorative test) in a given time frame (= test session). Finally, the reactive approach of explorative testing can be promoted in which test managers, development team members or other interested persons jointly discuss the essential findings in a debriefing at the end of a session and develop further ideas on how to proceed. And just like that, experience becomes valuable knowledge again!

Strictly speaking, tours are one of the possible creativity techniques that use metaphors to find test charters to design test sessions. For example, the analogy of exploring a city is drawn. The testers are asked to approach the exploration of the test object as if they were visiting an unfamiliar city. They should make sure that they get to know the main sights. The testers usually start by looking at a city map together. The "tour group" decides which parts of the city are interesting.   Once the parts of the city are decided, send the individual interest groups to different areas.
In the evening, the excursionists meet over a drink and share what they have experienced. Inspired by this, the group plans the next steps and considers which parts of the city should be explored next, or looked at again more intensively.
With the help of this "visualization" of the test object as a city and description of the test tours, it becomes easy to derive exploration goals, i.e. test charters, and to plan meaningful sessions for explorative testing.

In exploratory testing, ideally the whole team or people outside the team can participate. The focus here is not explicitly on participants with testing expertise. In this way, many test charters can be followed in the same period of time and all team members also get to know the entire application from new perspectives. Since experience grows particularly well together, it is very proven to repeatedly explore the test charters in pairs or even larger groups.

imbus supports you with trainings, in which we teach your team members the mentioned techniques in a comprehensible and practical way.

We can also support you in the daily doing by providing your team with an experienced quality engineer who can prepare these explorative tests and coordinate their execution.

Would you prefer to tackle the topics yourself, but be guided by an experienced coach?
Please contact us!