Wednesday, July 29, 2009

Testers Vs Managers

Yesterday, I came across a presentation from Matthew Heusser, I found this joke, si I though it would be great if I share this and post on my blog.

Man Reducing altitude, he spotted a man on the ground and descended to shouting range.

"Excuse me," he shouted. "Can you help me? I promised my friend I would meet him a half hour ago, but I don't know where I am."

The man below responded: "Yes. You are in a hot air balloon, hovering approximately 30 feet above this field. You are between 40 and 42 degrees North Latitude, and between 58 and 60 degrees West Longitude."

"You must be a tester," responded the balloonist.
"I am," the man replied. "How did you know?"

"Well," said the balloonist, "everything you have told me is technically correct, but I have no idea what to make of your information, and the fact is I am still lost."

Whereupon the man on the ground responded, "You must be a manager."

"That I am" replied the balloonist, "but how did you know?"

"Well," said the man, "you don't know where you are, or where you're going. You have made a promise which you have no idea how to keep, and you expect me to solve your problem. The fact is, you are in the exact same position you were before we met, but now it is somehow my fault. “

Sunday, July 26, 2009

Rubber Duck Principle

Code inspections and code walkthrough are two important techniques of human testing, along with formal testing methodologies, these techniques help in finding errors early in the development cycle and reduce the bug count. Theses inspections and walkthroughs help the developers to improve their quality code and reducing bug count. But there is some thing you can do as well.

The simple act of reading aloud your program/Solution/Scenario to yourself is a good technique of finding errors. This technique is also called “Rubber Duck Principle”.

It is applicable to all, whenever you are trying to solve any problem, or as a tester creating scenarios, take any thing on your desk and consider it as “Rubber Duck” :). And explain the whole problem or whole solution to him; you will feel while narrating, you will find other missing parts in your solution or problem.

It will not only help you to identify your problem but also act as a good Peer review as well.

So put something on your desk as “Rubber Duck” as your team member :)

Friday, July 17, 2009

Do not throw test cases

As designing test cases is quite important activity of testing phase , does not matter what approach we are using that is traditional waterfall or agile.
Do not throw test cases until the program life has ended, when we create test cases to test a specific functionality of a module, effort is there to create test cases to cater all scenarios. But after testing if the test cases are thrown away, it would create difficulty when we have to re-test the program it mean the effort we put for creating test cases will be lost so maintaining the repository of test cases is a good practice.

Having test case repositor helps a lot when we are going to automate regression testing as well.

Tuesday, July 14, 2009

What is a successful test case?

Successful test case is one who finds an un-discovered error in the application; test cases are designed having different methodologies like (boundary value analysis, Cause effecting graph, or equivalence partition). Writing test cases which are un-able to cover maximum part of code and obviously have the probability of finding very minimum errors puts question mark in the effectiveness of test cases.
In an organization, development managers use the term “successful test case “ in a different way, it is observed if after executing 50 test cases, 35 test cases find errors in the application while execution, the managers used to say the 35 test cases are not successful and 15 are successful J.
But as we said the test case that finds error in the application is a successful has proven to be a valuable investment and test cases which do not find any error in the application, because designing test cases is a costly activity.

Thursday, July 9, 2009

How to create software model for testing

The reality is that modeling does not represent a new skill. Test engineers always build models. The only question is whether or not the models are in a persistent form. The ‘model’ may only exist for a short time and live on a napkin or in the mind of the engineer.
In order to write a test script or test plan, an engineer must understand the basic steps required to use the system. Modeling at the behavioral level is very similar to flowcharting; the major transactions in the use of the product are defined in a graphical format. The sequence of actions that could occur during the use of the system are defined. The actions that “could” occur also imply that that there may be more than one possible action at a specific point in the process.
There are several approaches that can be used to develop tests from a model; most of these is the concept of a path. A path is a sequence of events or actions that traverse through the model defining an actual use scenario of the system. Each element in a path, a transition or state, can have some test primitives associated with it. The primitives will define what test actions are required to move the system from its current state to the next state, verify that the state is reached or check that the system has responded properly to previous inputs. Once a path through the model has been defined, a test script can be created for that path. When this script is applied to the actual system, the actual system will follow the same sequence (or path) as defined by the model path from which the test script was extracted. This process can then be repeated for another path, which defines another use scenario, and verifies another sequence of actions. Many methods can be used to select paths, each with its own distinct objectives and advantages.
Just for example, I have shown a sample login flow chart, here we have build model for login functionality, and we mapped the paths, both successful and un successful. Now it is same thing that testers usually have in his mind, by building model, we translated our application flow in the form of model, now considering each path, we can design our test cases.

