Showing posts from August, 2011

Static Testing

Static testing is a form of testing that does not involve execution of the application to be tested. Static testing involves going through the application’s code to check mainly for – conformance to functional requirements, conformance to design, missed functionality and coding errors.  Static testing is generally effective in finding errors in logic and coding.

Static testing may be performed by humans as well as software tools. Here, we look at static testing performed by humans. There are three main types of static testing that are performed. Desk checking Code walkthrough Code inspection While desk-checking is performed by the author of the code who reviews his/her portion of code, the other two techniques of walkthrough and inspection involve a group of people apart from the author of the code performing the review.

Normally, static testing is performed in the time frame between when the application is coded and dynamic testing begins. Static tests may be performed even earlier a…

State Transition Testing

State transition testing is used where some aspect of the system can be described in what is called a “finite state machine”. This simply means that the system can be in a (finite) number of different states, and the transitions from one state to another are determined by the rules of the “machine”. This is the model on which the system and the tests are based. Any system where you get a different output for the same input, depending on what has happened before, is a finite state system.

For example :

If you request to withdraw £100 from a bank ATM, you may be given cash. Later you may make exactly the same request but be refused the money (because your balance is insufficient). This later refusal is because the state of your bank account had changed from having sufficient funds to cover the withdrawal to having insufficient funds. The transaction that caused your account to change its state was probably the earlier withdrawal. Another example is a word processor. If a document is open…

White Box Testing

White box testing is very different in nature from black box testing. In black box testing, focus of all the activities is only on the functionality of system and not on what is happening inside the system.
Purpose of white box testing is to make sure that
Functionality is properInformation on the code coverageWhite box is primarily development teams job, but now test engineers have also started helping development team in this effort by contributing in writing unit test cases, generating data for unit test cases etc.
White box testing can be performed at various level starting from unit to system testing. Only distinction between black box and white box is the system knowledge, in white box testing you execute or select your test cases based on the code/architectural knowledge of system under test.
Even if you are executing integration or system test, but using data in such a way that one particular code path is exercised, it should fall under white box testing.
There are different ty…

Black Box Testing

What is Black Box Testing?
Black box testing is a software testing techniques in which
functionality of the software under test (SUT) is tested without looking
at the internal code structure
, implementation details and knowledge of
internal paths of the software.This type of testing is based entirely on
the software requirements and specifications.

In Black Box Testing we just focus on inputs and output of the software system without bothering about internal knowledge of the software program.

The above Black Box can be any software system you want to test. For example : an operating system like Windows, a website like Google ,a database like Oracle or even your own custom application. Under Black Box Testing , you can test these applications by just focusing on the inputs and outputs without knowing their internal code implementation.

Black box testing - StepsHere are the generic steps followed to carry out any type of Black Box Testing.
Initially requirements and specifications of the sy…

Acceptance Testing


Acceptance Testing is a level of the software testing process where a system is tested for acceptability.
The purpose of this test is to evaluate the system’s compliance with the business requirements and assess whether it is acceptable for delivery.


During the process of manufacturing a ballpoint pen, the cap, the body, the tail and clip, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and Integration Testing is performed. When the complete pen is integrated, System Testing is performed. Once the System Testing is complete, Acceptance Testing is performed so as to confirm that the ballpoint pen is ready to be made available to the end-users.


Usually, Black Box Testing method is used in Acceptance Testing.
Testing does not usually follow a strict procedure and is not scripted but is rather ad-hoc.

Acceptance Test Plan PrepareReviewReworkBaselineAcceptance Test Cases/…

Integration Testing

Objective of Integration testing is to make sure that the interaction of two or more components produces results that satisfy functional requirement. In integration testing, test cases are developed with the express purpose of exercising the interface between the components. Integration testing can also be treated as testing assumption of fellow programmer. During the coding phase, lots of assumptions are made. Assumptions can be made for how you will receive data from different components and how you have to pass data to different components.

During Unit Testing, these assumptions are not tested. Purpose of unit testing is also to make sure that these assumptions are valid. There could be many reasons for integration to go wrong, it could be because

Interface Misuse A calling component calls another component and makes an error in its use of interface, probably by calling/passing parameters in the wrong sequence.

Interface Misunderstanding A calling component makes some assumption abo…

Waterfall Model

The simplest software development life cycle model is the waterfall model, which states that the phases are organized in a linear order. A project begins with feasibility analysis. On the successful demonstration of the feasibility analysis, the requirements analysis and project planning begins.

The design starts after the requirements analysis is done. And coding begins after the design is done. Once the programming is completed, the code is integrated and testing is done. On succeeful completion of testing, the system is installed. After this the regular operation and maintenance of the system takes place. The following figure demonstrates the steps involved in waterfall life cycle model.

