Choosing right scripting technique/Framework for Automation Testing

While planning for automation testing for any project, a tough question for Testing automation engineers are – “Which automation scripting techniques or framework should be chosen?”

Selenium for Functional testing of web applications

Functional testing and black box is a methodology used to test the behavior that has an application from the viewpoint of their functions, validated for this purpose various aspects ranging from the aesthetics of the front end, the navigation within your pages between pages within the forms, the compliance of technical specifications associated with fields, buttons, bars, among other pages, entry permits and access to consultations and modifications, management of parameters, the management of the modules that constitute , and other conditions that make up the various "features" expected to provide the system to operate the end user as a normal and correct.

Types of Software errors and bugs | Most Common Software bugs

by Padmini C (Author of Beginners guide to Software Testing)

Following are the most common software errors that aid you in software testing. This helps you to identify errors systematically and increases the efficiency and productivity of software testing. This topic surely helps in finding more bugs more effectively :) . Also, you can use this as a checklist while preparing test cases and while performing testing.

Measuring Software test effectiveness

The main objectives of testing are to establish confidence and to find defects. This article describes some measures for test effectiveness.
Defect Detection Percentage (DDP)
DPP = Defects known by testing/Total Known Defects

HP WinRunner exam HP0-M12 sample questions

HP WinRunner exam HP0-M12 sample questions. These questions will definitely help you is passing the exam with good score.

Step by Step guide to Test Case Development

 .. Continuing the Beginners Guide to Software Testing series
est Case is a commonly used term for a specific test. This is usually the smallest unit of testing. A Test Case will consist of information such as requirements testing, test steps, verification steps, prerequisites, outputs, test environment, etc.

A Test Case is:
- A set of inputs, execution preconditions, and expected outcomes developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.

- A detailed procedure that fully tests a feature or an aspect of a feature. Whereas the test plan describes what to test, a test case describes how to perform a particular test. You need to develop a test case for each test listed in the test plan.
Test cases should be written by a team member who understands the function or technology being tested, and each test case should be submitted for peer review.

Organizations take a variety of approaches to documenting test cases; these range from developing detailed, recipe-like steps to writing general descriptions. In detailed test cases, the steps describe exactly how to perform the test. In descriptive test cases, the tester decides at the time of the test how to perform the test and what data to use.

Software Testing Techniques

Test Design Techniques

The purpose of test design techniques is to identify test conditions and test scenarios through which effective and efficient test cases can be written.Using test design techniques is a best approach rather the test cases picking out of the air. Test design techniques help in achieving high test coverage. In this post, we will discuss the following:
1. Black Box Test Design Techniques
  • Specification Based
  • Experience Based
2. White-box or Structural Test design techniques

Difference between Test Plan and Test Strategy | Do we really need Test Plan documents?

In this post we will discuss:
  • Difference between Test Plan and Test Strategy (by both theoretically as per IEEE829 and practically, i.e. what actually happens in testing projects) in brief and simple manner.
  • Do we really need Test Plan documents?

Tricky Software testing Terms

What is Ramp Testing? - Continuously raising an input signal until the system breaks down.
What is Depth Testing? - A test that exercises a feature of a product in full detail.
What is Quality Policy? - The overall intentions and direction of an organization as regards quality as formally expressed by top management.
What is Race Condition? - A cause of concurrency problems. Multiple accesses to a shared resource, at least one of which is a write, with no mechanism used by either to moderate simultaneous access.

SQL For Testers – Part 2

After reading part 1, now you are aware of –
  • Why database testing is necessary?
  • Differences between backend testing and front end testing
  • Backend testing phases / Database Testing Phases
  • Backend test methodology / Database Testing methodology
  • Basics of SQL
Now lets put more focus on SQL Statements -

V Model to W Model | W Model in SDLC Simplified

We already discuss that V-model is the basis of structured testing. However there are few problem with V Model. V Model Represents one-to-one relationship between the documents on the left hand side and the test activities on the right. This is not always correct. System testing not only depends on Function requirements but also depends on technical design, architecture also. Couple of testing activities are not explained in V model. This is a major exception and the V-Model does not support the broader view of testing as a continuously major activity throughout the Software development life-cycle.

Selenium Interview Questions

Posting the Interview questions of Selenium - Automated Software Testing Tool..

Software Testing Checklist - Major Areas of Testing - What to Look at?

In this post we will discuss the points to take care while testing following applications:
  • PRINTERS AND DRIVERS – Interface software

CSTE Sample Papers | CSTE Sample Questions

On Readers request, I am posting CSTE Certification practice questions.

CSTE Certification Essay based questions:
1. What fields would you include in creating a new defect tracking program (used by QA, developers, etc)? (25 points)
a. Draw a pictorial diagram of a report you would create for developers to determine project status.
b. Draw a pictorial diagram of a report you would create for users and management to show project status.
2. What 3 tools would you purchase for your company for use in testing and justify why you would want them? (this question is in both essay parts, only rephrased. I think 10 points each time)

Asnwers to advanced software Testing Interview Questions

Ans 1: Advantages of path coverage metric of software testing:
Path coverage requires extremely thorough testing.
Disadvantages of path coverage metric of software testing:
1) Since loops introduce an unbounded number of paths, this metric considers only a limited number of looping possibilities.
2) The number of paths is exponential to the number of branches. For example, a function containing 10 if-statements has 1024 paths to test. Adding just one
more if-statement doubles the count to 2048.
3) Many paths are impossible to exercise due to relationships of data.

Advanced Software Testing Interview Questions – Part 1 (Advanced Level)

Below are some advanced level/ Test lead level Software Testing Questions. Answer now and Judge yourself.

Tips for Software Testing Resume

The purpose of this article to show you how to write a Software Testing Resume which get the most out of your qualifications.  A good software tester resume helps you articulate your skills and opens the door for a job interview. 
Lets Check the Sample Software Testing Resume below:

Bug triage Meeting Process

