Manual Testing Process Quick Reading

Manual Testing Process Quick Reading

Software Quality:

Convene customer requirements in terms of Functionality

Convene customer expectations in terms of Performance, Usability, Security, Etc…

Non-Technical Factors:

Reasonable cost to purchase.

Time to release.

 All Types of Manual Testing

Software Quality Assurance (SQA):

The Monitoring and Measuring the strength of development process is called Software Quality Testing. 

Ex: Life Cycle Testing.

 Software Quality Control (SQC):

The validation of final product before releasing to the customer is called as SQC.

 Software Development Process:

In the above Software Development process, testing is being  conducted as a single phase by the development team. To improve quality in software development process, project management should focus on multiple stages of development with multiple stages of testing.

Fish model software development: Upper angle is life cycle development and lower angle is life cycle testing.

Information gathering defines what and Analysis defines how.

BRS: Business requirement specification explains the requirement the customer to be implemented as software. This document is also known as Customer Requirement Specification (CRS) or User Requirement Specification (URS).

SRS: Software requirement specification defines functional requirements to be developed and system requirement to be used (Hardware and Software).

Example: BRS defines addition (Customer requirement). 

SRS defines how to solve customer requirement.

Review: It is a static testing technique. 

In this review responsible people will estimate completeness and correctness of corresponding documents.

HLD: High Level Design document explains the complete architecture of the system from core functionalities to leaf functionalities.

This HLD is also known as Architectural Design or External Design.

LLD: Low Level Design document defines the internal logic of corresponding module (or) functionality.

The LLD is also known as Internal Logic Design document.

Prototype: An example model of an application without functionality is called prototype.

Program: A set of execute statements is called a Program.

Module: A set of programs is called as a Module or Unit.

Build: The set of modules is called as Software Build or Product.

White Box Testing: It is a coding level testing technique to test the completeness and correctness of program structure. 

Programmers will follow this technique. 

It is also known as Glass Box Testing (or) Clear Box Testing (or) Open Box Testing.

Black Box Testing: It is a build level testing technique. In this testing test engineers will validate every feature depending on external interface.

Software Testing: The Verification and Validation of a software application is called software testing.

Verification: can we build the product right?

Validation: can we build the right product?

3 V-Models

V stands for Verification and Validation. This model defines mapping between development process and testing process.

Refinement form of V-Model

The real V-model is expensive to pursue for small and medium scale organizations. Due to this reason, small and medium scale organizations maintains separate testing team for System Testing phase.

Reviews during Analysis

In general the software development process begins with requirements gathering and analysis. In this phase business analyst category people will develop BRS and SRS. After development of the documents the same business analyst category people will conduct review meetings to estimate completeness and correctness of the documents. In this review meeting, the same business analyst category people will concentrate on below checklist. 

BRS and SRS.

1. Are the requirements correct?

2. Are the requirements complete?

3. Are they achievable (w.r.t Technology)?

4. Are they reasonable (w.r.t Time)?

5. Are they testable?

Reviews during Design

After completion of analysis and then reviews the design category people will develop HLD’s and LLD’s. The same design category people will conduct review meetings to estimate completeness and correctness of the design documents. In the review the same design category people will think on below checklist HLD è LLD.

1. Does the design understandable?

2. Are the correct requirements met?

3. Does the design complete?

4. Does the design follow able (w.r.t Coding)?

5. Do they handle errors?

Unit Testing

After completion of design and their reviews, programmers will focus on coding to build software physically. In this phase programmers will test every program through a set of white box testing techniques w.r.t LLD.

1. Basis paths testing.

2. Control structure testing.

3. Program technique testing (Time).

4. Mutation Testing

Basis Path Testing

In this phase programmers will verify the execution of program without any syntax and run time errors. In this phase programmers will execute a program more than one time to cover all areas of that program coding while running.

Control Structure Testing

In this phase programmers will focus on correctness of the program functionality. In this phase programmers will check statements in the program together with variables declaration, IF conditions, Loops, etc….

Program Technique Coverage

In this phase programmers will verify the execution time of program to get better speed in processing. If the execution time is not reasonable then the programmers will change the structure of the program without touching functionality.

Mutation Testing

After completion of a program testing, the matching programs will review the completeness and correctness of the program testing. Mutation means that a change in coding of the program, in this Mutation testing programmers will perform changes in different areas in the program and repeat previously completed tests. If all the tests are passed on the changed program, then the program will continue testing on some program. If any one of the tests is failed on the change in program, then the program will focus on further coding.

Note: in white box Testing techniques, the first three techniques will test program code and the mutation testing will assess the completeness and correctness of the test on the program.

Integration Testing

After completion of dependent programs development and unit testing, programmers will inter join the programs to build complete software build. In this stage programmers will verify integration of programs in four types of approaches.

1. Top down Approach.

2. Bottom up Approach.

3. Hybrid Approach.

4. System Approach.

Top down Approach

In this approach the programmers will inter connect key models to some of the modules in the place of remaining sub modules programmers will use temporary programs called Stubs.

Bottom up Approach

