What is the testing process followed in a company ideally?

Well. Lets see about testing and its process ideally followed in a company with the help of flow chart for better understanding.

Testing

Testing  is a process to verify whether the software or application is performing enough to fulfil its intended purpose.

Objective of testing is to find as many defects as possible to make sure that the software under test is defect free to ensure the quality and implementation of  all requirements.

Testing process

test process

System Study

  • Requirements  is the input for testing.

Write Test Plan

  • A document which derives all future activities of the project.
  • It contains – Scope and objectives of testing, entry and exit criteria, when to write test cases, execution of test cases,  testing methodology to be adopted, planning test environment, resource planning, risks and failures, schedule and estimation, test deliverables etc.

Write Test case

  • Test case design techniques are identified to convert all the test scenarios into test cases.
  • Test cases are written in the standard template for each feature.
  • Once these test cases are reviewed and approved then they are stored in a test case repository.

Traceability Matrix

  • A document which ensures that each and every requirement has a test case.
  • Traceability Matrix has got the mapping between requirements and test cases.
  • It is also known as RTM(Requirement Traceability Matrix) or CRM(Cross Reference Matrix).

Defect Tracking

  • Any bug found by the testing team is logged and assigned to the development team.
  • This bug has to be retested by the testing team once it has been fixed by the developer.

Test Execution Report

  •  Test Execution Report(TER) contains a list of bugs, summary of test pass, fail etc.
  •  It is prepared after every test cycle and sent to development team, testing team, management and customer depending on the project.
  •  The last TER of the last test cycle is always sent to the customer. And this means that the project is over-according to the customer.
  •  This report is also called as Test Summary Report.

Project Closure Meeting

  • Project Closure Meeting  is an indication to the project team that the project is officially over.
  • Risk Management Plan will be reviewed and documented about how the project did in mitigating risks.
  • List of mistakes and achievements are discussed and documented to implement the good practices and correct the mistakes in future projects.

 

Advertisements

Stakeholders involved in the different phases of SDLC and their role

Stakeholder can be an individual, organisation, team or group who have interest and influence in the completion of the project.

Their roles are mapped to corresponding tasks to meet their responsibilities over the different phases of software development process.

Software to be developed will undergo in different phases of SDLC ,

Stage 1: Planning and requirement analysis

Stage 2: Defining Requirements

Stage 3: Designing the Product Architecture

Stage 4: Building or Developing the Product

Stage 5: Testing the Product

Stage 6: Deployment in the Market

THE DIFFERENT STAKEHOLDERS INVOLVED IN DIFFERENT PHASES OF SDLC

SDLC

STAKEHOLDERS AND THEIR ROLE

STAKEHOLDER

               ROLE

Client
  • Defining requirements
  • Reviewing solutions
  • User acceptance testing

Business Analyst / Product Analyst

  • Gathering requirements
  • Preparing Function Requirement Document and Business Requirement Document
  • Supporting implementation
Architect
  • Designing architecture of the product

Project managers

  • Plan, manage, and document project execution
  • Ensures work completion is on time and on budget
Developers
  • Product is built by developing the code
  • Providing technical document for deployment

Testers

  • Perform tests for the product
System Admin
  • Deployment

Business Document Vs Functional Document

Business Document

In Business document client explains requirement of the software he demands in simple terms and how their business works.

Business Analysts plays a vital role in collecting information about the initially stated requirements through various requirement gathering techniques.

These requirements specify what the system must do to fulfill the needs of the business.

Business document is also called as BRD (Business Requirement Document) depending on the project nature and process followed by the organisation.

Functional Document

Functional Document / Functional Specification Document (FSD) is derived from the BRD.

FSD is the primary document which contains detailed requirement specification of how the software should be developed comprising the set of use cases or user stories for functional requirement. Non functional requirements and interface of the system are also documented for the intended purpose of the software.

Focus of FSD is to act as a bridge between what the business users wanted the software to do and what IT should prepare to build to fulfil their needs.

Functional document also contains more detailed explanation of how each and every component should work and its workflow. Purpose of the Functional Document is to convert requirements into functionality and features demanded by the software.

It is also called as SRS (Software Requirement Specification) depending on the project nature and process followed by the organisation.

What is Use case and Test case?

Use Case

Use case is a pictorial representation of requirements. It explains how the end user interacts with the application. It gives all possible ways of how the end user uses the application.

Usecase

Usecase1figure 1.1

The above figure 1.1 is a sample use case of one of the requirements in the CRS.

In the MODULE A of the application, there are 6 features.

  • Admin has got access to 6 features
  • A paid user has got access to 3 features
  • A free user has no access to any of the features

Each use case must specify any preconditions that need to be met for the use case to work. Use cases must also specify postconditions that are observable results.

For paid user:

Precondition  – paid user must be created

Action  – login as paid user

Postcondition – 3 features must be there

For free user:

Precondition  – free user must be created

Action  – login as free user

Post condition – no features

Test Case

A Test Case is a set of actions executed to verify a particular feature or functionality of the software application. Test cases are used to validate whether the requirements have been met.

Test Condition can be a piece of functionality or anything you want to verify. In simple terms the goal of a test cases.

Example: Consider paid user of the above figure 1.1

Test Condition– Validate login functionality for the paid user.

Test Case comprises of steps to be followed to validate Login.

Step 1: Click on Login as paid user

Step 2: Input login credentials

Step 3: Click Enter

Step 4: Land in homepage

Customer gives the Customer Requirement Specification(CRS) for the application to be developed. The development team write the use case for the CRS and the use case is sent to the customer for review. If the customer approves it, then the approved use case is sent to the development team for design and coding. The approved use case is also sent to the testing team who start writing test plan and later on start writing test cases for the features of the application.