1.

Introduction

‘Requirement Gathering, Release, Testing and Documentation’ are important steps in

any product/software development process. Requirement gathering is the first step,

testing is the third step and documentation is a continuous process while product

development.

Requirement Gathering can be considered a fundamental part of product/software

development for the client [1]. Business Analyst is responsible for gathering requirement

and transform into a technical user story for the developer.

Requirement Gathering is all about “What user wants to do?” and “How is this

achieved?”. The goal of requirement engineering is to develop and maintain a

sophisticated and descriptive ‘System Requirements Specification’ document [1].

According to ANSI/IEEE 1059 standard Testing is – A process of analyzing a software item

to detect the differences between existing and required conditions (i.e., defects) and to

evaluate the features of the software item. Testing is conducted at the phase level in the

software development life cycle or at module level in program code. Software testing

comprises of Validation and Verification [2].

Any written text, illustrations or video that describe a software or program to its users is

called program or software document. Users can be anyone from a programmer, system

analyst and administrator to end user. At various stages of development multiple

documents may be created for different users. In fact, software documentation is a

critical process in the overall software development process [3].

1|Page
2. Requirement Gathering

For the completion of the development project, the requirement analysis is critical. The

needs must be measurable, measurable and testable and also linked to the expectations

of the user. The need to satisfy the user's requirement without any ambiguity makes the

project successful. An estimated 85% of defects in software development are found in

requirements gathering step. Some techniques are used to collect requirements. For each

project, not every technique is used. Some are useful in these techniques; others are not

but depend on the description of the project. Some techniques for requirement gathering

are [4]:

• Interviews

Interviews are a strong tool for collecting needs. Organization may carry out

several interview types.

• Surveys

Organization may conduct interviews with different stakeholders to find out what

they expect and what the future system will require.

• Questionnaires

All stakeholders are provided with a document with a set of objective questions

and options, which is collected and compiled. A weakness in this technique is that

the issue may be left unattended if an option to deal with a problem is not

mentioned in the questionnaire.

• Brainstorming

Different stakeholders have an informal discussion and all input for further needs

analysis is recorded

2|Page
 • Prototyping

Prototyping constructs user interface to interpret the features of the software

product without adding details for the user. It helps to better understand the

needs. If no software for the developer reference is installed at customer end, and

the customer does not understand his own requirements, developer produces a

prototype based on the requirements initially specified. The prototype is

presented to the customer and the comments are noted. The feedback from the

client is an input to demand collection.

2.1 Types of Requirements:

1. Functional Requirements:

This category includes requirements related to the functionality of the software. They

define functions and functionality within and from the software system.

For example:

1. User should be able to search for the record

2. User should not be able to modify payment information

3. Users should only have permission which is allocated to the user position

4. User should be able to send an email to customer from the system

2. Non-functional Requirements

This category includes requirements that are not related to the software's functional

side. They are implicit or anticipated software characteristics that are accepted by

users.

For example:

1. Performance

2. Speed

3|Page
 3. Disaster Recovery

4. Security

5. Cost

6. Flexibility etc.

2.2 Tools for Requirements Gathering

These are some important tools used for requirement gathering [5]:

1. Context diagram

A system context diagram defines the system’s boundary, its surrounding

environment, and all the interacting entities. The system is plotted in the

middle of the diagram and identifies customers, external or internal systems,

the organization’s end users and any vendors or suppliers providing third-party

services. By building a visual model of the software solution, you have a better

understanding of the major interactions and players in your system. It also

helps to define the context where the system sits so the end user can agree to

what is in scope and what is out of scope in the project.

Fig. Context Diagram Sample

4|Page
2. Functional decomposition

A functional decomposition diagram provides a top-down view of the business

process and/or the system’s major functions. When I think about what the system

should do, I’ll use the functional decomposition diagram to break it down into major

chunks. This view also helps validate all the functions the system should provide. It’s

similar to an organization chart and your end-user should be able to easily relate to

this model.

Fig. Functional Decomposition Diagram [6].

3. Use case diagram

A use case diagram is designed to capture a system's dynamic aspect. But this

description is too general to explain the purpose, as there is a similar purpose in

four other diagrams (activity, sequence, collaboration and State Chart). We will

discuss some particular reason, which differentiates it from four other diagrams.

Use case diagrams are used to obtain system specifications, including internal and

external variables. Some of these specifications are specification requirements.

There are also use cases prepared and actors recognised if a system are examined

to collect its functionalities.

5|Page
 Fig. Use Case Diagram

4. Activity Diagram

Activity diagram is another important diagram in UML to describe the dynamic

aspects of the system.

Activity diagram is basically a flowchart to represent the flow from one activity to

another activity. The activity can be described as an operation of the system.

The control flow is drawn from one operation to another. This flow can be

sequential, branched, or concurrent. Activity diagrams deal with all type of flow

