Software testing levels

Software testing is done under two levels as,

  1. Functional testing
  2. Non-functional testing

Functional testing

This is a black box testing type.  Functional testing is based on the specifications of the software that is to be tested. Here the application is tested by providing inputs. Then the results are examined and check whether the intended functionality is present. This method of testing is conducted on a complete integrated system to evaluate the system’s compliance with its specific requirements.

Under this unit testing, integration testing, system testing, regression testing, acceptance testing, alpha testing and beta testing/ pre-release testing can be done.

 Nonfunctional testing

For testing of the nonfunctional requirements like performance, usability, portability, security we can follow the nonfunctional testing.

Under this performance testing, usability testing, security testing, portability testing can be performed.

Next – Unit testing

Previous – Grey box testing

Grey Box Testing

With having a limited knowledge of the internal workings of an application, grey-box testing is the best technique to test the application. In software testing, the phrase the more you know, the better carries a lot of weight while testing an application.

Mastering the domain of a system always gives the tester an edge over someone with limited domain knowledge. Unlike black-box testing, in grey-box testing, the tester has access to design documents and the database. Having this knowledge, a tester can prepare better test data and test scenarios while making a test plan.

This method of testing is performed by end-users and also by testers and developers. When compared with other two methods, this is partly time-consuming and exhaustive. This method is not suited for algorithm testing and if known data domains and internal boundaries can be tested.

Following are some of the advantages of using this method

  • Offers combined benefits of black-box and white-box testing wherever possible.
  • Grey box testers don’t rely on the source code; instead they rely on interface definition and functional specifications.
  • Based on the limited information available, a grey-box tester can design excellent test scenarios especially around communication protocols and data type handling.
  • The test is done from the point of view of the user and not the designer.

However grey box testing has some disadvantages too.

  • Since the access to source code is not available, the ability to go over the code and test coverage is limited.
  • The tests can be redundant if the software designer has already run a test case.
  • Testing every possible input stream is unrealistic because it would take an unreasonable amount of time; therefore, many program paths will go untested.

Next – Software testing levels

Previous – White box testing

White box testing

White-box testing is the detailed investigation of internal logic and structure of the code. To perform white-box testing on an application, a tester needs to know the internal workings of the code. The tester has to look inside the source code and find out which unit/chunk of the code is behaving inappropriately.

Normally white box testing is performed by testers and developers. This method is he most exhaustive and time-consuming type of testing. This is suited for algorithm testing. Data domains and internal boundaries can be better tested using white box testing.

White-box testing is very advantageous.

  • As the tester know the source code, it becomes very easy to find out which type of data can help in testing the application effectively.
  • It helps in optimizing the code.
  • Extra lines of code can be removed which can bring in hidden defects.
  • Due to the tester’s knowledge about the code, maximum coverage is attained during test scenario writing.

However there are some disadvantages too.

  • Due to the fact that a skilled tester is needed to perform white-box testing, the costs are increased.
  • Sometimes it is impossible to look into every nook and corner to find out hidden errors that may create problems, as many paths will go untested.
  • It is difficult to maintain white-box testing, as it requires specialized tools like code analyzers and debugging tools


Next – Grey box testing

Previous – Black box testing

Black box testing

This method of testing is used when the tester does not have knowledge on the interior working of the application which is to be tested. Here the tester does not have access to the source code. When performing a black-box test, a tester will interact with the system’s user interface by providing inputs and examining outputs without knowing how and where the inputs are worked upon.

Black box testing is performed by end-users and also by testers and developers. It is exhaustive and the least time-consuming. However it is not suited for algorithm testing. This can only be done by trial-and-error method.

  • Black box testing is well suited and efficient for large code segments.
  • Since the code access is not required it is easy to be done
  • This method clearly separates user’s perspective from the developer’s perspective through visibly defined roles.
  • Moderately skilled testers can test the application with no knowledge of implementation, programming language, or operating systems and can be done by a large number of testers.


