“Bug prevention is testing’s first goal.” – B. Beizer
One of the best practices in our team is the fact that both the devs and the tests review the functional specification before it is accepted. As a test this is the time to make them most of. One of the practices I have learnt from Robert Binders, Testing Object Oriented Systems is analyzing the requirements while you read them. He recommends a pattern called Extended use-cases. If you rewrite the requirements in this way, trying to fill in different scenarios/inputs, you can detect ambiguities in the functional specification better than if you just read through the specification.
The functional specification is the basis for the system tests. Because you can start work on these as soon as the functional specification is out, you have your system test strategy ready even before the developers start churning out features. While you use the system tests the last, you write them the first. As features become available, you can start running some of them.
Tuesday, September 29, 2009
Sunday, September 27, 2009
Different approaches I take to take to testing a product - Part 1 Ad-hoc
As part of testing a product, I take various different approaches for doing the same task. The approach depends on the stage of the product, type of product, time at hand amongst other factors. I thought I'll pen down these approaches along with the reason I use the particular approach and its advantages/disadvantages.
The first kind of testing I ever did was ad-hoc testing. I joined my company with no prior experience/knowledge of testing. My manage asked me to just play with the product and try and find out as much as I could about the product by just trying out different features. He asked me to simply explore the product and write down any questions I might have and also anything that in my opinion was a bug. As a novice, my approach was purely ad-hoc.The only thing that helps me with this approach was my curiosity about the product.I tried the product with a notebook and pencil at hand. I would write the features I could not figure out and things which seemed intuitively wrong.
Over the years, this ad-hoc testing has become a part of my routine and something I try to do on a regular basis with the products I am working on or some other products that my team owns. With time I have realised that if you focus on a particular area, like UI or internationalization, when you are testing in this manner, it increases your chances of finding bugs. The idea is that while you focus on a particular area, you don't start out with plan. You just try to do different things with the product, some of them do turn out to be far stretched and a fragment of your imagination but that just adds to the fun. The more twisted the thing you try to achieve with the product, the more fun you have. Thats the basic idea about my adhoc testing, fun. It acts as a break from whatever else I was doing/trying to do. And a one hour of just playing with the product, gives more than enough insight and issues to justify the time I spend on it.
I have found more bugs with this ad-hoc testing approach that with the other planned approaches I have used. This has helped me know the health of a new feature faster than going through the test cases and also find test holes during the later part of the product cycle.
I guess this approach is similar to exploratory way of testing, though I don't know enough about exploratory testing to confirm it. Try it out if you don't already do it. Its fun and productive.
The first kind of testing I ever did was ad-hoc testing. I joined my company with no prior experience/knowledge of testing. My manage asked me to just play with the product and try and find out as much as I could about the product by just trying out different features. He asked me to simply explore the product and write down any questions I might have and also anything that in my opinion was a bug. As a novice, my approach was purely ad-hoc.The only thing that helps me with this approach was my curiosity about the product.I tried the product with a notebook and pencil at hand. I would write the features I could not figure out and things which seemed intuitively wrong.
Over the years, this ad-hoc testing has become a part of my routine and something I try to do on a regular basis with the products I am working on or some other products that my team owns. With time I have realised that if you focus on a particular area, like UI or internationalization, when you are testing in this manner, it increases your chances of finding bugs. The idea is that while you focus on a particular area, you don't start out with plan. You just try to do different things with the product, some of them do turn out to be far stretched and a fragment of your imagination but that just adds to the fun. The more twisted the thing you try to achieve with the product, the more fun you have. Thats the basic idea about my adhoc testing, fun. It acts as a break from whatever else I was doing/trying to do. And a one hour of just playing with the product, gives more than enough insight and issues to justify the time I spend on it.
I have found more bugs with this ad-hoc testing approach that with the other planned approaches I have used. This has helped me know the health of a new feature faster than going through the test cases and also find test holes during the later part of the product cycle.
I guess this approach is similar to exploratory way of testing, though I don't know enough about exploratory testing to confirm it. Try it out if you don't already do it. Its fun and productive.
Monday, September 21, 2009
Difficult to be a customer - My first lesson from Bangalore weekend testing
Last Sunday, I had a chance to interact with a group, which picks up an app and tests it for a couple of hours. This group is called the Bangalore weekend testing group. For me this was a brand new experience and something I had never done before. In one hour, I had to install, learn, use and find bugs in an app I had never heard of before. Yes, it had a functionality I could actually use in my life so I could have been a customer for that produce.I realised how difficult it is to be a customer and use a product for a very first time.
As testers we have access to so many sources, we have the functional specs, we have analysis of similar products, etc. This forms our basic expectations from the product and we test based on that. Sure we question the spec where it seems against some basic notion to us or we suggest different feature where we 'think' the customer might benefit. But the fact remains that at each point when we are doing that, we already know our product pretty well. While when a customer gets a product, she knows nothing about the product. Either the functionality should be available easily through the UI or she would have to read the entire help. I also realised when you are itching to use a product, you don't want to read the Help. I expected, when I was testing as a customer, that the basic functionality should be apparent through the UI. Sure if I want to do something extra, I would go read the Help. But I should not have to do it as step 1.
As a tester, we should be learn to be a customer, a novice. Forget everything we know about the product and just use it as if we are seeing it for the first time. This would help us give our customers a better product.
As testers we have access to so many sources, we have the functional specs, we have analysis of similar products, etc. This forms our basic expectations from the product and we test based on that. Sure we question the spec where it seems against some basic notion to us or we suggest different feature where we 'think' the customer might benefit. But the fact remains that at each point when we are doing that, we already know our product pretty well. While when a customer gets a product, she knows nothing about the product. Either the functionality should be available easily through the UI or she would have to read the entire help. I also realised when you are itching to use a product, you don't want to read the Help. I expected, when I was testing as a customer, that the basic functionality should be apparent through the UI. Sure if I want to do something extra, I would go read the Help. But I should not have to do it as step 1.
As a tester, we should be learn to be a customer, a novice. Forget everything we know about the product and just use it as if we are seeing it for the first time. This would help us give our customers a better product.
Friday, September 18, 2009
What Testing means to me
Testing to me means finding out what the product should be like better than the designer, knowing what the product does better than the implementers and questioning both the designer, the implementer and the product with the curiosity of a 5 year old.
Being a tester means being able to wear different kind of hats. Wear the customer hat to understand what the product should do, Wearing the developer hats to see what the vulnerabilities in the code could be, wear a writers hat to write the perfect bug report , wear a negotiator hat to convince others why your bug should be fixed.
Being a tester means being able to wear different kind of hats. Wear the customer hat to understand what the product should do, Wearing the developer hats to see what the vulnerabilities in the code could be, wear a writers hat to write the perfect bug report , wear a negotiator hat to convince others why your bug should be fixed.
Subscribe to:
Posts (Atom)