control by using different elements such as fork, join, etc

The purpose of an activity diagram can be described as −

• Draw the activity flow of a system.

• Describe the sequence from one activity to another.

• Describe the parallel, branched and concurrent flow of the system.

6|Page
5. Sequence diagram

It is obvious from the term Interaction that the diagram is used to represent some

kind of interaction between the various elements in the model. The interaction is

an integral part of the system's dynamics.

Two graphs known as the sequence diagram and collaboration diagram represent

this interactive behaviour in UML. Both diagrams have a common fundamental

meaning.

The sequence diagram focuses on the time sequence of the messages and on the

structural organisation of the objects transmitting and receiving messages.

Purpose of Interaction Diagrams:

Interaction diagrams are meant to show the system's interactive behaviour. It is

a challenging job to imagine the interaction. The approach therefore consists of

using different models to capture the various aspects of the interaction.

Sequences and diagrams of collaboration are used to capture the complex

essence from a particular viewpoint.

The purpose of interaction diagram is −

• To capture the dynamic behaviour of a system.

• To describe the message flow in the system.

• To describe the structural organization of the objects.

• To describe the interaction among objects.

7|Page
 Fig. Sequence Diagram

6. User stories

User stories are short, simple descriptions of a feature told from the perspective of

the person who desires the new capability, usually a user or customer of the system.

They typically follow a simple template:

As a < type of user >, I want < some goal > so that < some reason >

8|Page
3. Release

3.1 What is Release ?

The final version of an application is distributed via a release. A public or private version of

the software may generate a new or upgraded application in general. The alpha version and

then beta versions of the software are preceded by the release.

3.2 Release Steps[7]:

1. Plan release

The most intense planning phase can be, as your whole release is structured from

beginning to end. A robust release plan will help your team keep track of standards

and requirements.

A release plan is available in a number of ways. The software development life cycle

is among the most popular release management methods (SDLC).

The SDLC supports software developers in designing, developing, maintaining and

replacing high efficiency and quality software systems. The SDLC may be used

together or in spite of other processes for project management.

2. Build Release

You can begin to design and build the product for release by completing the release

plan. This is the actual product development based on requirements described in the

release plan. Once all the issues are dealt with, it is time that the building is tested for

real-world scenarios.

This might take a few iterations. When the team builds the product, it is sent to a

testing environment for user acceptance (usually automatically). This enables the

team to identify bugs or problems in a real world environment. When problems are

9|Page
 identified, the build is returned to the second stage for development. In other words,

the work can run from stage two to stage three and back until release is approved in

the iterative release management process.

3. User Acceptance Testing

User acceptance tests, also called UAT, are carried out when the end users have built

the product to use it and provide feedback. Often this is done online as a free beta

test or shared with a larger group of employees.

User acceptance testing is the most important step for release management, given

the amount of information and fixes that have been collected to get the system to

where it needs to be launched. This is part of an iterative process, as noted previously.

The team goes back to the desk to fix problems and redesign the build to improve

integrity when bugs are identified. The build needs to pass the UAT phase for final

execution and release.

4. Prepare Release

This step is to place the finishing touches on the product taking all that was learned in

UAT into account. The final quality review by the QA team also covers the release

preparation.

In order to ensure that the build meets the minimum acceptable standards and

business requirements described in the release plan, QA's team will conduct final

inspections. The functional team validates the results and concludes the release for

implementation, once the evaluation is completed. It must be approved by the

product owner before the build can be implemented in a live environment.

10 | P a g e
 5. Deploy Release

The time has come to put the product in the real world.

The deployment stage includes messaging and product training to the end user and

the entire company as well as the simple transmission of build into production.

Users should for instance be notified about the release changes and how the new

features are to be operated. You may need to provide robust and ongoing training to

keep everyone up to speed, depending on how significant these changes are. This is

particularly important when internal releases are carried out in order to be efficient

and productive for employees using the software.

3.3 Release Notes

Release notes are a document released as part of the final build which includes new

improvements to this release and the known problems.

Release notes are usually written by technicians who communicate with customers.

Release notes also feed the user documentation, user guide and training materials

process.

11 | P a g e
4. Testing

4.1 Testing Plan:

A software test plan can be defined to describe the scope, aim, approach and focus of a

software testing effort.

Test plan components include test plan id, testing features, test methods, test assignments,

pass or fail criteria features, test outcomes, roles, timetable, etc.

The test plan is conducted by a test manager or a conductor who explains how to test, when

to test, how to test and when to test.

4.2 Testing method:

of the software.

• That is, black-box testing techniques enable you to derive sets of input conditions

that will fully exercise all functional requirements for a program

• Black-box testing is not an alternative to white-box techniques. Rather, it is a

complementary approach that is likely to uncover a different class of errors than

white box methods.

• Black-box testing attempts to find errors in the following categories:

