understand it well and then ask the experts "What more should I read?"
Now the next question arises
"How do I verify that I have a good understanding?"
Step 3– Again dating back to our childhood, we would have taken our textbooks to someone, who wished to listen to our answers for the questions the book had at the end of every lesson. We used to be happy and confident whenever we heard "Good, dear child. You are good at these lessons". We would then add more confidence by taking up mock exams, isn't it?
Similarly, here we need to present our understanding and share ideas, with the team and also request some experts to witness the presentation. At the end of presentation, a new confidence level is visible if the team is confident about you.
Does it stop here? No!
We also need to document our understanding and circulate among other Team members and anticipate their comments on our understanding document.
Aren't you asking, "What is the next question?"
Here it is, for you...
"How to write the Test Cases?"
Step 4– When we come out of the exam hall, most of us say, "the paper was tough/easy". If the paper is set tough we see many students failing the exam along with us. Isn’t it? The reasons being the questions were tough and we should have prepared/designed our strategies for the exam in a better way. Probably we should have referred to more topics/books/articles to pass the exam with the same tough set of questions.
Similarly, tough test cases are the ones that make a system fail (not always). As a person who is setting the question paper for an exam, you should prepare cases that will lead to uncovering much failure (bugs, as we may call).
To write good test cases, we need to look at spec, design, system, feature, scope of testing and so many aspects. We should ensure, those designers and developers feel "Yes, I did miss this point, thanks for finding it for me"
Now again another question, perhaps, last of this article (happy?)
"How do we execute it well?"
Step 5– Even though you write your exam well, say if the person correcting your answer sheet did not evaluate your answers well, you usually end up getting less marks than what you deserve (desire), you do re-apply for correction and then you get more marks.
Similarly, you need to execute the cases well. If you overlook at a test case and execute something else, you will end up loosing marks (I wont repeat that I am referring to bugs when I say 'mark' here)
Conclusion–Assuming there are very few points that I may would have missed in "How to start the bug hunt?" I also hope this document to be beneficial to all of you in someway or the other. Let us hope to give a good, methodological effort and improve the quality, more than what we could have. (Not by the effect of this article though, just in case this did not add value to you.)
|How to Start a Bug Hunt||11.71 KB|