.. Continuing the Test Management Series
Bug Triage Meeting -
A meeting held by the CFT**, QA Group, Test Manager, Quality Manager, Project Manager; Product Manager and Testing Leads for any project. The objective of the meeting is to prioritize and track the defects to be addressed, ensuring timely and accurate resolution. During iterative Quality Assurance testing, the QA department logs defects. In Bug Triage, the bugs are prioritized to determine when bug fixes are to be releases, the difficulty of the fix and the difficulty of retest.
[**CFT - Cross Functional Team - An inter-departmental team comprising a Cross-Functional Team Leader and team members representing a network of experienced and knowledgeable staff members. The Cross-Functional Team concept allows staffing levels for each development discipline to increase and decrease at the proper times during the development cycle.]

How and When Testing Starts

.. Continuing the Beginners Guide to Software Testing series
For the betterment, reliability and performance of an Information System, it is always better to involve the Testing team right from the beginning of the Requirement Analysis phase. The active involvement of the testing team will give the testers a clear vision of the functionality of the system by which we can expect a better quality and error-free product.

Once the Development Team-lead analyzes the requirements, he will prepare the System Requirement Specification, Requirement Traceability Matrix. After that he will schedule a meeting with the Testing Team (Test Lead and Tester chosen for that project). The Development Team-lead will explain regarding the Project, the total schedule of modules, Deliverable and Versions.

The involvement of Testing team will start from here. Test Lead will prepare the Test Strategy and Test Plan, which is the scheduler for entire testing process. Here he will plan when each phase of testing such as Unit Testing, Integration Testing, System Testing, User Acceptance Testing. Generally Organizations follow the V – Model for their development and testing.

Requirement Specification document Review Guidelines and Checklists

To prepare effective test cases, testers and QA engineers should review the software specs documents carefully and raise as much queries as they can.
The purpose of Software Requirement Specification Review is to uncover problems that are hidden within the specification document. This is a part of defect prevention. These problems always lead the software to incorrect implementation. So following guidelines for a detailed specification review is suggested:

Role of a tester in defect prevention and defect detection

Some Testers (especially beginners) often get confused with this Question - “What is the role of a tester in Defect Prevention and Defect Detection?”. In this post we will discuss the role of a tester in these phases and how to testers can prevent more defects in Defect Prevention phase and how testers can detect more bugs in Defect Detection phase

HP QTP Certification HP0-M016 Exam Sample Question Bank

Question Bank:
1. QTP workflow Phases
2. what are the conditional statements provided in QTP?
3. Break point is used to :
4. What is the first step to change the logical name of the object recorded by Quick test?
5. Where can you find the result of an output parameter?
6. Where do you set action iterations for a specified action?
7. which of the following is created by default with new action?
8. What are the default addins provided by QTP?
9. Which source property specifies that data is retrieved from database?
10. Local object Repository is used for Single action tests.
11. shared object Repository is created in Object Repository Manager.
12. which tool is used to merge two shared object repositories.
13. Low level Recording is used to record:
14. virtual objects are stored in : dat folder…
15. bitmap checkpoint takes into consideration:
16. When using recovery scenario wizard ,the first phase is to specify : Trigger
17. Trigger events : popup window,object state, test run error,application crash

QTP Sample paper - Part 14 - **** Mostly asked questing in QTP Certification - 5...

1) You cannot expand ...... actions from the test flow
A) reusable
B) non-reusable
C) both A & B
D) None

2) You can associate shared object repositories with
...... actions simultaneously, using the Associate
Repositories dialog box
A) seven
B) Two
C) Three
D) Multiple

QTP Sample paper - Part 13 - **** Mostly asked questing in QTP Cerification - 4...

1. When a procedure is created in the Function Library editor, what is the extension on the file?


2. What are the categories in the Step Generator?

A. Object, Operation, Value
B. Library, Built-in, Local Script
C. Operation, Arguments, Return Value
D. Test Objects, Utility Objects, Functions

QTP Sample paper - Part 12 - **** Mostly asked questing in QTP Cerification - 3...

1) You can import and export object repositories from
and to .... files.

2) In general, the ....... object repository is
easiest to use when you are creating simple record and
run tests.
A) Shared
B) Local
C) Both
D) None

3) The Object Repository automation object model
enables you to manipulate QuickTest ....... object
repositories and their contents from outside of
A) Shared
B) Local
C) Both
D) None

QTP Certification HP0-M16 Practice Questions - Set 10

91) An ........ assigns a numerical value to a test object that indicates its order or location relative to other objects with an otherwise identical description (objects that have the same values for all properties)
A) Index identifier.
B) ordinal identifier.
C) SMART ID identifier.
D) original identifier.

92) You can add an object to the local object repository only if that object does not already exist in a shared object repository that is associated with the action. If an object already exists in an associated shared object repository, you can add it to the local object repository using the ........ option.
A) Copy from Shared Repository
B) Copy from Shared Object Repository
C) Copy to Local
D) Copy to Local repository

QTP Certification HP0-M16 Practice Questions - Set 9

81) In the Object Repository window:.
A) Local objects are editable (black)
B) Shared objects are in read-only format (gray)
C) Local objects are in read-only format (gray)
D) Shared objects are editable (black)

82) Mark true statement(s):.
A) You can delete objects from a shared object repository using the Object Repository window.
B) You can delete objects from the local object repository using the Object Repository Manager
C) You can delete objects from the local object repository using the Object Repository window
D) You can delete objects from a shared object repository using the Object Repository Manager

QTP Certification HP0-M16 Practice Questions - Set 8

71) QuickTest processes a comments when it runs a test.

A) True
B) False

72) Press ..... to add a new step below the currently selected step.

A) F8
B) Shift + A
C) F0
D) Shift + A + Q

73) While working with the Keyword View, you can ...... steps to move
them to a different location in a test or in an action

A) Copy and Paste
B) Cut and Paste
C) Drag and drop
D) Both A) and C)

QTP Certification HP0-M16 Practice Questions - Set 7

