We Agile Testers

There are many types of testings Unit testing, Module testing, System testing, Integration testing, bla bla bla ... ... ... We testers all know what these means and definition, we are always eager to answer what kind of testing means what and we are ready with out armors to fight a war of debates to prove it. A special thanks to ISTQB :) But what happens people found bugs right after the beta release of our tested products? Our manager asking us weird questions, teammates questioning why we missed that, colleagues are blaming and joking, what happens then?

We ask ourselves question, what did I miss? going to our checklists.
- Test cases (Checked)
- Sprint backlogs (Checked)
- Resolved issues (Checked)
- Reopen issues (Checked)
- Unit testing (Checked)
- Module testing (Checked)
- System testing (Checked)
- Integration testing (Checked)
- Load testing (Checked)
- Security testing (Checked)
- Portability testing (Checked) 
...
...
...
and the checklist goes on and if all are checked then we are finding more and more that we have done. Then how do we miss?

We agile testers, are so much concern to test the task or the user story, we often forget to the link between each user stories, how they interact with each other. I am not talking about different units or modules, I am talking about different logic, user stories how they interact, is this what our requirement is or something else?
We agile testers, live in small fragments called sprints and we often forget the whole picture, we often to use our common sense. I am not telling that we cant do that its because of the pressures, we often forgot.

So, what is this post about? its about focusing the whole picture, its about thinking end to end, its about living in the context not in sprints, its not about checking what we have done its about checking what we miss, its not about defects of developers work its about defects in our work, its about us agile testers :)

A simple test case management document

Recently many of my fellow colleagues and friends ask me for a simple test case management document and I gave them. So I thought of this post, lets share it here so if anybody need any information about basic test case management document so they can find here.

Before starting it I want you all to know that this is a very simple syntax, considering only those fields whose are necessary and avoiding others. Though this syntax can vary organization to organization but although it will give you an idea.

A spread sheet can be used to manage your test scenarios/ cases. A test scenario will always have one or more test cases. Its a good practice to break scenarios as small as possible while maintaining a test document.

Each scenario will contain following columns and each row will represent one test case.
- Serial Number(To track down test cases)
- Action(Action need to perform for that particular test case)
- Data(If any data is needed to perform the action of that case)
- Expected Output(Output which is expected for the action)
- Actual Output(Output actually given by the action)
- Result(Can be only Pass or Fail, nothing else)
- Comments(If any comment needed to add for the case)
- Defect(If the result is fail then you should give the link of the reported defect of your issue tracker)

Example:

Test Scenario: Log in