Using git ‘pull' ‘merge' principle to exploratory testing

I am a huge fan of git. I like its speed, ease of branching, offline capability, undo, and many many more features. But the one I love the most is its ability to bring the team together. I see it as an amazing collaboratory tool.

The ability to tag others in the team to review a pull request before it's merged into master by the reviewer is so simple yet so powerful. (a quick summary to those new to this approach - dev's create a new branch when they start working on a story, continuously update it, testers can pull code off this branch and test it to provide quick feedback and when the code is ready to be merged, the dev can tag members in the team to review the code and the reviewer can merge the branch to master if he\she is happy with the code)

We have extended this to feature files too. When we can't get hold of our product owners for a three amigos session. We raise a pull request with our scenarios and tag them for review. They add comments. We would work on the changes and eventually when the product owner and most of the team are happy the branch is merged to master.



So, how does any of this fit with exploratory testing? 

Our approach to testing is exploratory. We test in time bound sessions as in SBTM. The notes from test sessions get tagged to the specific jira stories. All sounds good?

Yes, but we strive on getting better and so with a bit of digging we realised that we do not pair much in test sessions and from what I have observed we do not de-brief test sessions.
To me, from my past experience interpretation of a test session is very important. This is when we learn from one another, share, challenge tests and is an enabler that makes the following test sessions better.

So how can we sort this with minimum overhead?

A proposal - What if we tag team members, to review the test session notes at the end of a session (similar to a git pull request). He/she can now do a debrief of the session or if physically cannot be present can review the session sheet, provide feedback, recommend tests or if happy with the session notes close the session (similar to a git merge)

I am hoping this simple, minor change can help us drive debriefs and bring the benefits with it. 

I will follow up with an update in couple of month’s time if this change helped us get better or not. In the meantime do let me know what you think of the idea.

Comments

Tony Bruce said…
Have a chat with Alan Parkinson - http://www.slideshare.net/alan_parkinson/pull-requests-and-testers-can-be-friends
Cheers Tony, Went thru the slidedeck. I completely agree with Alan, pull requests, checkin comments are GOLD :)

My proposal is to extend the similar principle to session sheets.
Example: At the end of my test session. I can tag you on the session sheet. We go thru it together or you review it and close the session. So, similar principle and all the benefits extended to session sheets :)

Popular posts from this blog

Exploratory testing, Session based testing, Scripted testing…concertedly

What do you do when you find a bug?

Regression Checks + Regression testing = Regression testing?!