Context gives us understanding. It gives us direction. And eventually it guides our actions.
Determining the context is crucial. Context gives you clarity over things. Just like how without knowing the blueprint you cannot actually repair an old mansion similarly without knowing the context you cannot create any impactful testing solutions.
Before I delve into the details of how we’ve implemented Context Driven Testing for an international customer using the Scaffolding Framework, it’s vital that we understand what Context Driven Testing is all about.
Just as gardeners rely on different tools for pruning plants based on their unique characteristics and needs, testers also require varying testing solutions to adapt to the changing context of different projects.
In gardening, different plants have different growth patterns, sizes, and types of branches. To effectively prune them, gardeners use specific tools such as shears, loppers, or pruning saws, depending on the plant’s requirements. This tailored approach ensures that each plant receives the appropriate care and attention it needs for optimal growth and health.
Similarly, in software testing, different projects have varying contexts, including factors like project scope, requirements, technology stack, and user base. Testers must adapt their testing strategies and techniques accordingly to address the specific challenges and goals presented by each project. Just as gardeners select the right tools for different plants, testers select the appropriate testing solutions, methodologies, and frameworks that best suit the context of the project at hand.
By recognizing the importance of context in both gardening and software testing, we understand that a one-size-fits-all approach is insufficient. Instead, a flexible and adaptable mindset is required, allowing testers to leverage the right testing tools and techniques to achieve the desired outcomes based on the unique context of each project
What is Context Driven Testing?
Context Driven Testing is an approach focused on understanding the context of a project by asking important questions (What, How & Why) and exploring the software with a clear objective.
It sounds like a lot of effort, doesn’t it ? But trust me, it surely pays off!
And I will show you how.
But for now, let’s focus on this question.
Why is Context Driven Testing (CDT) Necessary?
- It focuses on Bug prevention with the right questions asked at the right time and with a shift in mindset.
- Software is developed by people hence people set the context. (One of the important beliefs in CDT)
- Project context is understood first and then the suitable test strategy is created.
- Important Questions in CDT : What, How , Why
- Believes testing is a shared responsibility of entire team instead of treating testers as gatekeepers of quality
- Test execution focuses on exploring rather than sticking to executing a finite set of steps from Test Cases.
How to implement CDT ?
We came up with an evolving framework to support testers to implement CDT for a large international enterprise project. We call it Scaffolding.
What is Scaffolding?
Scaffolding, also called scaffold or staging, is a temporary structure used to support a work crew and materials to aid in the construction, maintenance and repair of buildings, bridges and all other man-made structures.
Now the framework, I am going to show you later in this blog is the one we worked on in the case of the project that we’re testing for the international client. But that doesn’t mean that it’s a one-size-fits-all or in this one-framework-fits-all solution. As your context changes you need to improvise.
But what remains the same is the four quadrants. These form the basis of all scaffolding frameworks you’re going to use.
Let’s see what we did in each Quadrant!
- Context Understanding: We focused on answering 5 questions in this quadrant to gain a holistic understanding of the User Story being picked up :
-
- My understanding about the requirements?
- What is the Business impact?
- What is the Technical implementation of this story?
- Why this story has been picked up now?
- How is the Customer/client/Organisation managing now without this story?
Below is a sample of how we answered the above 5 questions for Context Understanding :
- Strategising:
- Refer to Test Strategy Models (COP FLUNG GUN, FAILURE, SFDiPOT etc)
- Come up with possible Test Charters and relevant test ideas
- Layer them under
- Shallow: Covers only the Acceptance Criteria or the most obvious scenarios
- Practical: Covers Acceptance criterias, edge cases, negative flows, error cases, integration flows , Business impact , Minimum required browsers and device coverage etc.
- Deep coverage: Covers the Shallow and practical scenarios alongwith What If scenarios, Extreme use cases, disfavoured scenarios, Third-party integrations,User persona,Wider device & browser coverage,End-to-End Testing,Adherence to Web3 standards,Thorough regression
- Get on a call with PM/DM to confirm the Context understanding and agree upon the coverage to be achieved in the user story. Each user story will have a different priority and hence the coverage would vary for each user story.
The image below shows how we identified and layered the Charters:
- Execution:
-
- Go through the PRs and identify the tests in Unit/Component/Integration levels and update the Test Design Subtask :
The below image shows a test design subtask after updation:
-
- If we are unable to identify tests, sync with devs and the complete the test design. (Add test design link)
- SBTM/Pair Testing/Mob Testing sessions for the identified Charters/Epics/Release
- Add session notes and close the Test charters subtasks.
Session Notes: Below is the sample of how session notes look like. And it contains test ideas, observations, and whether or not there are opportunities for further testing of certain elements.
- Influencing :
-
- Add COCs by tagging relevant stakeholders in the tested User stories
Close out Comments: Below is the sample of the closing statement we offer with the user story. So here we can see that it was a sort of accessibility testing where the scope and the impact of the testing is explained in detail.
-
- Update and publish Confluence pages containing the Test Design summary on Epic level
-
- Go through the daily notes, identify the points to be discussed in retro and initiate the discussions.
- Connect with PM/DM : Give them a review of previous sprint activities and give them a walkthrough of the achieved test coverage
Mind Map for capturing our progress and Daily Activities:
We created a process map that involved a mind map to assess the readiness of each sprint ceremony and daily testing activities, providing an overview of their current status
Now that we’ve learned how the framework appears and works let’s reflect again on the essential question:
Why Scaffolding?
- It is a structured approach and a process to have better Context understanding, better collaboration with teams.
- Helps in coming up with better test design and test coverage (Shallow,medium and deep coverage).
- Helps in being prepared for each and every ceremonies
- Scaffolding helps in approaching the four most important quadrants i.e. : Context Understanding, Strategising, Influencing, Execution in a structured way.
- Helps in communicating and mitigating the risks
- Helps in influencing the stakeholders and bringing more visibility to the testing activities.
Conclusion:
So we now know that context understanding makes way for better strategising and execution. And also the scaffolding framework is definitely an enabler which helps us establish better communication with the involved parties.
12