However there are some disadvantages when using this method of testing.

  • It covers a limited area by testing, since only a selected number of test scenarios is actually performed.
  • This method is inefficient testing, due to the fact that the tester only has limited knowledge about an application.
  • This method performs a blind coverage, since the tester cannot target specific code segments or error-prone areas.
  • The test cases are difficult to design.


Next –  White box testing

Previous – Software Testing Methods

Software Testing

To see whether the software product is aligned with the client’s requirements, the testing is done. Software tester, software developer, project manager as well as the end users can conduct the testing.

Software tests are formal SQA components that are targeted toward review of the actual running of the software. The tests are based on a prepared list of test cases that represent a variety of expected scenarios. Under testing it examines software modules, software integration or entire software packages (systems). Recurrent tests (“regression tests”) are carried out after correction of previous test findings, and continued till satisfactory results are obtained.

Testing is done at every phase of SDLC.

  • At the requirement gathering phase, the analysis and verification of requirements are considered as testing.
  • Reviewing the design in the design phase with the intent to improve the design is  considered as testing.
  • On completion of the code, testing performed by a developer is also categorized as testing.

However the time which the testing should be concluded cannot be exactly said. Yet the following are some instances where testing can be stopped.

  • Testing Deadlines
  • Management decision
  • Completion of test case execution
  • Completion of functional and code coverage to a certain point
  • Bug rate falls below a certain level and no high-priority bugs are identified

Next – Software Testing Methods

Previous – Reviews and expert opinions

Reviews and expert opinions


As defined by IEEE (1990), a review process is:

“A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.”

The design phase of the software development process produces various kinds of documents as, design reports, software test documents and software installation plans and manuals. These documents are reviewed during this review process. Reviews are very important in the SQA process as they provide early detection and prevention of the errors and prevent the passing of the errors towards the stages where the error detection and correction are more cumbersome, intricate and  as a result are very costly, which were occurred during the design and analysis stages.

Reviews can be categorized as formal design reviews – the DR report and peer reviews – inspections and walkthroughs.

Use the following link to access more details on review methods.

Expert opinions

Expert opinions support quality assessment efforts by introducing additional external capabilities into the organization’s in-house development process.  This method may be particularly useful in some situations. The organization’s internal quality assurance activities are thereby reinforced.


Next – Software Testing

Previous – Verification and validation


Verification and validation

In verification we check – “Are we building it right?” This takes place before the validation and check for the documentation and codes. Verification is done in order to verify the software product which is to be developed, which is being developed. This is done by the developers, to ensure that the software system meets all the functionality which is expected to be there. Static activities including collecting reviews, walkthroughs and inspections are performed under verification.

In validation we check – “Are we building the right thing?” This takes place after the verification and checks the overall product. Validation is done in order to validate the software. This is done by testers to ensure that the functionalities which are developed in the software meet the expected behavior. Dynamic activities are performed in this stage because it includes executing the software against the requirements.

Next – Reviews and expert opinions

Previous – Software project life cycle components

Software project life cycle components

The life cycle of a software development project is composed of two stages as,

  • The development life cycle stage
  • Operation – maintenance stage

In first stage the detection of design errors and programming errors is done.

During the second stage , include specialized maintenance components , as well as development life cycle components (pre-maintenance, life cycle, infrastructure, managerial components) are checked.

The main components are,

  • Reviews,
  • Expert opinions
  • Software testing
  • Software maintenance
  • Assurance of the quality of the subcontractor’s work and the customer supplied parts.

Next – Verification and validation

Previous – SQA (Introduction)

Software Quality Assurance (SQA)

What is software quality assurance? The below is the expanded definition for SQA.

“A systematic, planned set of actions necessary to provide adequate confidence that the software development process or the maintenance process of a software system product conforms to established functional technical requirements as well as with the managerial requirements of keeping the schedule and operating within the budgetary confines.”

Simply in SQA we ensure that high quality software is produced. Here we see whether our software product is in accord with the standards and criteria given and whether our product satisfies the client’s requirements while minimizing the cost of guaranteeing quality.

It is done by a variety of activities performed throughout the development and manufacturing stages. The performed activities prevent the causes of errors, detect error and correct them early in the development process.

Next – Software project life cycle components