Manual Testing

Software Development Life Cycle

SDLC

SDLC stands for Software Development Life Cycle. SDLC is the process consisting of a series of planned activities to develop or alter the software products. • A process used by the software industry to design, develop and test high quality softwares. The SDLC aims to produce a high quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates

WHO DOES WHAT in the cycle?

Business Analysts define application requirements and testing objectives
Test Managers and Project Leads design test plans and develop test cases
Test Automation Engineers create automated scripts and store them in the repository
QA Testers run manual and automated tests, report execution results, and enter defects •
Developers implement the requirement, also review and fix defects logged into the system •
Project Managers create application status reports and manage resource allocation • Product

Managers decide whether an application is ready to be released

Software Development Life Cycle:

SDLC is a structured process that outlines the stages involved in the development of software applications. It provides a framework for planning, creating, testing, deploying, and maintaining software systems. There are various models of SDLC, but the following is a general explanation of the phases commonly found in most models:

Requirement Gathering and Analysis:

In this phase, the development team gathers requirements from stakeholders, including end-users, clients, and other relevant parties.

The requirements are analyzed to ensure they are clear, complete, and feasible.

System Design:

Based on the gathered requirements, the system architecture and design are created.

This phase involves creating high-level and low-level designs, including database schemas, user interface designs, and system architecture diagrams.

Implementation (Coding):

The actual coding of the software is done in this phase.

Developers write code according to the design specifications and coding standards.

Testing:

Once the code is developed, it undergoes various testing phases to ensure its quality and functionality.

Different types of testing such as unit testing, integration testing, system testing, and user acceptance testing (UAT) are performed to identify and fix defects.

Deployment:

After successful testing, the software is deployed to the production environment or released to end-users.

Deployment involves activities such as installation, configuration, data migration, and user training.

Maintenance:

Once the software is deployed, it enters the maintenance phase.

Maintenance involves fixing bugs, adding new features, enhancing performance, and addressing any issues that arise during the software's lifecycle.

Throughout the SDLC process, it's important to follow best practices such as continuous integration, continuous delivery (CI/CD), version control, and documentation to ensure efficient development and high-quality software products. Additionally, communication and collaboration among team members and stakeholders play a crucial role in the success of the SDLC process.

SDLC Project Methodology

Waterfall Development

• Structured Design

• Step-by-step approach to SDLC

• Became dominant in 1980s

• Proceed in sequence

• Project sponsor needs to approve the deliverables

• Deliverables approved

• The current phase ends

• Next phase begins

• Well documented

• Difficult to go backward

• Possible but difficult and rare.

Advantages

• Simple and disciplined

• Think first and code second

• Requirements are identified long before programming

• Time spent early is worthwhile

• A bug found in early stages is cheaper to fix

• Less money, time, and effort

• Minimize changes to the requirements

• Well suited for stable projects

• Problems are fully predictable

Disadvantages

• Impossible to get one phase perfected before moving on to next

• Leads to a lot of rework

• Lengthy deliverables are problematic

• Poor communication mechanism

• Important requirements might be overlooked

• Business environment is also changing

• Waterfall takes a static view of requirements

Parallel Development

A general design for the whole system is performed
The project is divided into a series of subprojects (can be designed and implemented in parallel)
Once complete, a final integration of the separate pieces (System is delivered)

Advantage

• Reduces the time to deliver the system

• Changes in the business environment are less likely to produce the need for rework.

Disadvantage

• Voluminous deliverables

• Integration could be very challenging

• Subprojects may not be completely independent

• Design decisions may affect each other

V-model Development

• Pay explicit attention to testing • Key concept • As requirements are specified and components designed • Testing for those elements is also defined • Each level of testing is clearly linked to a part of the analysis or design phase.

Advantage:

• Improves the overall quality

• Through early development of test plans.

Disadvantage:

•Suffering the same problems as Waterfall!

Rapid Application Development (RAD)

Get some part of the system developed quickly → Users can have better ideas earlier

Speed up by using → CASE tools Program generation techniques Visual programming languages.

Iterative Development

Break the overall project into a series of versions.

The most important and fundamental requirements are bundled into the first version.

Users provide valuable feedbacks to be incorporated into the next version of the system

Advantage

• Deliver a preliminary version to users quickly

• Inspire important additional requirements