The Waterfall Software Life Cycle Model
With the waterfall model, the activities performed in a software development project are requirements analysis, project planning, system design, detailed design, coding and unit testing, system integration and testing. Linear ordering of activities has some im…

Software Testing Life Cycle (STLC)

Software Testing Life Cycle:

Software testing life cycle or STLC refers to a comprehensive group of testing related actions specifying details of every action along with the specification of the best time to perform such actions. There can not be a standardized testing process across various organizations, however every organization involved in software development business, defines & follows some sort of testing life cycle.
STLC by & large comprises of following Six Sequential Phases:

1) Planning of Tests
2) Analysis of Tests
3) Designing of Tests
4) Creation & Verification of Tests
5) Execution of Testing Cycles
6) Performance Testing, Documentation
7) Actions after Implementation

Every company follows its own software testing life cycle to suit its own requirements, culture & available resources. The software testing life cycle can’t be viewed in isolation, rather it interacts with the every phase of Software Development Life Cycle (SDLC). Prime focus of the software test…

User Acceptance Testing

What is User Acceptance Testing?
User Acceptance Testing is often the final step before rolling out the application.

Usually the end users who will be using the applications test the application before ‘accepting’ the application.

This type of testing gives the end users the confidence that the application being delivered to them meets their requirements.

This testing also helps nail bugs related to usability of the application.

User Acceptance Testing – Prerequisites:

Before the User Acceptance testing can be done the application is fully developed.
Various levels of testing (Unit, Integration and System) are already completed before User Acceptance Testing is done. As various levels of testing have been completed most of the technical bugs have already been fixed before UAT.

User Acceptance Testing – What to Test?

To ensure an effective User Acceptance Testing Test cases are created.
These Test cases can be created using various use cases identified during the Requirements…

Regression Testing

Regression testing is the re-running of Test cases that a program has previously executed correctly, in order to detect failures spawned by changes or corrections made during software development and maintenance.

These failures arise from incomplete or incorrect changes and are often witnessed as (unexpected) side effects in apparently unrelated application areas. It is common in the IT industry, that one in six  of correction attempts are themselves defective. This high rate of introduced defects is exaggerated when developers maintain a large number of poorly documented, integrated systems where they of ten have little or no experience of these systems. Regression testing may then be used to great effect at detecting subtle side effects and unconsidered inter-relationships within these environments, thus reducing risk.

In regression testing standard actions in a test procedure are carried out and the expected responses are checked for correctness. Failure of the system to reproduce an…

Regression Testing and Retesting

Whenever testers test a software they find defects. These defects are then fixed by developers and the testers then retest the defects. This is called DEFECT RETESTING.

Because there are defects that have been fixed there is also a high probability that some other parts of the applications that were earlier working fine may now have problems. Why? Because the code that was modified (while fixing defects) could be calling or was being called by some other part of code. In order to make sure that these parts of application are working fine, testers do regression testing.

Regression testing means rerunning test cases from existing test suites to build confidence that software changes have no unintended side-effects. The “ideal” process would be to create an extensive test suite and run it after each and every change. Unfortunately, for many projects this is just impossible because test suites are too large, because changes come in too fast, because humans are in the testing loop, becau…

History of ISTQB Certification - Dorothy Graham

In the early 1990s, software testing was not a respected profession; in fact many thought of testing at best as a “necessary evil” (if they thought of testing at all!). There were few people who specialized in testing, and it was seen as a “second-class” activity. There was a general perception that testing was easy, that anyone could do it, and that you were rather strange if you liked it.

It was then that I decided to specialize in testing, seeing great scope for improvement in testing activities in industry, not only in imparting fundamental knowledge about testing (basic principles and techniques), but also in improving the view testers had of themselves, and the perceptions of testers in their companies. I developed training courses in testing, and began Grove Consultants, named after my house in Macclesfield. One of my most popular talks at the time was called “Test is a four-letter word”, reflecting the prevailing culture about testing. The UK’s Specialist Interest Group in So…

Design and Testing

Software Testing in relation to the Design Phase – The stages of software testing are derived from the way a software system is designed and built up. 
It is well depicted in the conventional V – model which maps the types of test to each stage of development. The types of software testing corresponding to the design phases are as stated below –
Component or Unit Testing – Detailed design
         Integration & Functional Testing – High level or System design
A representation is provided through the V-Model diagram:

Component / Unit Testing –
• It implies the first stage of testing & is done using the Unit test or Detail design document prepared during the component or detail design phase.
• It involves checking that each feature specified during the "Component Design" has been implemented in the component or the module.
• This is usually a white box testing which involves analysis of the written code so that errors are eliminated right at the first stage.
• Unit test case…