Read QTP Certification sample Questions – Part 6
61) You can use the Keyword View to add a step your test.

A) at the end
B) below the currently selected step
C) at the beginning
D) at anypoint

62) The Documentation cell is .............

A) Read-only
B) Write-only
C) Read and Write
D) Read, write & execute

QTP Certification HP0-M16 Practice Questions - Set 6

Read QTP Certification sample Questions – Part 5
51) Using the Object Spy, you can view

A) the run-time or test object properties and methods of any object in
an open application.
B) the run-time or test object properties of any object in an open
C) the test object properties and methods of any object in an open
D) the run-time object properties and methods of any object in an open

52) There are .........object type filters in Object spy dialog box.

A) Two
C) Four
D) Five

QTP Certification HP0-M16 Practice Questions - Set 5

Read QTP Certification sample Questions – Part 4
41) Object Spy can be found in

A) Tool
B) Tools
C) Task
D) Tasks

42) ............ displays the open documents side-by-side.

A) Tile Vertically
B) Tile Horizontally
C) Cascade
D) Tile Cascade

43) For opening the QuickTest Professional Help we can use.......

A) F3
B) F5
C) F1
D) F2

QTP Certification Practice Questions - Set 4

31) You can manage the test actions and the test or function library
steps using the ... menu commands

A) File
B) Edit
C) Automation
D) Tools

32) To expand all the steps in the keyword view which option you would
use from the View menu.

A) Expand
B) Expand All
C) Expand Items
D) Expand Rows

QTP Certification Practice Questions - Set 3

21) Panes in QTP can have one of the following states—docked or floating.

A) True
B) False

22) Which of the following statement is True:

A) QuickTest enables you to open and work on one test at a time
B) QuickTest enables you to open and work on two tests at a time
C) QuickTest enables you to open and work on predefined number of tests
at a time
D) QuickTest enables you to open and work on nine test at a time

23) Which of the following statement is True:

A) You can open and work on two function libraries simultaneously
B) You can open and work on multiple function libraries simultaneously
C) You can open and work on nine function libraries simultaneously
D) You can open and work on one function library at a time

QTP Certification Practice Questions - Set 2

Read QTP Certification sample Questions – Part 1
11) The Information pane provides a list of............. in the test:

A) Semantic errors
B) Syntax errors
C) Common errors
D) Logic errors

12) When we switch from Expert view to the Keyword view, QTP
automatically checks for syntax errors in the test and shows them in the
information pane.

A) True
B) False

13) If the information pane is not open, QTP automatically opens it in
case a syntax error is detected.

A) True
B) False

QTP Certification Practice Questions - Set 1

QTP Questions 1

1) 'Browser navigation timeout' is in which tab of Test Settings
(File Settings) window.

A) Properties
B) Resources
C) Web
D) Web Settings

2) How many tabs are there in Test Settings (File->Settings) window

A) 7
B) 6
C) 5
D) 8

3) Identify the tabs in the Test Settings (File->Settings) window

A) Properties, Run, Resources, Parameters, Environment, Web, Recovery
B) Properties, Run, Resources, Parameters, Environment, Web
C) Properties, Run Options, Resources, Parameters, Environment, Web,
D) Properties, Run, Resources, Input Parameters, Environment, Web, Recovery

When to Stop Testing | Testing Completion Criteria

.. Continuing the Beginners Guide to Software Testing series
Testing should be stopped when it meets the completion criteria. Now how to find the completion criteria? Completion criteria can be derived from test plan and test strategy document. Also, re-check your test coverage.
Completion criteria should be based on Risks. Testing should be stopped when -
  • Test cases completed with certain percentage passed and test coverage is achieved.
  • There are no known critical bugs
  • Coverage of code, functionality, or requirements reaches a specified point;
  • Bug rate falls below a certain level, now testers are not getting any priority 1, 2, or 3 bugs.
As testing is a never ending process we can never assume that 100 % testing has been done, we can only minimize the risk of shipping the product to client with X testing done. The risk can be measured by Risk analysis but for small duration / low budget / low resources project, risk can be deduced by simply: -
  • Measuring Test Coverage.
  • Number of test cycles.
  • Number of high priority bugs.

Game Testing Tips and Considerations

Author - unknown. [If you know the author, or if you are the author please contact us, we will update the  post]

Video games are also considered as software that needs sufficient testing before releasing in the market. In fact, many software developers want to become game developers.
Game testing is the process of verifying game environment and behaviour. Its occurrence in game development depends on its budget. High-budgeted projects test their products when the draft version is finished. On the other hand, low-budgeted games might only support testing of the probable final version. Other types like public betas and stress tests are also used in actual game industry, but it less systematic and scientific because testing is being done by simply playing the game from the start to finish and reporting random bugs that occur and detected accidentally. Scientific and methodological approaches in testing have the following purposes:

QTP Descriptive Programming - How to get number of objects

In this article, Dmitri Motevich explains QTP Descriptive Programming (DP) through Google Sets site:
The goal of the present QTP tutorial is to describe:
How to get number of controls (Links, Edits, Images, etc) with QTP DP.

Let's investigate Descriptive Programming on examples.First of all, we should understand what Descriptive Programming means:


QTP DP is a run-time processing of objects which are not located in QTP Object Repository.
I've created new QTP script which starts with page.

Tutorial Database Testing using SQL | SQL for Testers

The demand for "all round" testers, i.e. being able to test the system's functionality through traditional testing methods and being able to show some technical knowledge is growing.

Basics of Database testing contains the following:
1. How to connect to the database?
2. Ability to write simple queries to retrieve data and manipulate the data using DML operations.
3. Functional flow should be very well known!
4. Good knowledge on table level, column level constraints, ability to understand and execute complex queries related to joins is added advantage.
Contents of this tutorial:

Concept of Complete Testing | Exhaustive testing is impossible

.. Continuing the Beginners Guide to Software Testing series

