SOFTWARE QUALITY ASSURANCE (SQA)

SOFTWARE QUALITY ASSURANCE (SQA) is a set of activities for ensuring quality in software engineering processes (that ultimately result in the quality of software products).

SQA Activities

It includes the following activities:

  • Process definition and implementation
  • Auditing
  • Training

 

SQA Processes

Processes include:

  • Software Development Methodology
  • Project Management
  • Configuration Management
  • Requirements Development/Management
  • Estimation
  • Software Design
  • Testing
  • etc

Verification?

Definition: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.

Verification is a static practice of verifying documents, design, code and program. It includes all the activities associated with producing high-quality software: inspection, design analysis and specification analysis. It is a relatively objective process.

Verification will help to determine whether the software is of high quality, but it will not ensure that the system is useful. Verification is concerned with whether the system is well-engineered and error-free.

 

Methods of Verification: Static Testing

  • Walkthrough
  • Inspection
  • Review

 Validation?

Definition: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements.

Validation is the process of evaluating the final product to check whether the software meets the customer expectations and requirements. It is a dynamic mechanism of validating and testing the actual product.

Methods of Validation: Dynamic Testing

  • Testing
  • End Users

 

WHITE BOX TESTING (also known as Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is a software testing method in which the internal structure/design/implementation of the item being tested is known to the developer/tester. The tester chooses inputs to exercise paths through the code and determines the appropriate outputs. Programming know-how and the implementation knowledge is essential. White box testing is testing beyond the user interface and into the nitty-gritty of a system.

This method is named so because the software program, in the eyes of the tester, is like a white/transparent box; inside which one clearly sees.

 

Definition by ISTQB

  • White-box testing: Testing based on an analysis of the internal structure of the component or system.
  • White-box test design technique: Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system.

Example

A tester, usually a developer as well, studies the implementation code of a certain field on a webpage, determines all legal (valid and invalid) AND illegal inputs and verifies the outputs against the expected outcomes, which is also determined by studying the implementation code.

White Box Testing is like the work of a mechanic who examines the engine to see why the car is not moving.

White Box Testing method is applicable to the following levels of software testing:

  • Unit Testing: For testing paths within a unit.
  • Integration Testing: For testing paths between units.
  • System Testing: For testing paths between subsystems.

However, it is mainly applied to Unit Testing.

Advantages

  • Testing can be commenced at an earlier stage. One need not wait for the GUI to be available.
  • Testing is more thorough, with the possibility of covering most paths.

 

Disadvantages

  • Since tests can be very complex, highly skilled resources are required, with a thorough knowledge of programming and implementation.
  • Test script maintenance can be a burden if the implementation changes too frequently.
  • Since this method of testing is closely tied to the application being tested, tools to cater to every kind of implementation/platform may not be readily available.

 

BLACK BOX TESTING, also known as Behavioral Testing is a software testing method in which the internal structure/design/implementation of the item being tested is not known to the tester. These tests can be functional or non-functional, though usually functional.

This method is named so because the software program, in the eyes of the tester, is like a black box; inside which one cannot see. This method attempts to find errors in the following categories:

  • Incorrect or missing functions
  • Interface errors
  • Errors in data structures or external database access
  • Behavior or performance errors
  • Initialization and termination errors

Definition by ISTQB

  • Black box testing: Testing, either functional or non-functional, without reference to the internal structure of the component or system.
  • Black box test design technique: Procedure to derive and/or select test cases based on an analysis of the specification, either functional or non-functional, of a component or system without reference to its internal structure.

 

Example

A tester, without knowledge of the internal structures of a website, tests the web pages by using a browser; providing inputs (clicks, keystrokes) and verifying the outputs against the expected outcome.

 

Levels Applicable To

Black Box testing method is applicable to the following levels of software testing:

  • Integration Testing
  • System Testing
  • Acceptance Testing

 

The higher the level, and hence the bigger and more complex the box, the more black-box testing method comes into use.

Techniques

Following are some techniques that can be used for designing black box tests.

  • Equivalence PartitioningIt is a software test design technique that involves dividing input values into valid and invalid partitions and selecting representative values from each partition as test data.

E.g. Consider, a customer filling Form for Customer Details. In the Age field he is supposed to input Numbers, since age can’t be an Alphabet. So Acceptable input values are 0-9 and Non-acceptable values are A-Z and Special Characters.

VALID INVALID
0-9 A-Z, a-z, Special Characters

 

  • Boundary Value AnalysisIt is a software test design technique that involves the determination of boundaries for input values and selecting values that are at the boundaries and just inside/ outside of the boundaries as test data.

E.g. Consider a Customer filling form for Customer Details. In the Full Name field he is provided with a field having maximum 100 characters and is a mandatary field. So in this case, any input of length 1 to 100 is acceptable and any input less than 1 and more than 100 should be unacceptable. Hence, we come to the conclusion to that min =1 and max=100

Minimum Expected Test Result Maximum Expected Test Result
Min=1 PASS Max=100 PASS
Min-1=0 FAIL Max-1=99 PASS
Min+1=2 PASS Max+1=101 FAIL

 

E.g. Now, consider Mobile textbox. In this case mobile no is fixed length data of 10 digits in this case minimum and maximum will be 10.

Minimum Expected Test Result Maximum Expected Test Result
Min=10 PASS Max=10 PASS
Min-1=9 FAIL Max-1=9 FAIL
Min+1=11 FAIL Max+1=11 FAIL

 

  • Cause-Effect GraphingIt is a software test design technique that involves identifying the cases (input conditions) and effects (output conditions), producing a Cause-Effect Graph, and generating test cases accordingly. This is an old technique and has deprecated now-a-days.

Advantages

  • Tests are done from a user’s point of view and will help in exposing discrepancies in the specifications.
  • Tester need not know programming languages or how the software has been implemented.
  • Tests can be conducted by a body independent from the developers, allowing for an objective perspective and the avoidance of developer-bias.
  • Test cases can be designed as soon as the specifications are complete.

 

 

Disadvantages

  • Only a small number of possible inputs can be tested and many program paths will be left untested.
  • Without clear specifications, which is the situation in many projects, test cases will be difficult to design.
  • Tests can be redundant if the software designer/developer has already run a test case.
  • Ever wondered why a soothsayer closes the eyes when foretelling events? So is almost the case in Black Box Testing.

 

 

 

GRAY BOX TESTING is a software testing method which is a combination of Black Box Testing method and White Box Testing method. In Black Box Testing, the internal structure of the item being tested is unknown to the tester and in White Box Testing the internal structure is known. In Gray Box Testing, the internal structure is partially known. This involves having access to internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level.

Gray Box Testing is named so because the software program, in the eyes of the tester is like a gray/semi-transparent box; inside which one can partially see.

Example

An example of Gray Box Testing would be when the codes for two units/modules are studied (White Box Testing method) for designing test cases and actual tests are conducted using the exposed interfaces (Black Box Testing method).

 

Though Gray Box Testing method may be used in other levels of testing, it is primarily used in Integration Testing.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.