In this approach the programmers will inter connect sub modules without connection to the main module. Programmers will use a temporary program instead of main module called Driver.

Hybrid Approach

It is a combined approach of Top Down and Bottom Up approaches. This approach is also known as Sandwich approach.

System Approach

It is also known as Final Integration (or) Big Bang Approach. In this integration programmers will inter connect programs after completion of total development.

Note: In general the programmers will inter connect programs through any one of the above methods depending on circumstances.

System Testing

After completion of Integration Testing, and receiving the build from development team, the testing team will focus on system testing to conduct using Black Box Testing techniques.

System Testing is divided into 3 sub stages.

a. Usability Testing.

b. Functional Testing

c. Non-Functional Testing.

Usability Testing

After accepting software build from development team, the testing team will conduct usability testing. In this test the testing team will estimate “User Friendliness” of all screens in the software build. There are two sub tests.

User Interface Testing or UI Testing

In this test, the testing team will apply below 3 factors on every screen of the software build.

• Ease of use: To estimate understand ability of screen.

• Look and Feel: To estimate attractiveness of screen.

• Speed in Interface: To estimate length of navigation as short.

Manual Support Testing

Throughout this test the testing team will validate the correctness and completeness of help documents. These help documents are also known as User Manuals.

Case Study:

Functional Testing

It is a mandatory testing level in testing team responsibilities. At the time of this test, testing team will focus on “Meet customer Requirements” through below sub tests.

a. Requirement Testing.

b. Sanitation Testing.

Requirements Testing

It is also known as Functionality Testing. During this test the responsible testing team will apply different coverage techniques as discussed below on the functionalities of software build.

• GUI Coverage / Behavioural Coverage: Changes in properties of objects in screens while operating.

• Error Handling Coverage: To eliminate wrong operation on screens.

• Input Domain Coverage: Testing correct type and size of input values

• Manipulations Coverage: Returning correct output values.

• Back End Coverage: Valid effect of screens operations on back end data base tables.

• Functionalities Order Coverage: The arrangements of screens in the software build with respect to order of functionalities.

Sanitation Testing

During this test the testing team will concentrate on extra functionalities with respect to requirements of the customer. This testing is also known as garbage testing.

Non-Functional Testing

After completion of user interface and functional testing, the testing team will focus on Non-Functional Testing to validate quality characteristics of software build Like Security and Performance.

Recovery Testing

This testing is also known as Reliability Testing. During this test, the testing team will validate that whether the software build is changing from abnormal state to normal state.

Compatibility Testing

It is also known as Portability Testing. During this test, the testing team will validate that whether the software build is running on the customer expected platforms or not?

Configuration Testing

It is also known as hardware compatibility testing. During this test the testing team will validate that whether the software build is supporting different technology hardware devices or not?

Example: Different technology printers.

        Different topology networks, etc….

Inter Systems Testing

It is also known as End-to-End Testing. At the time of  this test the testing team will validate that whether the software build co-exists with other software applications to share common resources.

Example: Sharing data, sharing hardware devices, printers, speakers, sharing memory, etc.

Installation Testing

During this test, the testing team will set up customer site like configured environment. The testing team is exercise installation of software build in to that environment.

Load Testing

The execution of the software build under customer expected configuration and customer expected load to estimate speed of processing is called as load testing. Here, load means that the no of concurrent users working on the software. This is also known as scalability testing.

Stress Testing

The execution of the software build under customer expected configuration and various load levels from low to peak is called stress testing. In this testing, testing team will concentrate on load handling by the software build.

Storage Testing

Testing whether the system meets its specified storage objectives.Testing the data of different formats and in different devices. Verifying the efficiency of data storage in devices and proper retrieval of the data.

Data Volume Testing

Volume testing regards to testing a software application with a certain quantity of data. This amount can, in generic terms, be the database size or it could also be the size of an interface file that is the matter of volume testing. For example, if you want to volume test your application with a specific database size, you will expand your database to that size and then test the application’s performance on it.

Example: MS Access technology support 2GB of database as maximum.

Parallel Testing

It is also known as Comparative Testing. During this test, the testing team will compare the software build with other competitive software in market or with old version of same software build to estimate completeness. This is applicable only for software product but not on software applications.

User Acceptance Testing (UAT)

After completion of all probable Functional and Non-Functional tests, the project manager will focus on user acceptance testing to gather feedback from customer site people. There are two methods to perform UAT, such as a-Test and b-Test.

a-Test b-Test

1. Software applications.

2. At development site.

3. By real customers. 1. Software products.

2. In customer site like environment.

3. By customers site like people.

Collect Feedback

Testing during maintenance

After completion of user acceptance test and their modifications, project management focus on release team development with few developers, few testers and few hardware engineers. This release team is coming to customer’s site and conduct port testing.

During this port testing release team concentrate on below factors in customers site.

• Compact installation

• Overall functionality

• Input devices handling

• Output devices handling

• Secondary storage devices handling

• Co-existence with other software to share common resources

• Operating system error handling

After completion of port testing, release team provides training classes to customer site people.

During utilization of the software, customer site people are sending change request to our organization. There are two types of change request to be solved.