It is not unusual to find people making claims such as “I have exhaustively tested the program.” Complete, or exhaustive, testing means there are no undiscovered faults at the end of the test phase. All problems must be known at the end of complete testing. For most of the systems, complete testing is near impossible because of the following reasons:
  • The domain of possible inputs of a program is too large to be completely used in testing a system. There are both valid inputs and invalid inputs.
    The program may have a large number of states. There may be timing constraints on the inputs, that is, an input may be valid at a certain time and invalid at other times. An input value which is valid but is not properly timed is called an inopportune input. The input domain of a system can be very large to be completely used in testing a program.
  • The design issues may be too complex to completely test. The design may have included implicit design decisions and assumptions. For example, a programmer may use a global variable or a static variable to control program execution.
  • It may not be possible to create all possible execution environments of the system. This becomes more significant when the behaviour of the software system depends on the real, outside world, such as weather, temperature, altitude, pressure, and so on.
[From book - Software testing and quality assurance: theory and practice By Kshirasagar Naik, Priyadarshi Tripathy]

Must Read: Testing Limitations
The Impossibility of Complete Testing by Dr. Cem Kaner

Testing Limitations

.. Continuing the Beginners Guide to Software Testing series
Testing Limitations
  • You cannot test a program completely
  • We can only test against system requirements
- May not detect errors in the requirements.
- Incomplete or ambiguous requirements may lead to inadequate or incorrect testing.
  • Exhaustive (total) testing is impossible in present scenario.
  • Time and budget constraints normally require very careful planning of the testing effort.
  • Compromise between thoroughness and budget.
  • Test results are used to make business decisions for release dates.
  • Even if you do find the last bug, you’ll never know it
  • You will run out of time before you run out of test cases
  • You cannot test every path
  • You cannot test every valid input
  • You cannot test every invalid input
Must ReadThe Impossibility of Complete Testing by Dr. Cem Kaner

Practical interview questions on Software Testing - Part 1

.. Continuing the Beginners Guide to Software Testing series
1. On which basis we give priority and severity for a bug and give one example for high priority and low severity and high severity and low priority?
Always the priority is given by team leader or Business Analyst. Severity is given by the reporter of bug. For example, High severity: hardware bugs application crash. Low severity: User interface bugs. High priority: Error message is not coming on time, calculation bugs etc. Low priority: Wrong alignment, etc
2. What do you mean by reproducing the bug? If the bug was not reproducible, what is the next step?
If you find a defect, for example click the button and the corresponding action didn’t happen, it is a bug. If the developer is unable to find this behaviour he will ask us to reproduce the bug. In another scenario, if the client complaints a defect in the production we will have to reproduce it in test environment.
If the bug was not reproducible by developer, then bug is assigned back to reporter or goto meeting or informal meeting (like walkthrough) is arranged in order to reproduce the bug. Sometimes the bugs are inconsistent, so that that case we can mark the bugs as inconsistent and temporarily close the bug with status working fine now.

Descriptive Programming in QTP

Descriptive Programming:

When we start recoding on any application with QTP, QTP learns the object by adding some of its properties in Object Repository. QTP uses default Object Identification properties: mandatory and assistive to learn objects. For more information on how QTP learn objects, read this article. and QTP Object Identification tutorial.
Whenever QTP records any action on any object of an application, it adds some description on how to recognize that object to a repository of objects called object repository. QTP cannot take action on an object until unless its object description is in the Object Repository.

But descriptive programming provides a way to perform action on objects which are not in Object repository.

Download the Descriptive Programming Tutorials for QTP.
Document 1: Download - Basics of Descriptive Programming in QTP. [Note - This is writtern by Tarun Lalwani using QTP 8.2. It is atill applicable to all QTP versions.. A must read]

Document 2: Converting OR (Object Repository) Based scripts to Descriptive Programming
Document 3: Descriptive Programming Dummy Properties
Document 4: General issues people face while using Descriptive Programming (DP) in QTP.