Disadvantage

• First versions are incomplete

• Needs users’ patience

Agile Development

A group of programming-centric methodologies that focus on streamlining the SDLC.

Includes face-to-face communication.

Extreme programming – emphasizes customer satisfaction and teamwork.

Spiral Model

The Spiral Model is a risk-driven software development process model that combines elements of both waterfall and iterative development models. It was proposed by Barry Boehm in 1986 and is particularly useful for large, complex projects where requirements are not well understood or may change over time. The Spiral Model consists of the following key components:

Big Bang Mode :

The Big Bang model is a SDLC model where there is no specific process followed. The development just starts with the required money and efforts as the input, and the output is the software developed which may or may not be as per customer requirement.

Software Development Life Cycle

STLC Phase

S.N	PHASE	INPUT	ACTIVITIES	RESPONSIBILITY	OUT COME
1.	Test Planning What to test ? How to test ? When to test ?	Project plan Functional Requirements	Identity the resources Team formation Test Estimation Preparation of Test Plan Review on test Plan Test Plan sing-off	Test Lead/Team lead (70%) Testmanager (30%)	Test plan Document
2.	Test Designing	Project plan Functional Requirements Test Plan Design Docs Use Case	Preparation of test scenarios Preparation of test case Reviews on test case Traceability Matrix Test case sing-off	Test lead/Team lead(30%) Test engineers (70%)	Test cases document Traceability Matrix
3.	Test Execution	Functional Requirement Test Plan Test Case Build from Dev team	Executing test case Preparation of Test Report/Test log Identifying defects	Test lead/Team lead (10%) Test Engineers (90%)	Status/Test Reports
4.	Defect Reporting & Tracking	Test cases Test Reports/Test log	Preparation of Defect Report Reporting Defect to Developer	Test Lead/Team lead (10%) Test Engineers(90%)	Defect Report
5.	Test Closure/Sing-off	Test Reports Defect Reports	Analyzing Test Reports Analyzing Bug Reporting Evaluating Exit Criteria	Test Lead/Team Lead (70%) Test Engineers(30%)	Test Summary Reports

Test plan contents

A Test Plan is a document that describes the test scope, test strategy, objectives, schedule, deliverables and resources required to perform testing for a software product.
Test plan Template contents:

Overview→ (description)
Scope→ (according requirement document)

Inclusions
Test Environments
Exclusion

Test Strategy → ( type of test → manual, automation, regression, smoke, sanity )
Defect Reporting procedure
Roles/Responsibilities → who does what
Test schedule → when does what test with date
Test Deliverables → what
Pricing → by management dep
Entry and Exit criteria →
Suspension and Resumption Criteria → some time immediately testing stop
Tools → what kind of tool for manual and automation
Risk and mitigation → There will be some risk and resources
Approvals → who will approved the test plan document

Use Case, Test Scenario and Test Case

Use Case—> (PO/BA)

Use cases describe the requirement.
Use case contains three items

Actor, which is the user, which can be a single person or a group of people, interacting with a process.
Action, Which is to reach the final outcome.
Goal/Outcome, which is the successful user outcome.

Test Scenario → QA →what to test

A possible area to be tested.

Test Case→ QA → Whom to test

Step by step actions to be performed to validate functionality of AUT (How to test).
Test case contains test steps, expected result and actual result.

Test Scenario v/s Test Case

Test scenario is ‘what to be tested’ and test Case is ‘how to be tested’.

Example:

Test scenario: checking the functionality of login button

– TC1: click the button without entering username and password

– TC2: click the button only entering User name.

– TC3: click the button while entering wrong user name and wrong password

– TC4: click the button entering valid user name and password

Test Suite:

The suite is a group of test cases which belong to some category.

What is a test case ?

A test case is a set of actions executed to validate a particular feature or functionality of your software application.

Test Case Contents

Test case ID
Test case Title
Description
Pre-condition
Priority (High, medium, low)
Requirement ID
Steps/Actions
Expected result
Actual result
Test Data

Test case Template

Requirement Traceability Matrix (RTM)

Requirement Traceability Matrix describes the mapping of Requirements with the Test cases.
The main purpose of RTM is to see that all test cases are covered so that functionality should miss while doing Software testing

Requirement Traceability Matrix-Parameters include

Requirement ID
Req Description
Test case IDs

