Before I getting into “2013 – Lesson Learnt”, I like to thank “Anne-Marie” who helped me to take the first step to start my own blog and share my thoughts/ideas to testing community. Last week I have finished my previous role as Test Manager with retail solution company and I should admit it was not an easy journey for me. I had a lot of ups and down but I thoroughly enjoyed every moment. When I started this role my ultimate focus to create better test team and to add value by working closely with business. Below are the few changes we did in the past 1 year and I should say that I am really proud of the entire team as they are open for new ideas and ready to change the way we test software.
Be the change: As a lead, My first priority to meet everyone in my team to understand their passion for testing, motivational factor, day-to-day challenges and what they think about software testing in general. As expected, I can see everyone facing lot of challenges starting from process and the way we test different application but at the same time no one talked about what changes they like to make within the team to make this place better. Based on the feedback from team, we created our own Testing Road Map which consists of series of changes within the team . Below are few changes we made in last 1 year.
1. Introducing Exploratory Testing – Fundamental reason we introduced “Exploratory testing” to make sure our testers simultaneously “Learn, Design and Execute” test scripts instead of following traditional scripted approach which didn’t work for the team. Introducing “ET” helped us in lot of ways and the key take away are “ET” found most important defects from business perspective and “ET” helped every tester in our team to understand & learn the system/application under test which lead to better coverage.
2. Lean Test Case Design – After reading Darren McMillan post on Mind Map, we thought why not experiment Mind Map in few projects to understand the advantages & disadvantages of Mind Map. After piloting in few projects we understood that Mind Map helps us to produce high coverage and better test conditions within short period of time. Also Mind Map helped us to visualise our business flow, Test Strategy and business team can understand our coverage better through visualizing our scenarios. After 3 months no one in our team wants to go back to the traditional way of creating test case using expensive tool set.
3. Bug Bash: As a Test team our objective is to ensure we test the application and provide early feedback to the business to make decision. We took another step and invited business to come and help us with testing. We called this procedure as “Bug Bash” and it was a great success as testers worked hand to hand with business. To ensure bug bash is successful we time boxed every session to 1 – 2 hour and collected all the feedback from business. End of the day we normally have usability feedback provided by business and few defects which we missed as part of our testing. Normally bug bash session happens once every release cycle and to make it fun we use to organise pizza session and award people who found important defects which will be judged by Product Owners.
4. Bad Metrics: Right from start of my career I always had issues with counting number of test case, Pass rate, fail rate, number of test executed per day, number of test executed per person etc.. I am not sure whether test team providing right information to business to make decision using above said metrics. So we worked with business to understand what exactly they need from business perspective and we stopped creating metrics which didn’t make any sense.
5. Celebrate your wins: Putting 100% effort is great for each individual but I strongly believe that celebrating success is key motivational factor for each individual. Our test team not just found the major issues but we started celebrating and started showing visibility to the entire project team on key success milestones.
PS: This is my first blog post, I am keen to get feedback from everyone.
parimala6 said:
Good start, Hari. Welcome to Blogosphere!
harijaganathan said:
Thanks Parimala! I got lot to learn from you and your team
james bach said:
Yes, good start. Excellent, even.
How about elaborating on one of these details? For instance: “Based on the feedback from team, we created our own Testing Road Map which consists of series of changes within the team.” Okay, what’s the roadmap? Let’s see it!
Anne-Marie Charrett said:
Congratulations Hari!
A question and a comment:
“Introducing Exploratory Testing – Fundamental reason we introduced “Exploratory testing” to make sure our testers simultaneously “Learn, Design and Execute” test scripts instead of following traditional scripted approach which didn’t work for the team.”
What exactly do you mean by Learn, Design and Execute” test scripts. Is not Exploratory Testing by its vary nature ‘unscripted’?
Bad Metrics
I’d love to see more detail on what you mean by bad metrics. What metrics did you throw away and why? What did you keep (and why?). Also what was the companies response to this? I’m very interested in what you did, are you able to share?
Again, great to see another Australian taking to the blogosphere. I hope to see many more posts.
Daniel said:
Great blog post, congrats on putting it together. I’m also interested in the metrics your business owners were interested in. If you can let us know, that would be great.
mcburkels said:
Hi Hari, nice to meet you :-)!
Thanks for sharing your experiences! It is very motivating for peers to learn about what others went through and how that worked for them.
I am very interested to see more of your roadmap! And of course the metrics as well.
What kind of obstacles did you face (because you must have faced them :-)) and how did you manage them? I for instance struggle a bit with test data management during the sessions in which we perform ET. The data available is bound to all kinds of regulations and conditions and on top of it, no unlimited availability AND it must be shared with others. I have found that during sessions, specific data types were needed (as we wanted to explore more based on observations) but could not be facilitated at that point. I decided to capture them as ‘new test ideas’ and try to arrange it for the next session(s). But perhaps you have another process that could be of interest for me!
mcburkels said:
Hi Hari, nice to meet you!:-)
Thanks for sharing your experiences- it is very motivating for those of us who are working a change what others have experienced (and to learn from that).
I am also very interested to see your test roadmap! Great idea by the way. At the client I’m working for some years now, I decided to put a big model airplane (it’s an airline company..) in the coffee area and people could see by looking at the state of the plane what progress we were making with the changes I decided to implement. As it was in a central area, it initiated a lot of dialogue with the people outside the testing department which was exactly my intention.
And the metrics..do share!
Also, I wonder what obstacles you have faced when making those changes, as I am sure have faced them (don’t we all) and how you managed them. Currently I am struggling a bit with test data management during the sessions in which we perform testing by ET. The data is quite complex as it is bound to all kinds of regulations and restrictions so there is limited availability. On top of that, it is shared between departments. What I do today is that whenever in session we would like to explore (based on the observations) more in a certain area but there is no appropriate data available, I log them as a ‘new test idea’ to capture it in a next session.
I’m interested to learn how you managed it!