The Shaolin of testing

A colleague of mine Anand Bagmar and I were conducting a QA-bootcamp (training) for some fresher and lateral tester hires in our organization. During the second day, we thought of having an ice-breaker in the form of 'Taboo' as a game. As we played the game and were observing the participants playing, anand and I realised something. There were many aspects of the game that testers adopt in their day-to-day jobs as testers. After the game ended, we asked everyone to come up with their learnings from the game. This is the list they came up with Team Work Interference Focus Leg-pulling Expression / Communication Distraction Time management Strategy Observation Persistence Support Rotation / Shared Responsibility Build Trust Conflict Resolution  The above list almost completely if not fully, covers all the aspects of what we as testers try and adopt to get our job done in the best possible m...

Given the nature of change within agile projects, it is good to try and foresee what is in store in the near future. This is where the use of a crystal ball is useful. Now, when i say crystal ball, i do not literally mean having a nice shiny circular translucent object that takes us into the future. I am talking of a chart which gives us a slight insight into what is going to be delivered. Lets call this Crystal ball as an ETA (Expected Time of Arrival) chart. This ETA chart gives the team an insight into what is going to be delivered within an iteration. This ETA chart is a matrix where the columns represent the week days within a 1/2 week iteration and the rows are the dev pairs working on different stories. This is what it looks like So the idea is to get the developer pairs signed up for stories to put up an ETA (Expected time of arrival) for the stories they are working on and put it against a day. So they would just put a sticky note with the story no and a brief desc of th...

As a tester, i have spent more than 6 years trying to automate tests at the UI layer. As years passed, better automation frameworks evolved resulting in writing more manageable and maintainable code, but the only thing that wasn't getting better was the cost of maintaining these tests, especially when the no. of tests were 500+. There are multiple reasons why i feel creating an automated regression suite of tests at the UI layer is not good. Some of them are Limitations on what the tool can do Time taken to execute these tests leading to longer feedback loop Success rate of tests is not 100% due to latency issues Change in UI and UI flow resulting in an increase in cost to maintain UI tests On the other hand, testing business logic without having to deal with the dumb UI was a concept that a friend of mine at ThoughtWorks, Chirag Doshi introduced to me. He sent me couple of blog links written by Alex Verkhovsky about why is it so hard to do functional test automation at th...

A question that has been troubling me for years is how much to automate. We all like to achieve maximum coverage and build a robust safety net where possible in order to give us confidence about the system under test. Given there is ample time i would like to automate almost everything, but in the real world, this isn't possible. This is when we introduced the concept of Value and Cost for a test scenario. Every test scenario would be assigned either of these attributes. Lets call the attribute automation classification High Value - Low Cost High Value - High Cost Low Value - Low Cost Low Value - High Cost What this translates into is we are associating business value and cost to automate to every scenario. So, when a test scenario is of high business value and the cost to automate it is low, then this becomes our ideal automation candidate. You would like to start automating all test scenarios that fit into the High Value - Low Cost category first. See picture below If tim...

In one of my recent projects we tried a new technique of brainstorming a story which we called 'Story Kick-offs'. Story Kick-offs were mainly about discussing the stories to be played within an iteration in more detail. All members of the team; Devs, Testers, UX, PM, IM, BAs would participate in this meeting. Typically, the BA responsible for a story would walk the team through the details of the story and then questions from the team would be addressed. Depending on the team size and number of parallel streams that could be in play, typically, 2 or 3 stories would be discussed during this meeting. We would have atleast 3-4 Story Kick-off meetings per iteration to cover-up all stories within the iteration. The Testers would already have some knowledge of the stories being discussed, since they would have reviewed the stories before they were sent for customer sign-off and ideally have already written test scenarios for the stories to be discussed. After our first story kick-off...