Thursday, June 17, 2010

Project Management Sin:Lust

Lust is intense or unrestrained craving for features; it is experienced when we try to put many features into the product within allocated time and treat every feature as a critical one.
This result in
• Reduced quality
• Overtime
• Lots of surprises in the end.

Agile helps in 3 ways in order to avoid lust during product management.

Developing features in priority order: even if everything is required, product team still needs to prioritize tasks and focus on what is the most important thing to do first.

Incremental Gratification: See progress after every 2 to 4 weeks, so that lust does not get a chance to accumulate.

Working as sustainable pace: Working on a sustainable pace avoids overtime.
You can read last post regading Project management sins form here.

Monday, June 14, 2010

What is pair testing?

Pair Testing is a successful approach to exploratory testing. Inspired by pair programming, this practice groups two testers together for an exploratory testing session. One tester sits at the keyboard and exercises the feature or application while the other tester stands behind or sits next to the first tester and helps to guide the testing.
Both testers are performing exploratory testing, but while one concentrates on driving the functionality, one is thinking about the application from a high level. The testers switch roles at regular intervals.
In an experiment in Micorsoft, it is observed that in a single 8-hour session, 15 pairs of testers found 166 bugs, including 40 classified as severity 1 (bugs that must be fixed as soon as possible). In feedback collected from a survey sent to the 30 participants, only 3 thought that pair testing was less fun than an individual approach is, and 4 four thought it was less effective.

Thursday, June 10, 2010

Why we need gray-box testing?

We often follow quite common approaches like black box and white box testing for SUT (System under test). Black box testing is an approach based on testing an application without any knowledge of the underlying code of the application. Black box approach to testing is a useful method of simulating and anticipating how the customer will use the product. On the other hand, pure black box approaches often end up over-testing certain parts of the application while under-testing other portions.
Conversely, white box testing is an approach that uses test design based on analysis of the underlying source code or schemas not visible to the end user. Test cases founded solely on a white box approach are typically thorough, but nearly always miss key end-user scenarios.
The answer to this dilemma is a gray box (sometimes called glass box) approach. Tests are designed from a customer-focused point of view first (that is, black box), but white box approaches are used to ensure efficiency and test case coverage of the application under test. Testers are responsible for both the customer viewpoint and for determining the correctness of an application. They cannot cover both areas effectively without considering both black box and white box approaches.
Reference: "How we test software at microsoft".

Tuesday, June 8, 2010

Code Debugging while exploratory testing

Yesterday, I was reading a book “How we test software at Microsoft” by Alan page and his colleagues. I liked his approach of debugging the code before designing test cases or doing exploratory testing. I am quoting his words below:

Frequently, when I am testing a component or feature for the first time and I have source code available, I use the debugger to test. Before I even write test cases, I write a few basic tests. These might be automated tests, or they might be just a few ideas that I have scribbled onto a pad. I set a breakpoint somewhere in the component initialization, and then use the debugger to understand how every code path is reached and executed. I note where boundary conditions need testing and where external data is used. I typically spend hours (and sometimes days) poking and prodding (and learning and executing) until I feel I have a good understanding of the component. At that point, I usually have a good idea of how to create an efficient and effective suite of tests for the component that can be used for the lifetime of the product.”