Sample RTM

Test Environment

Test Environment is a platform specially build for test case execution of the software product.
It is created by integrating the required software and hardware along with proper network configurations.
Test environment simulates production/real time environment.
Another name of test environment is Test Bed.

Test Executing

During this phase the test team will carry out testing based on the test plan and the test case prepared.
Entry Criteria: Test cases, Test Date & Test Plan
Activities:

Test cases are executed based on the test planning.
Status of test cases are marked, like Passed, Failed, Blocked, Run, and others.
Documentation of test results and log defects for failed cases is done.
All the blocked and failed test cases are assigned bug ids.
Defects are tracked till closure.

Deliverables: Provides defect and test case execution report with completed results.

Guidelines for Test Execution

The build being deployed to the QA environment is the most important part of the test execution cycle
Test Execution is done in a Quality Assurance (QA) environment.
Test execution happens in multiple cycles.
Test execution phase consists Executing the test cases + test scripts( if automation).

Defect/Bugs

Any mismatched functionality found in a application is called as Defect/Bug/Issue
During Test Execution Test engineers are reporting mismatches as defects to developers through templates or using tools.
Defect Reporting Tools

Jira → test management tools
Quality center
ClearQuest→ only bug reporting tool
Bug jilla
DevTrack etc

Defect report COntents

Defect_ID: unique identification number for the defect.
Defect Description: Detailed description of the defect including information about the module in which defect was found.
Version: Version of the application in which defect was found.
Steps: Detailed steps along with screenshots with which the developer can reproduce the defects.
Date Raised: Date when the defect is raised
Reference: Where you provide reference to the documents like. Requirements, design, architecture, or maybe even screenshots of the error to help understand the defect.
Detected By: Name/ID of the tester who raised the defect
Status: Status of the defect, more on this later
Fixed by: Name/ID fo the developer who fixed it
Date Closed:Date when the defect is closed
Severity: Which describes the impact of the defect on the application
Priority: which is related to defect fixing urgency. Severity priority could be High/Medium/Low based on the impact urgency at which the defect should be fixed respectively.

Defect Classification

Defect Severity

Severity describes the seriousness of the defect and how much impact on Business workflow
Defect severity can be categorized in to four class

Blocker(Show stopper) : This defect indicates nothing can proceed further.

Ex: Application crashed, login not work

Critical: The main/basic functionality is not working. Customer business workflow is broken. They cannot proceed further.

Ex1: Fund transfer is not working in net banking
Ex2: Ordering product in ecommerce application is not working.

Major: It cause some undesirable behavior, but the feature/application is still functional.

Ex1: After sending email there is no confirm message
Ex2: After booking cab there is no confirmation.

Minor: It won’t cause any major break-down of the system

Ex: look and feel issues, spellings, alignments.

Defect Priority

Priority describes the importance of defect.
Defect priority states the order in which a defect should be fixed.
Defect Priority can be Categorized into three class

High: The defect must be resolved immediately as it affects the system severely and cannot be used until it is fixed.
Medium: It can wait until a new versions/builds is created
Low: Developer can fix it in later releases.

Note : QA gives priority and it can be changed by dev/BA.

:QA gives severity and no one can change it .

High severity, Priority and low severity, priority defects

More examples

Defect Resolution

After receiving the defect report from the testing team, development tem conduct a review meeting to fix defects. Then they send a Resolution type to the testing team for further communication.
Resolution types

Assept
Reject
Duplicate → already reported
Enhancement → not defect new feature
Need more information → dev may ask mor information
Not Reproducible → not in dev environment
Fixed
As Designed

Test Cycle Closure

Test Metrics required data

percentage % of test cases Executed

= (No. of Test cases executed x 100) /Total No. of Test Cases written

% of test cases NOT Executed

= (No. of Test cases Not executed x 100) / Total No. of Test Case writtenx100

percentage % of test cases passed

= (No. of Test cases passed x 100) /Total No. of Test Cases executed

percentage % of test cases failed

= (No. of Test cases failed x 100 ) /Total No. of Test Cases executed

percentage % of test cases blocked

= (No. of Test cases blocked x 100) /Total No. of Test Cases executed

Defect density

No.of defect identified per requirement No. of defects foundSize(No. of requirements)

Defect Removal Efficiency (DRE):

DRE

