Theme: Changing the way people test and think about testing
Venue Sponsor: Edista Testing Institute & Test Republic
For more pics, click here
Ajay talked about the change he had after attending my workshop on Exploratory Testing – A Rapid Software Testing Approach and how it helped him log several hundreds of bugs when he started doing a structured exploratory testing. He explained how he struggled with the templates that he had to adhere and how those test cases filled in templates failed to yield coverage and value.
It surprises me that some organizations get their resources trained to help changes to occur to their work and grow skeptical when they get to witness the change.
Before he finished his presentation, he mentioned how the management started seeing Ajay’s work output as a different value than what they expected out of him. What they expected from Ajay was to run as many test cases as possible and what he ended up producing was finding defects and reporting them in their bug tracking system. That is an interesting one – test cases are there, wherever they are, to help testers find bugs and some managers might be misusing it to show progress of testing. I have heard it happens everywhere in the world and not just in
During the facilitated discussion that happened after Ajay’s presentation, Shrini mentioned, “The value depends on what stakeholders defines it as”. However, sometimes some stakeholders might need education from a tester to have more meaningful value definition.
Rahul Mirakhur (RM) brought in the idea of a tester wearing different hats and being able to think the value that different stakeholders might want from a tester.
When he interacted with Support teams in an earlier organization, it opened up a completely new world of information source and that, changed the way he did testing thereafter. It also gave a glimpse on how different functions on a project bring in value and in the case of Support teams case, value is more "after" product release.
As the discussion drifted to bugs, Rahul Verma said, “I see bugs as questions we can ask”
Manoj Nair’s presentation on An attempt for better testing
Manoj talked about the opportunity he got in his project where time crunch and amount of testing to be done, enabled his manager to bestow him with a freedom to do free style exploratory testing (without much documentation) for an important feature in his project. The defects and the information he came up by performing free style exploratory testing made the management to postpone the release realizing the danger. He felt happy with his effort, until he was required to explain the details of test coverage across the feature and provide test case document for the tests he conducted for those features. The test case document he prepared were subset of the entire range of tests he performed because he did not have time to document all those tests. He realized the value of tests he did could possibly diminish through that activity. Looking back at it he felt, if he had used Session Based Test Management, he could had done a much better job in providing test ideas document.
During the discussion, I talked about the idea of a Wiki for changes to the product open to all team members and the value it could have for the test team.
Aishwarya, an undergraduate student asked a striking question, “How much information would be an overflow of information?”
The discussion then digressed to – When is the right time to get testers on the project for which all participants had different ideas and experiences. Many organizations have tried bringing in testers early and late and most of them are not yet sure when to bring them in.
I argued that it depends on the kind of a tester an organization is trying to bring in and other factors. Not all testers are the same. I have witnessed organizations that actively ignore testers in requirements review meeting as they have had a bad experience of bringing in a tester. It makes me think that if I lose credibility, it affects other team members in my test group. That is how important it is for each team member to have and build credibility.
Manjunath’s Presentation of Review of Review of Review of Bug Reports
He talked about his experience in one of his previous organization in the context of bug report reviews conducted to help testers log better and credible bug reports. This exercise was undertaken based on the success of improved bug report quality, post a review of each bug reported from the previous project.
This process was then declared a failure for the second project as its implementation went wrong and
ceased to exist thereafter, maybe.
Someone hasn't talked about it as "best practice" yet? It then digressed to how much English should testers know and then RM talked about practicing English as a daily activity as opposed to a one time upgrade of English skills.
We got back to reviewing and then discussed on reviewing as a skill and review effectiveness.
Lunch Time folks!
At about , we walked to a nearby hotel down the street and carried over facilitation-less discussions over lunch table. A heavy lunch
Then when we returned, something helped us get the heat back… Rahul Verma’s presentation on Confessions of a Fallible Tester
This was a very energetic presentation we had for that day and thanks to Rahul Verma, he did it right at the time it was needed ( post lunch )
He made confessions of the mistakes he did right from the start of the career where he thought testing was not his cup of tea. He just did not confess but also explained how he learned from those mistakes and lived better after each big mistake.
One of his confession sounded very cool - “When senior testers in the team said XXXX XXXXXX was the best tool, I believed it” and then he explained how the project suffered because of that tool or the idea of thinking that as THE BEST Tool.
He explained how he cleared that trap and ended up writing a customized plug in to work with XXXX XXXXXX to make it suitable for his testing context.
He then confessed on another mistake of how two blank lines that caused the test environment to fail to enable the product to be tested over it. He or his team members make turned the case by defocusing the customer to something else when the customer observed it. The message was – Test your Test Environment. I think those who do that today are the ones who have realized the value of it. Many testers just setup and start running their test cases without bothering if test environment is what they intended it to be.
The discussion kicked off and we started discussing about tools. The topics varied from Automation Readiness to Vendors bribing managers to sell their tools to Good code versus Measurable Code.
He started with a cool question, "When people say WHY will you want to be a software tester, I ask WHY NOT" and I think that was exciting. RM had some interesting observations about IT people in
He then talked about his experience of witnessing developers who moved to testing because they were interested in testing. He then said based on his experience, “Jump into development first if you are serious about becoming a tester”. He shared the experience and value of hiring a person who earlier worked in a support job.
The discussion post this presentation helped in understanding how many different ways are there to get into testing and the value of taking each way. We also talked about the value of learning testing from other fields and that reminded me of CAST2008 conference theme and presentations from there.
We had an interesting comment that - By the time an organization implements some new practice as a "best practice" and penetrate every team, the idea is outdated. It reminded me of Ted Neward’s presentation at Oredev08 where he talks about the time difference of programming language birth to becoming an industry usage.
Shrini talked about his experience of becoming a tester and then about how he grew from being a fresher in software testing to wherever he currently is. He then talked about an interesting experience of Test Automation Readiness Assessment that he was supposed to do for a client in
Shrini also talked about his consulting experience and mentioned that almost all test consulting assignments he witnessed, the client was interested in knowing some "universal" or industry standard benchmark related to testing - be it dev to test ratio or % of project cost that could be associated to testing. His experience was that he rarely witnessed anyone challenging those industry standards. In his opinion - That is hindrance for our profession.
Discussions on Test Automation, mindset and skill set followed Shrini’s presentation until the bell rang at
We had a quick check out and got on to the socializing evening and facilitation-less discussions. We decided on a
What a fantastic learning to all of us. I must thank Shikhar Singh and Raghu Sahay for coming down from Mumbai and Pune to attend BWST-1. It was fantastic to note that Aishwarya Shukla, an undergraduate student, wanting to do a software testing project as his final year project after attending BWST along with Santhosh Tuppad who completed Practical Software Testing Training at Edista and has been working on several testing assignments as a freelancer. Every participant asked questions that helped other people learn and discover more about themselves and the work they do.
Once again, special thanks to Mohan Panguluri, Pradeep Chennavajhula and Rachna for providing us the space @ Edista Testing. I wish India has more leaders like them who facilitate knowledge sharing and learning in software testing without just being business minded.
- Only testers can talk about Testability
- Book suggestion: Perfect Software and other Illusions about Testing – Jerry Weinberg
- “Every bug is a duplicate of a master bug that the product fails to do something that is important to work for someone” – if that sounds bad - that's still me.
- Philosophy in Golf & Testing – Adam Goucher
- Bug Advocacy – Cem Kaner
- How to investigate Intermittent Problems –
James Bachblog post
- “The best tester is the one who gets
the mostthe right bugs fixed” – Cem Kaner in Bug Advocacy
- Do confess when you screw up
- Turning Numbers into Knowledge – A book by Jonathan Koomey
- Lessons Learned in Software Testing – Kaner, Bach, Pettichord
- “Automation could be a dangerous word for a tester” – Rahul Verma
- “If you have failed big, it indicates you rose to a great height” – Rahul Verma
- Value of Checklists – Cem Kaner’s presentation in CAST 08
- Video Record Your Bugs
- The intake I have had from BWST-1, has questioned what I have learned so far. It has helped me to unlearn and learn consistently - Ravisurya
- "When I spoke to support teams, it changed the way I tested, forever" - Rahul Mirakhur “
- After I attended Rapid Software Testing Workshop, my testing improved” – Ajay Balamurugadas
- “The value you add as a tester is like
NAVof an investment. It changes every day” – Shrini
- General Systems Thinking – A book by Jerry Weinberg