Wednesday, July 29, 2009
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
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 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
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
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.
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
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
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.