How to build a QA Mindset from scratch - Chapter 3 - How to build exploratory testing

Do you know that exploratory testing started at concept of building documentation?

Reading is one of the inherent work that Quality Assurance Engineers have to do daily. Let’s think about some examples of the work to be done daily:

• Starting from the daily scrum ceremony

• Read and add comments to update tickets

• If you have a refinement about the tickets to be refined,

  • add or ask for details for the acceptance criteria

• read or send emails

• read documentation to support you in your test activities, such as analyzing and designing the test cases, defining a test plan, and implementing the test cases

• Code reviews about the merge requests for automation or even read your developer’s code (Why not?)

• After reading technical or business documentation, you can identify that is not clear or needs more details, or even more, you identify an issue in the documentation…

Wow. What a long list right?

Touching the last point, do you know that is possible to identify issues in the documentation?

Yes, it’s possible, even more possible if you apply an exploratory testing technique or risk-based testing, two techniques that walk hand in hand when the intent is to find issues as early as possible with a short amount of time.

So what is exploratory testing?

Is an Experience-based Test Technique where the test cases result from:

• Engineering skills (mostly done by the QAE)

  • Detail-oriented, curious, communication skills, efficient and proactive, are some of them.

• Required domain knowledge and experience with similar applications and technologies

  • Compared to similar products, and platforms previously worked, is possible to start prioritizing which are the most important to start testing with.

• Intuition to explore the product and discover issues.

  • If you have good product knowledge, you can review the documentation and even share previous results from similar products. This is shift-left, start testing earliest possible.

I believe this is an exercise for all engineers, not only QAEs, to start to have a QA mindset, looking at things like a child looks, always curious about what you are seeing, and asking, there are no stupid questions.

In Exploratory testing, informal tests are designed, executed, and logged, without pre-written test scripts or formal test plans. The evaluation is dynamically made during the test execution.

•Exploratory testing is most useful when there are few or inadequate specifications or significant time pressure on testing.

•Exploratory testing is strongly associated with reactive test strategies

Due to this type of test strategy - the tests are designed and implemented, and may immediately be executed in response to knowledge gained from prior test results. Exploratory testing is a common technique employed in reactive strategies.  An appropriate test strategy is often created by combining several of these types of test strategies - risk-based testing (an analytical strategy) can be combined with exploratory testing (a reactive strategy).

Why it’s important?

• Allows QAEs to identify issues that may have been missed through scripted testing, as they can adapt their testing to the current state of the product and follow their experience with the product;

• Exploratory Testing can improve test coverage and effectiveness;

• Exploratory Testing can help reduce test cycle time and costs.

How is the process of Exploratory testing?

Exploratory Testing is an iterative process, and the steps described above may be repeated multiple times as needed.

The engineer may also adjust the scope of the test or the test scenarios based on their findings during the test session.

• Test Design – High-level plan created with the scope of the test and includes any risks or likelihood that could impact the test

• Test Execution – explores the feature/product in a flexible and unscripted way, using experience and intuition. Also can use it if there exists any available documentation.

• Issue Reporting – defects opened and registered on the test management tool – JIRA with steps reproduce and evidence ( logs and/or screenshots)

• Test Analysis – analyzing the results to help identify any patterns or trends in the issues obtained. Prioritize the issues by severity and impact.

• Retesting – Once the issues are fixed, needed to be retested, and check also if no new issues are added by testing the feature ( previous tests to be executed!)

• Documentation – Once the tests are executed need to create a report with any recommendations, issues reported or observations to be improved.

So how can you start using exploratory testing? If you never use it, take the correct journey and use several techniques, choose one or more that makes sense to your daily work. Below are some examples.

I have used this technique for a while, I’m old school, and I use a notebook and pen, to design diagrams and flows that give me an overview of the product and service that I’m testing. My biggest challenge was to prepare an Exploratory Testing Technique Workshop, I did it and offered a tutorial for those who wanted to apply it. So let’s start ;)