Thursday, 27 October 2016

Pair testing for all

Pair Testing
  • Pair testing is for all in the team - inclusive of testers and non-testers
  • Pair testing is not a measure of who can test better but what and how we can learn (and continue to) from with who we pair with
  • Pair testing has helped me to learn what I need to learn, how having  more heads can help me, how not to test and how else we can test better
  • Pair testing has nothing to do with performance review, have I mentioned it already! The most common myth that if I pair with another person then they steal my super powers needs to be definitely debunked. Let' u encourage pair testing where and when needed. And leave those alone who love to test with the tools, techniques and approaches they have. Because they too contribute to the overall good of the product
  • Pair testing is for those who wish to learn, to get help, to share their ideas, are ready to put their current skills to test and are ready to learn continuously to make themselves better than yesterday
  • Pair test to learn and add tools to your tool kit and ideas to your idea base reference
  • If pair testing is proven to do you harm, share your experience in the comment section so that we can learn how to address it in that context and to understand where not to use it or enforce it
  • I like pair testing with new and experienced testers and non-testers with whom I can learn from, Skype me for a testing session or join weekend testing forums to learn to pair test with the attendees. Pair testing with the tester Ravisuriya (from Moolya, Bangalore) has done more good to me. He deep dives and learns from various perspectives and is a good mentor

Here is my take on Pair Testing for all in the form of a mind map made with XMIND.

Thursday, 29 September 2016

Tester_More than a bug reporter

A tester creates and adds his/her own enhancements to a product based on the skills acquired over a period of time and by learning based on the experience in the same domain and across verticals. As the product progresses from it's discovery phase and passes through requirement collection, wire-frame designing, data modelling, coding and testing phases, we will for ourselves see how continuous learning contributes to transform the product into a full-fledged product or in some cases a minimum viable product (MVP).
Here are a few tips that can come in handy to build such an experience into a product. To make this experience first hand, explore the product from different perspectives that are in scope and in a given context.
  1. Learn continuously
  2. Report diligently

Learn to test

A tester needs to learn to test from different user perspectives. In a particular session, if we are testing on behalf of a user who sees a product as insecure. In the next session, we might want to change this perspective and test the product on behalf of a user who has motor and sensory disorder, a user who faces difficulty in accessing the application using the keyboard. This mindset can help a tester to learn to test differently and make the software accessible to the wider audience.
Pair testing is found to be an effective way to learn faster, as testing becomes double the fun when we test together. It helps avoid common mistakes, learn another test idea, build competence and equip oneself with the knowledge shared by a paired tester.
Continue this exercise with other testers in the team and learn from all. It is found to be beneficial, when the team comes together and tests. And not just with testers, broaden this circle and test with non-testers, coders, actual users, differently-abled users, a hacker to learn and share the knowledge. I picked up on testing with browser add-ons in one such exercise and I find myself getting into a habit to be on the lookout for tools which can assist in testing quicker and better. Built on this continuous learning is a product which takes shape brilliantly with each passing day. This combined with a sense of contribution to enhance the product's quality leads to satisfaction as a tester who's ideas are as important as anybody else's in the team.


A journalist or a reporter stops at nothing, when reporting news which the public can use. So is a tester, who should not shy away or be afraid to communicate a bug. Learn to learn and unlearn no matter how trivial a task is. We blame the media for reporting only the failures and rightly so for overdoing it. Testers can take a cue from this and give all the love that a product rightly deserves.
Testers need to not just critique the software but also share good news. Give credit to all the goodness in a product. 

Interacting with valid and accurate sources of information is a key to reporting successfully and to get the bug fixed with less or no hassle. More is the value attached to the bug report when the reporter talks to and refers reliable sources of information. Have a repository of tools, point of contacts, websites, updated legal guidelines to refer to, to make the report itself authentic. Add value to the report by quoting various instances in which a user finds it difficult to access the application or fails in doing so.
Finally, build reliable reference list and keep it updated, check list, tools, heuristics to refer to when reporting bugs.