Defect Driven Test Cases

Recently I was reading something around test driven development and how it has been further extended to behavior driven development. I started to understand the philosophy behind behavior driven development pretty quickly. The Given,When,Then format for writing a scenario is an straightforward and easy input for developers to build their code around.

Now I am thinking that similarly we should also start doing defect driven test cases. So the current practice for a tester is , generally, look at the requirements , analyze the testing aspects from a story card (I think only agile projects now), identify testable items and write them as acceptance cases. This is good and required but what about System Level test cases, integration test cases should they be written upfront ?. Now if the quality of test cases are so good that you get at least 30 percent of defects from executing your test cases then I think writing test cases before doing actually testing is worthwhile but if the objective of writing test cases is to create more documentation to cya , or to be able to create an unnecessary deliverable from the testing team then really its futile. Instead what we should do is "Exploratory Testing". Do Exploratory testing on the in system and integration phases and then based on whatever defects found during system testing or integration testing and create test cases for that particular defect for future testing and regression. This will do two things for the tester. 1 - Invest less time in writing useless test cases and 2 Write test cases which are more specifically targeted to previously found issues on the application in a given module/part/application.

I will continue on this thought further but for now...I think defect driven test cases is the way to build your test repository from a test case/scenario/test data/and app issues perspective.

My presentation debut done...am glad I did it

So finally I gave a presentation to some QA folks from Morgan Stanley on "my experiences in agile testing"......I have been working on it for more than 2 months now....it got postponed twice before it finally happened but I am not complaining as I got that much more time.So how did it go ??

1. Well first thing I learned was I was not being a good listener. Some audience asked me questions but I realized that I was cutting them in between and assuming what the rest of question is and would started answering which did not help....
2. I also thought I did not answer them in a easily understandable way...like I was clear in my mind of what I am saying but I did not frame it nicely enough....
3. For one question I did not really understand the intent of the question but started answering as soon as the question was over...not good

I dont want to be too hard on myself. I will just take these 3 points as my learning from this venture and try to plug that gap....

Another interesting thing that happened was...confusing around who will run the ppt while I am talking abt it. I was told that since I am remote and on phone the ppt will be run by host and not presenter so i did not have my notes in a hard copy but just on the notes section of the slide...what actually happened was that i was supposed to share my desktop in run mode so I could not see my notes during run time at all...

Well given that confusion I think I did ok as a starter.I was glad i could complete the presentation in allotted 60 mins although during practice I took 1.30 minutes for my first dry run :)

The most important takeaway from this presentation is that its DONE I am no more a rookie in presentation and talks.(I have done it once atleast )....so now I think I am ready for another one...I will take it whenever I get a chance again....