Software Testing Practices, Test Methodologies and Test Competency Services


Welcome to the world of Software Testing & Best Test Practices.

All you wanted to know about Software Testing, Test Practices, Test Methodologies and building the Test Competency Services !!


Showing posts with label SDLC Models. Show all posts
Showing posts with label SDLC Models. Show all posts

Monday, May 19, 2008

Refined V Model

Due to cost and time point of view, V-model is not applicable to small scale and medium scale companies. These types of organizations are maintaining a refinement form of V-model.

Development starts with information gathering. After the requirements gathering, BRS/CRS/URS will be prepared. This is done by the Business Analyst.

Requirements analysis: After all the requirements are analyzed, S/wRS is prepared. It consists of the functional (customer requirements) + System Requirements (h/w + S/w) requirements. It is prepared by the system analyst.

During the design phase, two types of designs are done. HLD & LLD.

High Level Design discusses an overall view of how something should work and the top level components that will comprise the proposed solution. It should have very little detail on implementation, i.e. no explicit class definitions, and in some cases not even details such as database type (relational or object) and programming language and platform. In the High-Level Design, the Technical Architect of the project will study the proposed applications functional and non-functional (qualitative) requirements and design overall solution architecture of the application which can handle those needs.

A low level design has nuts and bolts type detail in it which must come after high level design has been signed off by the users, as the high level design is much easier to change than the low level design.

During the coding phase, programs are developed by programmers.

Unit Testing: After the completion of design and their reviews, programmers are concentrating on coding. During this stage they conduct program level testing, with the help of the WBT techniques. This WBT is also known as glass box testing or clear box testing or structural testing.

WBT is based on the code. The senior programmers will conduct testing on programs. WBT is applied at the module level.

There are two types of WBT techniques, such as

1. Execution Testing

  1. Basis path coverage (correctness of every statement execution)
  2. Loops coverage (correctness of loops termination)
  3. Program technique coverage (Less no of Memory Cycles and CPU cycles during execution)

2. Operations Testing: Whether the software is running under the customer expected environment platforms (such as OS, compilers, browsers and etc…sys s/w.)

Integration Testing: After the completion of unit testing, development people concentrate on integration testing, when they complete dependent modules of unit testing. During this test, programmers are verifying integration of modules with respect to HLDD (which contains hierarchy of modules).

There are two types of approaches to conduct Integration Testing:

(i) Top-down Approach
(ii) Bottom-up approach


During the system and functional testing, the actual testers are involved and conduct tests based on S/wRS.

During the UAT, customer site people are also involved and they perform tests based on the BRS.

Reviews during Analysis:

After completion of information gathering and analysis, a review meeting is conducted to decide the following 5 factors.

(i) Are they complete?
(ii) Are they correct?
(iii) Are they achievable?
(iv) Are they reasonable? ( with respect to cost & time)
(v) Are they testable?

Reviews during Design:

After the completion of analysis of customer requirements and their reviews, technical support people (Tech Leads) concentrate on the logical design of the system. In this every stage, they will develop HLDD and LLDD.

After the completion of above like design documents, they (tech leads) concentrate on review of the documents for correctness and completeness. In this review, they can apply the below factors.

(i) Is the design good? (understandable or easy to refer)
(ii) Is the design complete? (all the customer requirements are satisfied or not)
(iii) Is the design correct? (the design flow is correct or not)
(iv) Is the design followable? (the design logic is correct or not)
(v) Does the design handle error handling? ( the design should be able to specify the positive and negative flow also)

V-Model



Port Testing: This is to test the installation process.

DRE (Defect Removal Efficiency):

DRE= a/(a+b)
a = Total no of defects found by testers during testing
b = Total no of defects found by customer during maintenance

Sunday, May 18, 2008

The Waterfall Model

The Waterfall model (non iterative model) is a sequential software development model in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. Progress flows from the top to the bottom, like a waterfall. Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them.

It is also called as Classic Life Cycle Model (or) Linear Sequential Model.


The advantage of waterfall model is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process. Other advantages include

  1. Testing is inherent to every phase of the waterfall model
  2. It is an enforced disciplined approach
  3. It is documentation driven, that is, documentation is produced at every stage

The disadvantage of waterfall model is that it does not allow for much reflection or revision (inflexible).

However, many projects rarely follow its sequential flow. This is due to the inherent problems associated with its rigid format. Namely:

  1. It only incorporates iteration indirectly, thus changes may cause considerable confusion as the project progresses.
  2. As the client usually only has a vague idea of exactly what is required from the software product, this model has the difficulty accommodating the natural uncertainty that exists at the beginning of the project.
  3. The customer only sees a working version of the product after it has been coded & this may result in disaster if any undetected problems are precipitated to this stage.