1 Incorrect or missing functions

2 Interface errors

3 Errors in data structures or external database access

4 Behavior or performance errors

12 | P a g e
 5 Initialization and termination errors

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

̶ It is mainly applied to System testing and Acceptance 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.

• 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.

13 | P a g e
 Fig. Black box testing & white box testing

4.2.2 White Box Testing:

• White-box testing, sometimes called glass-box testing, is a test-case design

philosophy that uses the control structure described as part of component-level

design to derive test cases.

• Using white-box testing methods, you can derive test cases that

1 Guarantee that all independent paths within a module have been exercised at least

once.

2 Exercise all logical decisions on their true and false sides.

3 Execute all loops at their boundaries and within their operational bounds.

4 Exercise internal data structures to ensure their validity.

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

̶ It is mainly applied to Unit testing and Integration testing

14 | P a g e
 ̶ Unit Testing: For testing paths within a unit.

̶ Integration Testing: For testing paths between units.

̶ System Testing: For testing paths between subsystems.

White-box testing is a testing technique which checks the internal functioning of the system.

In this method, testing is based on coverage of code statements, branches, paths or

conditions. White-Box testing is considered as low-level testing. It is also called glass box,

transparent box, clear box or code base testing. The white-box Testing method assumes that

the path of the logic in a unit or program is known.

• 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.

15 | P a g e
4.3 Testing Strategy :

Fig: Testing strategy

• Test Technique is a set of instructions outlining the test design and how it should

be evaluated.

• Test strategy components include: aims and scope of implementation,

documentation types, test procedures, team reporting structure, customer

engagement strategy, etc.

• The project manager introduces a test plan. It determines which technique and

which module to test.

• The evaluation strategy explains the methods in general. You may summarise and

evaluate knowledge that is not for project-specific.

• Test approach can also be used as a part of a test plan in smaller projects. It can

be seen in many projects at the organizational level

16 | P a g e
4.4 Testing Strategies [6]:

4.4.1 System Testing:

Fig. Types of System Testing

System testing (ST) is a technique of the black box testing used to measure compliance of

the system with specified requirements throughout the system. With system testing, the

system functionality is thoroughly tested. In order to measure the quality of the system

unevenly, System Testing is usually done by a team that is independent from its

development team. The tests are functional as well as non-functional.

4.4.2 Validation Testing:

Process of software evaluation during or at the end of the development process to

determine if the software meets specific business needs. Validation Tests ensure that the

17 | P a g e
product meets the needs of the customer. It can also be defined to show that when

deployed in a suitable environment, the product meets its intended use.

Fig. Validation Testing - Workflow

4.4.3 Integration Testing:

Integration testing addresses the issues associated with the dual problems of verification

and program construction. Integration is defined as a set of integration among

component. Testing the interactions between the module and interactions with other

system externally is called Integration Testing. Testing of integrated modules to verify

combined functionality after integration.

18 | P a g e
 Integration Strategies:

• Big-Bang Integration

• Top Down Integration

• Bottom Up Integration

• Hybrid Integration

4.4.4 Unit Testing:

Unit is the smallest part of a software system which is testable it may include code files,

classes and methods which can be tested individual for correctness. Unit is a process of

validating such small building block of a complex system, much before testing an

integrated large module or the system as a whole.

Unit Testing - Advantages:

• Reduces errors or eliminates bugs when modified by current features in the newly

created features.

• The cost of testing decreases because errors are detected very early on.

• Improves architecture and improves code refactoring.

• Unit Tests give quality of build when integrated with the build.

19 | P a g e
Unit Testing Lifecycle:

Fig. Unit Testing Lifecycle

4.4.5 Smoke Testing

Smoke Testing is a hardware-based testing method which controls the smoke of hardware

components once the power of the hardware is switched on. Smoke testing refers similarly to

testing the basic functionality of the build in the context of software testing. When the test

fails, product is declared unstable and is NOT tested until the it passes smoke test.

20 | P a g e
4.5 Test Cases

A test case is a document, which has a set of test data, preconditions, expected results and

post conditions, developed for a particular test scenario in order to verify compliance against

a specific requirement.

Test Case acts as the starting point for the test execution, and after applying a set of input

values, the application has a definitive outcome and leaves the system at some end point or

also known as execution post condition.

Typical Test Case Parameters:

• Test Case ID

• Test Scenario

• Test Case Description

• Test Steps

• Prerequisite

• Test Data

• Expected Result

• Test Parameters

• Actual Result

• Environment Information

• Comments

21 | P a g e
 Example of Test Cases:

Scenario Test Step Expected Result

Appointment Book appointment and check Appointment status should be

Users must verify their New user registration ‘user_active’ status should
email id by clicking on receives email of verification change from ‘0’ to ‘1’.
verification link sent on link.
registered email id.