Author - Tarun Lalwani (

Related posts - Book Review QuickTest Professional Unplugged.

QTP: Object Repository, Descriptive Programming and Beyond

This excellent and self explained presentation is prepared by Prepared by: Igor Gershovich.
  • This presentation explains the following:
  • Object Repository vs. Descriptive Programming –what to use?
  • OR Pros and Cons
  • DP Pros and Cons
  • QTP Scripting Using Object Repository
  • QTP Scripting Using Descriptive Programming
  • Descriptive programming – when and why?
  • Different ways to work with objects
  • ChildObjects method – using Collection Object
  • Regular Expressions in Object Repository
  • TO, RO and .Object methods in QTP
  • Run-Time “Native” Object Properties/Methods  from AUT
  • Object Smart Identification

Equivalence Class Partitioning Simplified

.. Continuing the Beginners Guide to Software Testing series
Concepts:   Equivalence partitioning is a method for deriving test cases.  In this method, classes of input conditions called equivalence classes are identified such that each member of the class causes the same kind of processing and output to occur.
In this method, the tester identifies various equivalence classes for partitioning.  A class is a set of input conditions that are is likely to be handled the same way by the system.  If the system were to handle one case in the class erroneously, it would handle all cases erroneously.
Equivalence partitioning significantly reduces the number of test cases required to test a system reasonably.  It is an attempt to get a good 'hit rate', to find the most errors with the smallest number of test cases.
To use equivalence partitioning, you will need to perform two steps
1. Identify the equivalence classes
2. Design test cases

Gray Box Testing

.. Continuing the Beginners Guide to Software Testing series
Gray Box Testing -
  • It is just a combination of both Black box & white box testing.
  • It is platform independent and language independent.
  • Used to test embedded systems.
  • Functionality and behavioral parts are tested.
  • Tester should have the knowledge of both the internals and externals of the function
  • If you know something about how the product works on the inside, you can test it better from the outside.
Gray box testing is especially important with Web and Internet applications, because the Internet is built around loosely integrated components that connect via relatively well-defined interfaces. Unless you understand the architecture of the Net, your testing will be skin deep.
Go back to Test Design Techniques

White Box Testing

.. Continuing the Beginners Guide to Software Testing series
White Box Testing
  • Testing the Internal program logic
  • White box testing is also called as Structural testing.
  • User does require the knowledge of software code.
  • Testing all loops
  • Testing Basis paths
  • Testing conditional statements
  • Testing data structures
  • Testing Logic Errors
  • Testing Incorrect assumptions
Structure = 1 Entry + 1 Exit with certain Constraints, Conditions and Loops.
Logic Errors and incorrect assumptions most are likely to be made while coding for “special cases”. Need to ensure these execution paths are tested.

Test Design Techniques

Methods of Black box Testing

.. Continuing the Beginners Guide to Software Testing series
The following basic techniques are employed during black box testing:
  • Equivalence Class
  • Boundary Value Analysis
  • Error Guessing

Black Box Testing

.. Continuing the Beginners Guide to Software Testing series
What is Black Box Testing?
  • Test the correctness of the functionality with the help of Inputs and Outputs.
  • User doesn’t require the knowledge of software code.
  • Black box testing is also called as Functionality Testing.
  • Testers make sure that software is working as per the requirements.
It attempts to find errors in the following categories:
  • Incorrect or missing functions.
  • Interface errors.
  • Errors in data structures or external data base access.
  • Behavior or performance based errors.
  • Initialization or termination errors.
Read – Approaches used in Black Box Testing

Fault, Error and Failure

.. Continuing the Beginners Guide to Software Testing series
Fault : It is a condition that causes the software to fail to perform its required function.
Error : Refers to difference between Actual Output and Expected output.
Failure : It is the inability of a system or component to perform required function according to its specification.
IEEE Definitions
  • Failure: External behavior is incorrect
  • Fault: Discrepancy in code that causes a failure.
  • Error: Human mistake that caused fault
  • Error is terminology of Developer.
  • Bug is terminology of Tester

What Is Software Testing?

.. Continuing the Beginners Guide to Software Testing series
Definitions of Software Testing -
  • It is the process of Creating, Implementing and Evaluating tests.
  • Testing measures software quality
  • Testing can find faults. When they are removed, software quality is improved.
  • Testing is executing a program with an indent of finding Error/Fault and Failure.
  • IEEE Terminology : An examination of the behavior of the program by executing on sample data sets.

Why is Software Testing Important?

.. Continuing the Beginners Guide to Software Testing series
1. To discover defects.
2. To avoid user detecting problems
3. To prove that the software has no faults
4. To learn about the reliability of the software.
5. To avoid being sued by customers
6. To ensure that product works as user expected.
7. To stay in business
8. To detect defects early, which helps in reducing the cost of defect fixing?

Read – Why start testing early?

Defect Density

Defect Density
What are various ways of calculating defect density?
The formula itself is simple: Density = Total Defects Found / Size
if we see defect density at granular level say Codesize of a particular functionality X in a application Y along with number of files, then we may draw some good observations like -

Mercury Quality Center Interview Questions

1. What is meant by test lab in Quality Centre?
Test lab is a part of Quality Centre where we can execute our test on different cycles creating test tree for each one of them. We need to add test to these test trees from the tests, which are placed under test plan in the project. Internally Quality Centre will refer to this test while running then in the test lab.
2. Can you map the defects directly to the requirements(Not through the test cases) in the Quality Centre?
In the following methods is most likely to used in this case:
  • Create your Req.Structure
  • Create the test case structure and the test cases
  • Map the test cases to the App.Req
  • Run and report bugs from your test cases in the test lab module.
The database structure in Quality Centre is mapping test cases to defects, only if you have created the bug from Application. test case may be we can update the mapping by using some code in the bug script module(from the customize project function), as per as i know, it is not possible to map defects directly to an requirements.

HP0 M15 Quality Center Certification Questions

HP0 M15 Quality Center Certification sample Preparation Questions:
1) Quality Center is
- an ERP
- a standalone software
- a web based (client/server) tool
- a script
2) Traceability Alert is depicted with "@" Mark against a Test
- Yes
- No

Effective Handbook for Implementing Test Strategies

A strategy in its synonym is a preparation for long-term battle plans or making plans to achieve a goal. It might involve giving up a destructive habit or addiction or it might be a matter of recognizing a self-defeating pattern of behavior and somehow seeing how to change it.
For example the bulk of testing hours of a tester goes in to testing the product again and again for different releases in the same pattern. At a certain phase it leads to frustration of the testers for doing things repeatedly. It happens sometimes that when someone is frustrated he may sound something like, “I know its possible to see this (or experience) differently”. And often, this awareness or even hope that there is another way of experiencing your dilemma, or problem opens the door for it to occur. This is where strategies come in.

Defining a Test Strategy

A solid testing strategy provides the framework necessary to implement your testing methodology. A separate strategy should be developed for each system being developed taking into account the development methodology being used and the specific application architecture.

The heart of any testing strategy is the master testing strategy document. It aggregates all the information from the requirements, system design and acceptance criteria into a detailed plan for testing. A detailed master strategy should cover the following:

Creating a Test Strategy

The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.

Inputs for this process:

Test Strategy

In This topic we will discuss, what is a Test Strategy, Why test strategy is required, how to create a Test Strategy, Defining Test Strategy, Requirements in Test Strategy and Key points to remember in Test Strategy.

A simple approach to Software Test Estimation

A very simplistic method for estimating testing time can be as follows for a typical black box testing assignment .
Total Time=No of cycles*(Time for each testing cycle+time for fixing of bugs found in one cycle)
So if you have an estimated time of testing cycle as 6 days and you expect that the developers are going to take 4 days for fixing bugs found in one cycle and if the number of testing cycles are estimated as 4 then
Total time = 4*( 6+4)
Total time= 40 days

Software Testing Effort Estimation

