I had suggested introducing the context-driven approach and the reply was “How can we apply it in our project?”. As a result, below write up! Maybe not all but in most cases, the context-driven approach makes the testing interesting, fun, challenging and revealing useful information
I have used this approach (not fully) in two of my (short) assignments, and it made my testing, interesting, fast and useful (which most of the “testing businesses” are looking for).
About this document
Purpose:
This document explains how to use the context-driven approach in testing or in an agile project. The document explains the basics and does not get into the details as, the purpose is, to begin with, the context-driven approach. The approach is explained from tester’s view (as to me tester’s role seems more parallel to this approach) however, can be customized for the overall project.
Assumption:
The document assumes, the reader has the basic understanding of the context-driven approach/context-driven testing.
By: Anita Gujrathi
Practices
This section explains a few basic practices a team can start with to use the context-driven approach in testing or in a project
1.Understand the context
One of the possible ways to understand the context of a project/requirement is to ask questions. Below are the few possible questions.
1. May I ask questions?
2. What problem is this requirement trying to solve?
3. Who are the users? In which environment users will use the application?
4. What is the tester’s role? i.e. test objective
5. What are the risks?
6. What kind of data will be processed?
7. Who are the other stakeholders?
8. What is the HW and SW requirement?
9. What tools are available to support the testing
10. What effects might new feature have on the existing functionality?
Let us consider the “Attachment” feature for audit reporting application. Assume below are the answers to some of the questions above.
1. Purpose of the feature: Currently users need to type in a lot of text while creating the report. To minimize this typing effort, the attachment feature is required. This will allow adding, editing, deleting and viewing the attachments as per the role. Check the latest version of the application to understand the current behavior.
2. Tester’s Objective: To find the functional/UI defects of the “Attachment” feature
3. Users: Education Institute’s auditor will use this application. These officials visit minimum 7-10 education institutes a day, review the institute and provide their report.
4. Tools: SnagIt, Google, Mobile Simulator
5. Data: Different file formats, Description of data? What are the frequently used formats?
6. Risk:
Business Risk: Handling different supported, unsupported file formats
Project Risk: Mobile emulator application is very slow and gets hang frequently, delayed build deployment.
In a project, not necessarily all the questions will be answered or all the answers will provide complete/required information. As we move further information unfolds.
2.Create a feature map
Let us create a feature map based on the answers and other information available to us. Please refer the excel sheet
1. Create an outline of the feature i.e. high-level idea of the feature. Here Add, View, Edit, and Delete are the core operations of the Attachment feature
2. Now, put details about how these operations work. Refer the sheet “Function details”
3. Let’s add test ideas for these functions. Refer the sheet “Test Ideas”
4. Note: There are tools available to create the maps but keeping the restriction in mind excel sheet is used. Creating a map in the excel is a challenging and time-consuming.
5. The map can be extended as per the need and information available. For example, risk section can also be added.
6. Update the feature map if any new information is received from dev/BA/Product Owner
Benefits of the feature map
1. Helps to visualize the information. (Most of the times, visualization effective over reading)
2. Helps to explain feature understanding to other stakeholders, generate ideas, discuss queries
3. BA, Product Owner suggestions may help to decide the depth of testing, priority.
4. Providing more details may help in pointing requirement gaps
5. Test ideas in the map can be converted to test scripts
6. If any tricky scenario comes up while creating the map, can be handled in the development cycle
7. Can be helpful in tracking progress, coverage
8. More ideas can be added as we move further
Applying in My project
This section explains how above techniques can be incorporated in my project.
1. Testers can come up with their questions and the feature map
2. Discuss with the offshore team
3. Revise the questions and map if needed
4. Share the map and the questions during the sprint planning meeting to discuss with other stakeholders like Business Analyst, Product Owner
5. Instead of, applying this approach to all the stories in a sprint, the team can experiment with few stories in the beginning.
Challenges/Factors affecting
1. To get the different member of the project team to discuss the project/feature with a common shared goal
2. Geographically distributed team: This can be overcome by scheduled meeting
3. What if dev/testers have the difference in opinion? This can be documented as a query and checked with BA/Product owners
4. Generate ideas: Providing knowledge about business/users/environment in which application is used
5. Train testers to ask questions about the product or requirement.
6. Train other stakeholders on expecting the questions from testers
References & Inspirations
http://context-driven-testing.com/
http://www.satisfice.com/
http://kaner.com/
http://www.developsense.com/
http://testerstories.com/author/Administrator/
http://karinatester.blogspot.com/
http://testerstories.com/author/Administrator/
