Saturday, December 26, 2009

The story of Rich Tester and Poor Tester

Even though we may not realize it at the time, the way in which we approach our work sometimes has a profound impact on our future. Let me explain this with the help of a story that I have made up. This story is about two testers who faced identical circumstances. The two even had very similar knowledge about the craft of testing. The only difference was that one of them earnestly wanted an opportunity to make her mark in testing.

Once upon a time, there were two testers working in a company. The company started a project in which two testers were required. Our two testers were assigned to the project with hopes (as always) of successful testing. However, only the Rich Tester (though she did not think of herself as such at the time) had been eagerly waiting for such a chance.

As usual, the initial period of the project was used for the purpose of knowledge transfer and knowledge building about the application under test. Both the testers were serious about gaining in-depth functional knowledge about the application. Both of them asked a lot of questions to the trainers and obtained clarifications to their queries. The Poor Tester stopped at that but the Rich Tester did not. The Rich Tester took the time to build her own notes about the problem areas of the application, the problems that she observed and the areas of the application that she would like to explore in detail.

Soon enough, the period of knowledge transfer finished and the day came when the two testers were provided a recent build of the application. Their Test Lead divided the test items between the two. As expected of her, the Poor Tester executed the test cases on her assigned test items and logged the defects in the issue tracking system. But the Rich Tester did not immediately start the execution of her test cases. She performed a sanity test on the application. She found a few high-level problems. Then she executed the test cases on her assigned test items. She logged both the high-level defects as well as the defects in her assigned test items. The result was that the Rich Tester was able to find a few more and a few more important defects.

As subsequent builds of the application came up, the Poor Tester stuck to her assigned test items. Since the available test cases listed only positive tests, she limited her test execution to only positive testing. However, things went differently for the Rich Tester. On a new build of the application, she would start with the usual sanity test. Then she would execute her assigned test cases but did not limit herself to the test data listed in her test cases. She designed other interesting test data and executed her test cases with that as well. She spent the remaining test execution time to design and execute negative tests in her assigned areas. There was now an observable difference in the outputs of the two testers. Generally, the Rich Tester was able to find either defects with a bigger impact or simply more defects than the Poor Tester.

There was no stopping the Rich Tester. She utilized the time between the builds to automate the generation of certain test data as well automate the sanity tests. Automated generation of test data saved a substantial period of time that she could now devote to an even more thorough round of testing. She started her automated tests every evening before she left for the day and analyzed the test results the next morning. Due to the quality of the defects raised by her, the Rich Tester had established a better perception in the minds of the stakeholders of the project. For the Poor Tester, things had remained fairly static.

Fast forward a couple of years. The Poor Tester was still testing (efficiently, mind you but by the book). However, the Rich Tester had impressed the stakeholders in her previous projects. She was considered a role-model for other testers and was now leading a team of her own. Soon, she would be in consideration for a role as Test Manager.

We can realize from this short story that it is in our best interest to not wait to be asked but to push the boundary as far as possible. We should find the means to make a bigger impact and magnify our output.

Sunday, May 17, 2009

Domain Knowledge: 5+ ways to build your domain knowledge

Professionals from many backgrounds work in the software testing field. Some professionals have vast experience in the testing field. They are aware of many ways to test, they might have good people skills and reporting skills and they might be aware of many resources and tools that they could leverage in their tests. Some other professionals are ex-developers and they bring their technical acumen to testing. They usually have rich experience in at least one development environment, they are quick to conceptualize the implementation of the software they test and they can learn any new test automation tools very quickly. There is a third category of professionals who work in the software testing field. They come from the business background. They have been in the industry for a long time and they are keenly aware of the general requirements of the business and the end-users. Of course, these professionals from the business background might not know a great deal about testing methodologies or test automation tools but they know the business domain.

If you work in the software-testing field and you do not belong to the third category of professionals, you should know that building up your domain knowledge would put you ahead of many colleagues and fellow testers who do not choose to build that knowledge actively. View my below video or read on.

Let us look at the various ways in which you can increase your domain knowledge related to your project. Many software testers who have not worked in prior projects related to an industry e.g. investment banking, retail and so on learn about the project from the available documentation and the knowledge given to them by their project team members. The documentation may exist in the form of a requirements specifications, design specifications or user stories. The project team members may provide them knowledge in meetings or casual interactions. However, the initial learning from the team and continuous learning from the feedback given by the business are not the only ways to get the domain knowledge. You should consider the other ways to build up your domain knowledge:

1. Just get interested in the domain.
Even acknowledging to yourself that you need to know about the domain is helpful in itself. You would see the opportunities to educate yourself in the domain e.g. if you watch business news on television, you would find yourself paying attention to a program related to your domain. If you come to know about a local exhibition related to your domain, you could go visit there.

2. Read the business publications (articles, news items, web casts and so on).
By doing this, you would quickly become aware of the vocabulary and key concepts used in the business.

3. Get your hands on the documentation of similar projects done in the past and read it.
This would make you aware of the past issues and if it is a long-running project, you might become privy to information that is known to few people in your team or company.

4. If possible, work only in projects related to a particular industry.
This way, you would be able to leverage your existing domain knowledge.

5. Network and interact with professionals in the business.
Once you have some knowledge in your domain, you could build it further by networking. Professionals like to hear from each other and share information.

You can safely assume that either some software testing professionals would not consider actively building up their domain knowledge or even if they do so, they might not make a concerted effort in that direction. Therefore, if you make a regular effort to build up your domain knowledge further, you would get the following benefits:

1. The requirements of your project would be clearer to you.

2. You would be able to focus on the key aspects of the project easily.

3. Your reports (test results and defect reports) would contain the language of the business. You would strike rapport with the business stakeholders in this way.

Strengthen your domain knowledge and excel in testing.

Sunday, March 22, 2009

Bug report: How to write an effective bug report?

View the above video or read on. Each one of us in the software testing field has seen many bug reports. Bug reports are written in a vast variety of styles. Sometimes, we happen to see the bug reports created by experts and inspire ourselves by doing so. However, a test engineer may create a bug report in any manner as seen fit. If so, can one be sure that the bug report is best suited to the circumstances? Will the bug report do the job well? In this article, I wish to make my reader aware of various aspects of a bug report. I have attempted to integrate many methods used by experts. This will enable you, my reader, to create bug reports that are best suited to the conditions at hand. The next time you have to write a bug report, you will have many tips to choose. Alternately, you may implement certain parts of some tips to create a custom strategy that suits the purpose.

Tuesday, March 17, 2009


A very warm welcome to this blog!In order to get things going, please note that in the month of January 2009, I wrote an article about security testing. This article focuses on the SQL injection technique. Please provide your inputs for this article.