This topic is a mixture of practical experiences and estimation theory (estimation science, theoretical knowledge). The purpose of this topic that the Test Leads, Managers or aspiring leads, managers must aware of all the test estimation techniques. This will helps in clearing interviews and in test planning as well. In the upcoming topics we will discuss the Guidelines and Principles for Test Estimations.
Introduction - Estimation is done often because it is expected to help in predicting how much will the project cost and when will the project get completed. Proper analysis and effort estimation is necessary for successfully planning for a testing project. Any flaw in critical estimation phase, results in missing the project deadlines, reduces ROI and loses of customer’s faith. Remember - Bad estimation can lead to poor distribution of work. 

There are different standard and non standard methods for test estimation. In many product based companies, people utilize non standardized but conventional estimation methods to make things work. These methods might have developed over a continuous period accommodating hidden factors like nature of application under test, environment, and risk factors for that specific product/market. But these methods can’t be adopted as a generalized organization standard for a mature operation model.

Fact: Managers/Leads are not comfortable with software estimation work. But it is a required activity, so based on their past experience on one particular Product, Test Leads/Test Managers estimate the entire testing project (but for that Product only). Because they spent 1-2 or 2-3 or even more years on that particular product. But if they are asked to change company or shift to new product of entire different domain, then it is very hard for them to do estimation.

Estimation Guidelines for Testing Projects

There are several factors, which have to be considered while estimating a testing project. The stability of the application to be maintained is a crucial element while estimating testing projects. A generic estimation methodology is very difficult to arrive at. At best, one could highlight the factors that influence estimation in such projects. Hence estimation largely is based on the information and experiences from previous projects. As in other cases these estimates are validated as the project progresses.

Software Testing Post Project Reviews

The Post Project Review (or sometimes referred to as the Post Implementation Review) is a key review meeting taking place one month after the implementation of a project (or sooner if metrics are available). This review includes all team members involved in the project.
The main purpose is to review all testing activities, the effectiveness of the testing and allow comments to be made on the development procedures. The primary purpose of the Post Project Review (PPR) is to see improvements made on future projects – to learn from our mistakes and also to recognize aspects of the project that were good.

Traceability Matrix from Software Testing perspective