This short description is taken from the article from Larry Apfelbaum and John Doyle and login flow chart is just for sample from downloaded from google.

looking for your feedback :)

Tuesday, July 7, 2009

Help your project manager to decide about shipment

Project Manger: can we ship our new release on this weekend?
QA: hmm, well, there are few critical bugs that are show stopper. if we ship the code to the client, we will suffer a lot in the production support.
Project Manager: ok, let me talk to Dev TL

This conversation is a part of our professional life and we often come across such statements. The job of software testers/Quality engineer is to find bugs but there are some other important things that can add value to over all products like

Block premature product releases.
This tester stops premature shipment by finding bugs so serious that no one would ship the product until they are fixed. For every release decision meeting, the tester’s goal is to have new showstopper bugs.
Help managers make ship / no-ship decisions.
Managers are typically concerned with risk in the field. They want to know about coverage (maybe not the simplistic code coverage statistics, but some indicators of how much of the product has been addressed and how much is left), and how important the known problems are. Problems that appear significant on paper but will not lead to customer dissatisfaction are probably not relevant to the ship decision.
Minimize technical support costs.
Working in conjunction with a technical support or help desk group, the test team identifies the issues that lead to calls for support. These are often peripherally related to the product under test.

I think it is quite important that quality engineer should know about the overall status of the release, about its stability, and helping project mangers and other stake holders in making decision about the shipment of release

I have taken these testing objectives from Cem kaner article “What is a good test case”.You can consult in case of further reading

Sunday, July 5, 2009

Model Based Testing (Testing using flow Diagrams)

What is Model Based Testing
Few days back, my dearest teacher and good friend of mine Zahid Irfan, replied to my post and asked me about my view on model based testing, his questions inclined me to read some more material about model based testing, so that I can answer his question, After studying lot of material I am summarizing my views about model based testing.

Models are used to understand, specify and develop systems in many disciplines. , models are used to establish understanding and provide a reusable framework for product development. In the software engineering process, models are now accepted as part of a modern object oriented analysis and design approach by all of the major OO methodologies. Model based testing has given a innovative way of test case designing, in most of the software development projects, test cases are derived from RS (Requirement specification) or FS (functional specification).

Designing test cases by using model of the software helps the tester in finding and exploring different paths or scenarios for the end user, modeling technique also helps in determining the correct output at given path

Problems in Textual Description
The traditional means of specifying the correct system behavior is with English prose in the form of a Requirement Specification or Functional specification. The specification, , is often incomplete - only the typical or ideal use of the feature(s) is defined, not all of the possible actions or use scenarios. This incomplete description forces the test engineer to wait until the system is delivered so that the entire context of the feature is known. When the complete context is understood, tests can be developed that will verify all of the possible remaining scenarios. Another problem with textual descriptions is that they are ambiguous, (i.e., “if an invalid digit is entered, it shall be handled appropriately.”) The ‘appropriate’ action is never defined; rather, it is left to the reader’s interpretation. For example, you think we should allow the user to retry the entry, but I think we should abort the command. If you wrote the code and I wrote the tests, they would fail and we will waste time resolving an issue that could have been done before we even started. At a recent Requirements Engineering Conference, papers and presentations described the root cause of 60-80% of all defects as incorrect requirements specifications.

Advantages of Model Based Testing
Modeling is a very economical means of capturing knowledge about a system and then reusing this knowledge as the system grows. For a testing team, this information is gold; what percentage of a test engineer's task is spent trying to understand what the System under Test (SUT) should be doing? Once this information is understood, how is it preserved for the next engineer, the next release, or change order? If you are lucky it is in the test plan, but more typically buried in a test script or just lost, waiting to be rediscovered. By constructing a model of a system that defines the systems
Desired behavior for specified inputs to it, a team now has a mechanism for a structured analysis of the system.
Scenarios are described as a sequence of actions to the system [as it is defined in the model], with the correct responses of the system also being specified.
The largest benefit is in reuse; all of this work is not lost. The next test cycle can start where this one left off. If the product has new features, they can be incrementally added to the model;
if the quality must be improved, the model can be improved and the tests expanded; if there are new people on the team, they can quickly come up to speed by reviewing the model.

It is just a brief description; I would like to continue to post some more material about model based testing.

Articles from Larry Apfelbaum and John Doyle helped me a lot in writing this post.