= (Defects identified during testing x100 )/ fixed defectsDefect identified by the customer/missed defects

Defect Leakage= (No. of defect found in UTA x 100)/ No. of defects found in Testing

Defect Rejection Ratio= (No. of defects reject x 100) /Total No. of defects raised

Defect Age= Fided date-Reported date

Customer stisfaction=No. of complaints per period of time

Agile Methodology

It is an Iterative and incremental approach
Agile is an iterative and incremental process

Agile Principle

Customers do not need to wait for a long time.
We develop, test and release pieces of software to the customer with few features.
We can accept / accommodate requirement changes
There will be good communication between customer, business analyst, developer & testers

Advantage

Requirement change are allowed in any stage of development or we can accom requirement changes in the middle of development
Releases will be very fast (Weekly)
Customers do not need to wait for a long time.
Good communication between team
It is very easy doodle to adopt

Disadvantage

Less focus on design and documentation since we develop software very fast

Scrum(Framework)

Scrum is a framework through which we build software products by following agile principles.

Team ( 5-9)

Product owner 1

Scrum master 1

Dev Team: Dev lead 1

Front-End dev 1

Back-End dev 1

QA team: Test lead 1

Manual Tester 1

Automation tester 1

Total team = 9

Product owner :

Get the requirement from customer
Define the features of the product
Adjust features and priority every iteration as needed
Accept or reject work results.

Scrum Master:

The main role is facilitating and driving the agile process.
Educating the Team
Create and maintain burndown chart

Developer Team : Develop the software

Design software
Unit testing
Integration testing
Coding

Tester tem :Testing the software

Understanding requirement
Writing the test case
Executing the test case
Bug reporting/tracking

Scrum Terminology

User story: A feature / module in software → prepared by Product owner

Epic: Collection of user story belongs to the same category → prepared by Product owner

Product Backlog: contain list of user stories → prepared by Product owner

Sprint iteration : period of time to complete the user story decided by the product owner and team, usually 2-4 weeks of time.

Sprint planning meeting:

Meeting conducts with the team to define what can be delivered in sprint and duration.
Most of time it will one day meeting
Whenever start project first day
How many story in backlog and how many story develop and test in the sprint
What is the duration of sprint
Story point

Sprint backlog: List of committed stories by Dev and QA team for specific sprint.

Scrum meeting /Standup meeting / scrum call

Meeting conducted by scrum master every day for 15 mins. Called as scrum call/standup meeting.

What did you do yesterday ?
What will you do today
Are there any impediments in your way ? (An impediment is anything that slows or blocks progress)
Whole team (scrum master, product owner, Dev team and QA team.

Sprint retrospective meeting:

Conduct a meeting after completing of spring the entire team, including both the scrum master and the product owner should participate.

Story point:

Rough estimation of user story will be given by Dev and QA in the from of fibonacci series( 0+1+1+2+3+5+8)
Input: N = 10
Output: 0 1 1 2 3 5 8 13 21 34
Explanation: Here the first term of Fibonacci is 0 and second is 1, so that 3rd term = first(o) + second(1) etc and so on.

Test case	Dev	QA	Total
Log in	5hrs	3hrs	8hrs

Note: 1 story point = 1hr / 3 hrs/ 1 day (6hr) depending on the company.

Burndown chart:

Show how much work remains in the sprint maintained by the scrum master daily.

Scrum Board

Definition of ready(DoR) & Definition of Done(DoD)

Product Backlog (PO)

Sprint Backlog (Team)

Task

Agile and JIra

Test management tools

Bug Reporting and tracking tools

Agile Tools

Jira, versionONe, teamcity

Jira → Agile Management Tool

Jira software is for agile

JIRA Tutorial

The JIRA tutorial provides basic and advanced concepts of JIRA tool. Our JIRA tutorial is designed for beginners and professionals.

JIRA is one of the most widely used open source testing tools used in manual testing.

Our JIRA tutorial includes all topics of a testing tool such as Features, installation, issues, workflows, components, reports, etc.

What is JIRA?

JIRA is a software testing tool developed by the Australian Company Atlassian. It is a bug tracking tool that reports all the issues related to your software or mobile apps. The word JIRA comes from the Japanese word, i.e., "Gojira" which means Godzilla.

1 Home page of jira software project (kanban, scrum, bug tracking)