Expired stock of pharmacy Inserted new expired stock in Application should show this
automatically shows in inventory system. product in Expired Stock page
Expired Product page and and pharmacist can remove
pharmacist can click on stock.
remove stock to remove
stock.

Once saving blood group Saved blood group of Test Application should make blood
by patient, he/she cannot Patient. group as read-only.
change it without any
proof to admin.

Table: Test Cases

22 | P a g e
5. Testing Documentation
Documentation for testing is the documentation of artefacts created during or before

software testing. Documentation reflects the importance of individual and business

processes. Projects containing all documents are mature at a high level. Careful

documentation can save the organisation time, effort and wealth.

Every test engineer prepares the needed reference document before the test execution

process is started. In general, when the developer is busy writing the code, testers write

the test document.

5.1 Test Document Structure [8]:

Test Scenarios

The test scenario is a detailed document of test cases that cover end to end functionality

of a software application in liner statements. The liner statement is considered as a

scenario. The test scenario is a high-level classification of testable requirements. These

requirements are grouped on the basis of the functionality of a module and obtained

from the use cases.

In the test scenario, there is a detailed testing process due to many associated test cases.

Before performing the test scenario, the tester has to consider the test cases for each

scenario.

Test Case

It is an in-details document that describes step by step procedure to test an application.

It consists of the complete navigation steps and inputs and all the scenarios that need to

23 | P a g e
be tested for the application. We will write the test case to maintain the consistency, or

every tester will follow the same approach for organizing the test document.

Test Plan

It is a document that is prepared by the managers or test lead. It consists of all

information about the testing activities. The test plan consists of multiple components

such as Objectives, Scope, Approach, Test Environments, Test methodology, Template,

Role & Responsibility, Effort estimation, Entry and Exit criteria, Schedule, Tools, Defect

tracking, Test Deliverable, Assumption, Risk, and Mitigation Plan or Contingency Plan.

Requirement Traceability Matrix (RTM)

The Requirement traceability matrix [RTM] is a document which ensures that all the test

case has been covered. This document is created before the test execution process to

verify that we did not miss writing any test case for the particular requirement.

Test Strategy

The test strategy is a high-level document, which is used to verify the test types (levels) to be

executed for the product and also describe that what kind of technique has to be used and which

module is going to be tested. The Project Manager can approve it. It includes the multiple

components such as documentation formats, objective, test processes, scope, and customer

communication strategy, etc. we cannot modify the test strategy.

Test Data

It is data that occurs before the test is executed. It is mainly used when we are

implementing the test case. Mostly, we will have the test data in the Excel sheet format

and entered manually while performing the test case.

24 | P a g e
The test data can be used to check the expected result, which means that when the test

data is entered, the expected outcome will meet the actual result and also check the

application performance by entering the in-correct input data.

Bug Report

The bug report is a document where we maintain a summary of all the bugs which

occurred during the testing process. This is a crucial document for both the developers

and test engineers because, with the help of bug reports, they can easily track the

defects, report the bug, change the status of bugs which are fixed successfully, and also

avoid their repetition in further process.

25 | P a g e
6. References

1. Chima, W. (2019, October 28). Requirements gathering for software development

projects. Retrieved April 09, 2021, from

https://www.bbconsult.co.uk/blog/requirements-gathering

2. Software testing - Overview. (n.d.). Retrieved from

https://www.tutorialspoint.com/software_testing/software_testing_overview.htm

3. Program documentation. (n.d.). Retrieved from

https://www.tutorialspoint.com/programming_methodologies/programming_meth

odologies_program_documentation.htm

4. Software requirements. (n.d.). Retrieved April 9, 2021, from

https://www.tutorialspoint.com/software_engineering/software_requirements.htm

5. 7 tools to gather better software requirements. (2020, December 16). Retrieved

from https://www.liquidplanner.com/blog/7-tools-to-gather-better-software-

requirements/

6. Functional decomposition. (n.d.). Retrieved from

https://www.tutorialspoint.com/software_testing_dictionary/functional_decomposi

tion.htm

7. 5 steps to a successful release management process | Lucidchart blog. (2020, June

30). Retrieved from https://www.lucidchart.com/blog/release-management-process

8. “Testing Documentation - Javatpoint.” Www.javatpoint.com,

www.javatpoint.com/testing-documentation

26 | P a g e
9. 7 tools to gather better software requirements. (2020, December 16). Retrieved

from https://www.liquidplanner.com/blog/7-tools-to-gather-better-software-

requirements/

10. Different Requirements Gathering Techniques and Issues. (n.d.). Retrieved from

https://www.ijser.org/researchpaper/Different-Requirements-Gathering-

Techniques-and-Issues.pdf

11. Software requirements. (n.d.). Retrieved from

https://www.tutorialspoint.com/software_engineering/software_requirements.htm

27 | P a g e