Session Based Testing – How to serve the best results?

As software testers, we used to test our modules as a whole. To structure and timebox these tests, we can simply divide our modules into manageable session and carry out the complete testing process within those smaller portions which helps in rapid defect discovery!

Session Based testing is a common exploratory testing technique, that divides the testing modules into multiple sessions of equal duration and performs exploratory testing on top of each session.

Testers can use this to create the test plan and strategy along with the test reports for each session of the exploratory testing.

“The strength of Whole is the sum of its stronger parts.”

Aristotle

Before starting with session-based testing let’s hear about exploratory testing too!

“Exploratory testing is a catch-all term for a testing method that allows testers to explore, learn, and analyze a program based on their own intuition and insights.”

Now, let’s talk about the components of SBTM

Components of Session-Based Testing:

It is built around six fundamental aspects. They are:

Mission:

It outlines the session’s goals, the modules which fall under each session, and the length of each period.

Charter:

It defines the objectives of each period, including the modules that are planned for testing during that specific period. In essence, session planning falls under the responsibility of the testing team.

Session:

A session can be continuous and uninterrupted testing for a specific and brief period. Sessions are typically based on the charter, but this does not limit the tester’s ability to experiment with new and creative methods of testing.

It accounts for the summary and status of the testing sessions, which may include the Charter, strategy, approach, testing types, areas under test, test cases prepared by the testers, bugs explored, the time required, comments (if any), and so on.

Debriefing:

It includes all of the testers involved in the SBT. During this period, each tester briefly describes his or her method of testing. The PROOF concept is generally the focus of debriefing.

P →Past: Activities done by the tester during the session.
R →Results: Achievements of the session
O →obstacles: Problems faced during the session.
O →Outlook: Plans for the next session.
F →Feelings: Tester’s opinion and reviews, about all these.

Parsing:

A standardized report that aggregates all session reports and reports overall defects and other issues discovered during SBT.

How to run an SBTM?

There are numerous ways to explore and use the SBTM, but it produces the best results when two testers or a tester and a developer run the period together, where each participant runs the same scenario in different environments and then discusses observations/insights at the end of the session

1. Create a time-boxed session (60-120 minutes)
2. Set the goal to guide the session.
3. Create the scenarios you want to execute.
4. Debrief the observations.
5. Discuss observations with the relevant committee.
6. Log defects based on the discussion.

In addition to the steps outlined above, I recommend writing a session report that includes the information that will be discussed during the debriefing period.

By documenting this information, everyone will understand why we are holding this period, how long it will take, and what the main findings will be.

A typical session report might contain the following:

1. Link to feature/user story
2. Date and time started
3. Mission statement and goal.
4. Testers/developer names.
5. Task breakdown
6. Test environments
7. Test scenarios.
8. Potential defects found.
9. Test notes.

How does SBTM fit in agile projects?

We can use SBTM for both small and large Agile projects because of its flexibility. The team can start using SBTM on each user story to gain a thorough understanding of the product’s requirements and functionalities. The team can begin writing high-level test cases based on the observations and issues generated at the end of these sessions. With minor modifications, the same approach can be applied to large complex agile projects.

Approach to incorporate SBTM in agile projects:

1. Create acceptance criteria for each user story and identify business flows to test (Manual and Automated).
2. Determine the story’s risk and impact for each of these scenarios.
3. Once the risks and business flows have been identified, it is time to create the technical test flows that will be used as input to the SBTM process.
4. When an exploratory testing session is finished, all documentation generated from the session can be attached to the specific story, informing the team about the session’s details, including the defects and issues discovered.

Happy Testing!

To learn more about Quality Engineering topics visit – https://engineering.rently.com/quality-engineering/

Get to know about Rently at https://use.rently.com/