This is a very helpful topic for test leads and managers (also for junior testers if they want to grow).
Traceability Matrix is used in entire software development life cycle phases:
    1. Risk Analysis phase
    2. Requirements Analysis and Specification phase
    3. Design Analysis and Specification phase
    4. Source Code Analysis, Unit Testing & Integration Testing phase
    5. Validation – System Testing, Functional Testing phase

    Selecting a Software testing Tool | Testing Tools Evaluations

    One of the challenging job for Test Managers and Test Architects is to select a testing tool. Choosing an automated software testing tool is an important step, and one which often poses enterprise-wide implications. Here are several key issues, which should be addressed when selecting an application testing solution. Below are some basic guidelines for selecting and evaluating Software Testing tools for different phases:

    Security Testing – Secure Software Development Lifecycle

    Phase 1: Define Security Guidelines, Rules and Compliance Regulations
    First, create a system-wide specification that defines the security requirements that apply to the system; it can be based on specific government regulations. One such company-wide regulation could be the Sarbanes-Oxley Act of 2002, which contains specific security requirements.

    Phase 2: Document Security Requirements, Develop Attack Use Cases
    A common mistake is to omit security requirements from any type of requirements documentation. Not only do security requirements aid in software design, implementation and test case development, they also can help determine technology choices and areas of risk.

    Unit Testing - Points to take care

    White box testers, Unit Testers, Development Teams usually heard these  words from managers - “After performing unit testing Why manual testing team still finding critical bugs? Why you are not performing Unit Testing?”
    Actual – They perform unit testing but not standard unit testing. When writing the unit test consider the following when looking for things to test:

    The Testing Mindset

    .. Continuing the Beginners Guide to Software Testing series
    A professional tester approaches a product with the mind-set that the product is already broken - it has bugs and it is their job to find out them. They suppose the application under test is inherently defective and it is their job to ‘illuminate’ the defects.

    Practical Test Reporting

    It is very likely you‘ll meet a lot of opposition when you give opinions like ‘this is not good enough to go live’. In test reporting it is strongly recommended to stick to the facts. Do test reporting periodically (e.g. every 2 weeks). This will give valuable information to other project parties. It is said that a software project is like driving on a long, dark road and testing provides the headlights. It is very likely that testing is the only party in the project organisation that has a clear view on the real progress of the project. Share this knowledge!

    Guide to Effective Test Status Reporting and Metrics Collection – Part 1

    Test Status Report
    Test Status Reporting is a formalized reporting on the status of the project from a testing point of view. This is part of the project Communication plan. The Report shows quantitative information about the project.
    Test Status Reporting is the component that informs key project stakeholders of the critical aspects of the project's status. Good status reporting prevents surprises to project sponsors and stakeholders. Formal status reporting needs to be provided as part of the project steering committee meetings.

    Golden Rules for Bug Reporting

    Read these simple golden rules for bug reporting. They are based on years of practical testing experience and solid theory.

    Function Testing Step by Step – Part 2

    Click Here to read Function Testing Step by Step – Part 1

    Component and component integration testing
    - For now, let’s not go in to that. This is a chapter on functional testing. Component and component integration testing are a responsibility of the Development department.

    Functional Testing Step by Step – Part 1

    Are you an aspiring Test Lead or Test Manager? Are you ready for transition from test engineer to lead or Lear to a Manager? Here we explain how to set up good testing step by step. You will not find a lot of theory here, only a practical introduction on how to perform good functional testing. You can consider it as a Checklist or Guidelines set. These are the points to take care while planning the test project.

    V-model is the basis of structured testing

    You will find out this is a great model!

    Agile Testing Method Simplified

    Article for newbie who want to know what is agile, how agile works, how agile testing methodology is different from traditional  methodologies and what are the challenges in agile.

    Unscripted Testing Techniques/Approaches

    Error Guessing
    Why can one Tester find more errors than another Tester in the same piece of software?

    More often than not this is down to a technique called ‘Error Guessing’. To be successful at Error Guessing, a certain level of knowledge and experience is required. A Tester can then make an educated guess at where potential problems may arise. This could be based on the Testers experience with a previous iteration of the software, or just a level of knowledge in that area of technology. This test case design technique can be very effective at pin-pointing potential problem areas in software. It is often be used by creating a list of potential problem areas/scenarios, then producing a set of test cases from it. This approach can often find errors that would otherwise be missed by a more structured testing approach.

    SQL interview questions for Testers

    These SQL interview questions are very simple and mainly were used for interviewing software testers who is involved (or going to involve) in database SQL testing or grey box testing.

    Web Testing basic Concepts | Get/Post methods and HTTP Status Codes

    In this post, we will go thru the basics of GET/POST methods and HTTP Status codes

    Testing with Visual Studio Team System 2010 (VS 2010) - Part 2

    VSTS (Visual Studio Team System) supports five key types of tests:
    1. Unit testing in which you call a class and verify that it is behaving as expected;
    2. Manual testing;
    3. Generic testing that uses an existing test application that run as part of the biggest test;
    4. Web testing to ensure the html apps function correctly
    5. Load testing to ensure the app is scalable.

    VSTS (Visual Studio Team System) improves the workflow by allowing the developers and testers to store their tests and results in one place. This allows a project manager to run a report to see how many tests have passed or failed and determine where the problems are, because the information is all in one data warehouse.

    With VSTS (Visual Studio Team System), testing capabilities have been integrated right into the VS environment, simplifying the process of writing tests without flipping back and forth between applications. VSTS supports testing as a part of an automated build system.

    VSTS also allows a developer to aggregate multiple tests, which have already been written, so that they can be executed by automated test agents to simulate up to a thousand users for load testing. Several agents can be run concurrently to increase the load in multiples of about a thousand. This whole process allows a team to reuse the work that was initiated for the various kinds of tests.

    This also makes it easier for the developers themselves to execute a load test based on the unit tests of the individual code modules, so that they can identify problems at an earlier stage, saving time, and learning how to write better code.

    VSTS automated test code generation capabilities can save a developer two to three minutes of work per method.

    Another key advantage is the Test List feature for managing tests in hierarchical categories that can be shared across projects. There are two grouping mechanisms for the tests, using projects and folders, using Test Lists. Test Lists makes it easier to manage the tests in batches. If you have twenty tests in one project and twenty in another, you can include them by clicking on one group of text boxes and reorganize your groups very easily.

    VSTS and TDD
    In TDD the test always comes first, while in unit testing this is not always the case. The basic idea of TDD is: Test a little, code a little, refactor a little - in that sequence! The rhythm for the entire sequence is seconds or minutes. With TDD the test always comes first, while with "unit testing" in the broadest sense this is not clear. Generating tests after-the-fact is not considered to be TDD.

    On the other hand, unit testing after the code is developed is not necessarily bad, it just does not serve the goals of TDD. Some testing is always better than no testing. However, software that is implemented using a test-driven approach, if done properly, will result in simpler systems, which are easier to understand, easier to maintain and with a near-zero-defect quality.

    VSTS plug-ins
    Compuware DevPartner and TestPartner, provide interactive feedback, coding advice and corporate coding standards and enable developers to find and repair software problems. This software now plugs into Studio Team System (VSTS) to make detailed diagnostic data available to the developer.
    Among other third-parties supporting VSTS list AutomatedQA with TestComplete and Borland with CaliberRM.

    Testing with Visual Studio Team System - Static Code Analyzer | Code Profiler | Unit Testing

    VSTS supports four types of tests, namely unit, manual, web, and load testing, which are organized using the Test Manager.

    The team can code and store the tests in projects within the solution, like the normal source code projects. These test projects are designed to provide a container to hold all tests. This interpretation offers tests the same functionalities as the source project receive of VSTS. For example, the tests are placed in the source code control, can be linked to work items, and the test results are saved on the foundation server for other team members to review.

    Testing with Visual Studio Team System - Manual Testing and Web Testing

    The oldest way to verify the correctness of the implemented code is the manual test. A manual test is a list of test activities with descriptions that a tester performs step by step.
    A project team uses manual tests, as portrayed in figure below, when the test steps are complicated or unfit to be automated. An example of a test situation where a team may decide to use a manual test is when they want to determine a component's behavior when network connectivity is lost.

    Load Testing with Visual Studio Team System 2010

    The idea behind the load test is simulating that multiple users execute the logic of the solution simultaneously. The primary goal of the load test is to discover scalability and performance issues in the solution. Testing the solution also gives benchmark statistics on performance as the solution modified or extended.

    Metric Based Approach for Requirements Gathering and Testing


    1. Introduction
    Requirements development and management have always been critical in the implementation of software systems. It is a known fact that engineers cannot build what analysts cannot define. It thus becomes imperative to have an efficient requirements gathering and management to deliver the best possible software systems.

    Requirements Reliability Metrics

    Go to Part 1 - Metric Based Approach for Requirements Gathering and Testing 

    Requirements Reliability Metrics:
    The business requirements are the foundation upon which the entire system is built and this specifies the functionality that must be developed in the final delivered software. And that requirement verification and validation is needed to assure that the functionality representing the requirements has indeed been delivered. However, often the requirements are not satisfied, leading to a process of fixing what you can and accepting the fact that certain functionality will not be there. The better approach is to get the requirements right the first time, complete, concise and clear, that will provide the developer a clear picture to build the system with out any misunderstanding between the Business Analyst, Developer, Quality Assurance team and the client.
    The requirement reliability metric is based on the requirement specification and keeps track of the requirements-in scope of the project.

    Testing Reliability Matrix

    Testing Reliability Matrix:
    • Software testing provides visibility into product and process quality in terms of current performance measurement and to use as historical data for future estimations and quality assurance.

    Checklist for Data Warehouse Testing

    1. Validate schemas of both source and targets of data warehouse

    2. Ensure key constraints for targets are in sync with specifications given to you
    3. query on source and targets and try to break transformation logic written in informatica. This is key and important since data sits in target based on transformation logic written and also check for Mapplets if any.

    White box testing Simplified

    In this topic we will cover the various white box testing techniques:
    - Statement- Coverage
    - Branch- or- Decision- Coverage
    - Multiple- Condition- Coverage
    - Loop- Coverage
    - Call- Coverage
    - Path- Coverage

    Unit test framework – An Introduction

    Unit test frameworks are software tools to support writing and running unit tests, including:
    • a foundation on which to build tests
    • the functionality to execute the tests
    • the functionality to report their results.

    Guide to Metrics Collection in Software Testing

    Read Part 1: Guide to Effective Test Reporting.

    Guide to Metrics Collection in Software Testing:

    Metrics are defined as ‘standards of measurement’ used to indicate a method of gauging the effectiveness and efficiency of a particular activity within a project.
    Base metrics constitute the raw data gathered by a Test Analyst throughout the testing effort. These metrics are used to provide project status reports to the Test Lead and Project Manager, Senior Management and Client Every project should track the following Test Metrics:

    Art of Test case writing

    Objective and Importance of a Test Case
    - The basic objective of writing test cases is to ensure complete test coverage of the application.

    Why start testing Early?

    Introduction :
    You probably heard and read in blogs “Testing should start early in the life cycle of development". In this chapter, we will discuss Why start testing Early? very practically.

    Golden Rules for Software Testing

    OK Folks, the original article is written by Ray Claridge here - ( In this article we are adding few more tips.

    Read these simple golden rules for software testing. They are based on years of practical testing
    experience and solid theory.

    Disclaimer / Contact Us

    This is my personal blog for my software testing study purposes. The topics posted in this blog are mine and from some other sources (credits are given). I always add those topics which helps me.

    Hope these topics will help you guys also. Please contact at for any issues, concerns related to articles.

    - Happy testing

    Neither nor the respective Organizations are responsible for any inadvertent error that may have crept in the Information being published on the Net. The Information published on the net are for immediate information to the user and information received from respective Organization should only be treated as authentic in this regard.

    The information provided in these pages of or in any other pages on this network are indicative and we are in no way responsible, either directly or indirectly. The information in these pages do no carry any legal warranty or validity. Any part of data on these pages can be modified unconditionally at any time. Use of this information is under your own risks.

    We always make sure that the information provided here is correct and accurate at all times. But, as the old saying says “To Err is Human”, we may fall in errors by making typos or providing you with incorrect or unclear information., its people, employees, Affiliates or Advertisers and/or people involved in the design of these pages our are in no way responsible for any errors, omissions or representations on any of our pages or on any links on any of our pages. We do not endorse in anyway any advertisers on our web pages. Please verify the validity of information on your own before undertaking any reliance.

    We would like you – being one of our esteemed Guest, to help us in making these pages more Informative, Educative and Accurate.

    Please report any missing / broken links you may find in these pages to

    Some of the links, information or data (including Images, Graphics, Sounds, Animations, Logos or other any interactive Content) on these pages may be owned, maintained or designed by other companies or persons. In most cases we get confirmation from them to have their links on these pages. By in very few cases, we may not be able to reach them. Our aim is to make people from round the world to know, visit and learn using the Internet as the best Media. In case you have any sort of Objection or have found a serious error, please let us know of the same. We shall come back to you with a reply at the earliest.

    If you find a typo error or wish to make an update to these pages, you may send a E-Mail briefly giving description of the page and updated info. You may post an E-Mail to and we shall make our best to update them accordingly. Alternatively you may please fill out guest book from the link below.

    As a last word, let us inform you that we are in no way responsible for any Legal Warranties either directly / indirectly in any case.

    Click Here to Read Privacy Policy

    QTP Tutorials

    Click on the below Link:

    QTP Certification Sample Practice Papers:

    Software Testing Suite

    Are you an aspiring Test Lead or Test Manager? Are you ready for transition from test engineer to lead or Lear to a Manager? Here we explain how to set up good testing step by step.

    Chapter 1 - Golden Rules of Software Testing

    • Introduction
    • Its all about finding the bug as early as possible 
    • Make sure you have these 3 software testing levels
    • Don’t expect too much of automated testing 
    • Deal with resistance
    • Do regression testing every new release
    • Let real users test with real data
    • You‘ll be lost without change request management
    • Make good arrangements with development and business
    • Focus on the software testing process, not on the tools
    • 'Impact' and 'Chance' are the keys to decide on risk and priority
    Chapter 2 - Why Start Testing Early
    • Fact One
    • Fact Two
    • Conclusion: start testing early!
    • Want to know how to do this?
    Chapter 3 - V Model is the basis of Structured testing
    Chapter 4 - Functional Testing Step by Step
    • Introduction
    • Planning
    • Acceptance test preparation
    • System test preparation
    • Component and component integration testing
    • System and System Integration Test Execution
    • Acceptance test execution
    Chater 5 - Golden rules for Bug Reporting

    • Introduction
    • Make one change request for every bug
    • Give step by step description of the problem
    • Explain the problem in plain language
    • Be concrete
    • Give a clear explanation on the circumstances where the bug appeared
    • If a result is not as expected, indicate what is expected exactly
    • Explain why (in your opinion) the request is a "show stopper"
    • Last but not least: don't forget to use screen shots!
    Chapter 6 -  Test Reporting

    Software Testing Tutorials for Beginners

    This topic is especially for beginners. It bridges the gap between theoretical knowledge and real world implementation. This article helps you gain an insight to Software Testing - understand technical aspects and the processes followed in a real working environment.

    Who this tutorial is for ?

    • Fresh graduates who want to start a career in SQA & Testing
    • Software engineers who want to switch to SQA & Testing
    • Testers who are new to Software Testing field.
    • Testers who want to prepare for interviews.