Context-Driven approach

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/

Everybody is doing because Everybody is doing

Since past few years, often I feel “Everybody is doing because everybody is doing and most do not know why they are doing”. Most of us are afraid “what if I do not do this, I will stay behind”

Are we living a very very Human-Centric life?

On the occasion of this Independence Day, let’s free ourselves from the unnecessary human-centric thoughts and live a life which looks at the self, this environment, ecology and other forms of life

YES, it is difficult …….

So

Realize and accept, I am the one who is responsible for my life. (This may help in making a better choice next time :))
Let’s not be serious all the time about life
Create an atmosphere within us which will take care of the atmosphere around us

LET’s help SELF and so each other to feel pleasant, happy…… within and so outside

If we make ourselves a happy pleasant, eco-friendly life, it is the BEST gift we will give to the generation next. This is important, as we got something from our previous generation we ought to do something USEFUL for the generation next

YES, again it is easier said than done ...... but worth giving a try isn’t it?

Reference & Inspiration
http://www.satisfice.com/blog/
https://isha.sadhguru.org/in/en/wisdom/quotes/

Do not attend stand up but follow agile not Agile

This post is about my learning from a very short but interesting assignment I recently completed. Though I say, the lessons learned are specifically from the project, my overall experience has an influence on these thoughts.

What was the challenge?

Product’s Graphical User Interface was completely redesigned. The product was going through the frequent design changes and so, programmers were facing their own challenges. This caused a number of issues in the product. To reduce the number or at least core issues before it goes for third-party testing, an internal tester was introduced.

Challenges faced by a tester?

1. Entered in the middle of the development cycle
2. The product was going through frequent design changes
3. Testing in the development environment, as no independent QA environment was available (but as I moved forward, realized that in this context testing in the development environment was a huge plus from the project outlook)
4. Not part of any of the meetings (but sometimes this saved my time J)

Knowledge or resources available for testing?

1. Product Knowledge: I had used the previous version of the user interface while testing the back-end of the system
2. The older interface as a reference product
3. Story tickets
4. Access to programmers
5. Freedom to conduct testing

What are the lessons learned from this challenge? 

1. Testing without test scripts
   As I was testing within the programming cycle time frame, preferred not to write any test cases. This approach is interesting (though mine need a lot of improvement as it was not structured as mentioned by the James Bach in Structured ET). Structured ET (Exploratory Testing) cannot be learned and implemented in one go. Initially, struggled to document the tests, as I was learning and testing the product simultaneously.
    To overcome this documentation issue, execute few tests, note them, and move further.  During testing one area if you feel potential bugs in any other areas, make a note as a future opportunity
2. Collaboration with other developers of the product
   • Who is the developer here? I feel every team member who contributes to the development of the product. So, with this understanding, all the different roles Project Lead, UI/UX Designer, Programmer, Architect, Customer, and Tester can be referred to as a developer
   • Programmers were readily available could immediately inform them about the priority defects.  I think this helps to reduce the programmer's time in understanding and fixing the issue and so project's time and money.
   •  Sometimes programmer's counter questions to the tester's observations can give more test ideas or may help the tester to avoid if she is focusing on the wrong path.
     
   • As a tester, our job is to log the defect against product not against any developer in the project team
   • The project team needs to understand; testing is questioning the product and see how it responds (more practical definition is "Testing is an investigation of a product to evaluate it"). So, as much information provided to the tester about the product/feature being tested will help them to test better.
   • When everybody in the team has the same goal, trivial, minor issues can be discussed and fixed without reporting. This saves the time of both tester and developer.
3. Testing in the development environment was helpful  

• Apart from the core issues, other functional, usability, UI issues, enhancements were also observed. This helped to reduce the feedback time as issues were identified in the development environment and within the development cycle. Otherwise in the typical process, when a bug is observed in QA environment, programmers are already in the next sprint and need to go back to the previous sprint to fix the issue
  
•  

Why the title "Do not attend stand up but follow agile not Agile"?

1. Agile: As per my reading and knowledge, Agile is a methodology which tries to introduce the communication within the project team by following a certain process. In this assignment, I did not follow any such process.
2. agile: A word which means “Able to think and understand quickly”.  This is possible if different members of the product development team collaborate with each other to achieve the same goal, as one cannot think and understand quickly if alone. 
3. This assignment also helped me to understand the importance of the first point “Individuals and interactions” mentioned in the AgileManifesto 

 Summary

1. One may not go away from the scripted testing completely. However, introducing the structured exploratory testing with scripted testing can be useful. (to introduce the exploratory testing formally, one needs to understand and learn it.) 
2.  A project needs to have the process, as the purpose of the process (as per my understanding and experience) is to help different individuals on the project team to organize themselves to give good productivity and a tracking mechanism.  So, the process is for the people, by the people who are working on a project towards a common, shared goal.
3. When I work on my next assignment, learning from this project may be applicable or may not be. That will depend on the context of the project.
4. In order to have every member of the project team working on a common shared goal, one aspect of the organization which can have the considerable impact is the evaluation process. Project team members should be more evaluated as a team than as an individual contributor. 

References

http://www.satisfice.com/blog/

http://enjoytesting.blogspot.in/