ManualTesting Suresh V005

Selenium Training by Suresh
Manual Testing Notes By

SURESH
Naresh i Technologies, Opp. Satyam Theatre, Ameerpet, Hyd, Ph: 040-23746666, www.fb.com/nareshit
1 of 58
Mr. Suresh – Profile
 Currently working as a Consultant with one of the Top MNC and has 15
+ years of genuine experience in Software Testing.
 Hands-on experience with Selenium since 2009 and has 10 years of in-
house Corporate Training experience.
 Successfully trained multipul batches on Selenium
 Expert in Selenium Automation using Selenium RC and WebDriver.
Heavy Programming using Java, TestNG and worked with QTP and
Ruby with Watir as well.
 Proficient in Planning, Designing, Building and maintaining complex
automation frameworks (Keyword, Modular, Hybrid and POM).
 Pro-active Team Leader and Manager with strong focus on
documentation and process.
 Rich industry experience as worked with Symphony Services,
Accenture, IGATE and Capgemini.
Specializations:
 Expertise in creating Test Automation Frameworks for open source
automation tools.
 Competence in open source automation APIs like Selenium RC and Web
Driver.
 Proficiency in conducting Classroom, Corporate and Online Training on
Selenium.
2 of 58
Manual Testing Course Content
Introduction to Software Testing
-What is Software Testing
-Why Software Testing
-Benefits of Software Testing
-What is Quality
Overview of Software Testing
Why Testing Required
Why Testing Job
Testing Roles & Responsibilities
-Software Test Engineer Responsibilities
-Sr. Software Test Engineer Responsibilities
-Test Lead Responsibilities
-Test Manager Responsibilities
SDLC–Software Development Life Cycle
-Phases in SDLC :
SDLC Real Time Process Implementation
Types of SDLC Models
-Waterfall model
-V - model
-Agile - Process
Software Testing Methodologies
-Block Box Testing
-White box testing
Real Time Folder Structure To implement STLC
STLC – Software Testing Life Cycle
-STLC Phases
Test Plan
-Entry/Exit Criteria to prepare Test Plan :
-Contents in Test Plan
Test Scenarios
-How to create a Test Scenario
-Entry/Exit Criteria to Identify Test Scenarios :
-Test Scenarios Template
-Sample Example of TestScenarios
Test Case
-What is Test case?
-The benefits of an effective test case include:
-Entry/Exit Criteria to Identify Test Cases :
-Test Case Template
-Sample Example of TestCases
Test Case Design Techniques
3 of 58
-Black box techniques
-White box techniques
Test Execution - Bug or Defect Management
-Bug / Defect Template
-Sample Example of BugReporting
Bug or Defect Life Cycle
-What is a defect/bug lifecycle in software testing?
-Difference between Defect /Bug/Error/Failure
JIRA Tool:
-Jira Login Process:
-Steps to Create Test Cases in JIRA :
-How to Pass a test case:
-Steps to Report Bugs in JIRA
Types of Testing
-SmokeTesting
-Sanity Testing
-Re Testing
-Regression Testing
-Static Testing
-Dynamic Testing
-Adhoc Testing
-Alpha Testing
-Beta Testing
-Functionality Testing
-Usability Testing
-Compatibility Testing
-Database Testing
-interfaceTesting
-Performance Testing
-Security Testing
Test Closure
When to stop Testing?
4 of 58
What is Software Testing
“Software testing is a process of executing the application with the intent of
finding the defects by
comparing the output behavior of the application with expected behavior
(requirement).”
In other words it’s comparing the actual behavior of an application with
expected behavior.
Why Software Testing
Humans make mistakes all the time!!
“Software testing is really required to point out the defects and errors that were
made during
the development phases”.
We humans can’t identify our mistakes in a work done by us. We should get
someone else to check our
work because another person may identify the mistakes done by us. In the same
way software
developers may not identify the mismatches in a program or application
implemented by them which
can be identify by the another department called Software Test Engineer.
Benefits of Software Testing
“Software testing helps in finalizing the software application against business
requirements.”
Software testing makes sure that the testing is being done properly and hence
the system is ready for
the customers to use.
Below are few benefits of software testing.
- Finding the defects before delivery
- Gaines the confidence about quality
- To Prevent defects
- Ensure the requirements are delivered to client
What is Quality
“Software quality is nothing but delivering a bug free application and delivered
on time with all requirements.”
5 of 58
Overview of Software Testing
Why Testing Required

 To identify the defects in development phases
 To ensure Quality of the product
 Saves Money as defect identified in earlier stages
 To build customer confidence and business
Why Testing Job

 Software Testers Are Made for Challenging Work Environments
 You Can Enjoy Every Day of Work
 Flexible and Fun Work Environment
 It’s Creative
 It Is a Secure Career Path
 There Is Attractive Remuneration and Room for Growth
 An Academic Background Isn’t a Necessity
6 of 58
Testing Roles & Responsibilities

 Software Test Engineer(STE) – (0-4yrs)
 Sr. Software Test Engineer(SSTE) – (4-6yrs)
 Test Lead (TL) – (6-8yrs)
 Test Manager(TM) – (8-10yrs)
 Sr.Test Manager(STM) – (10+yrs)
 Assoc. Dir. – Software Testing
 VP – Software Testing
Software Test Engineer Responsibilities

 Understating the requirements of the application
 Identifying required Test Scenarios of the project
 Designing and preparing Test cases to validate application
 Execute test cases to validate application
 Logs Test Results(How many Test cases passes/failed)
 Defect Report and Tracking
 Retest fixed defects of previous builds
 Performed various Types of testing assigned by Test Lead(Sanity
,Functionality , Usability, Compatibility , etc)
 Preparing and Sending of status Reports to Lead on assigned tasks
 Participated in regular meetings , team meetings by lead & Manager
 Creating automation scripts for Regression testing
Sr. Software Test Engineer Responsibilities

 Same as test engineer responsibilities
+
 Participates in Review of Test Scenarios ,Test cases and defects
 Some Times involved in Test Plan preparation also.
 If required Leading the team when Team Lead is on Vacation
Test Lead Responsibilities

 Task Preparation and allocation to Team members
 Training Team members
 Team Management
 Test Scenarios & Test Cases Reviews
 Bug Reviews
 Preparation of Build summary report
 Conducting meetings with Team members
7 of 58
 MOM Preparation
 Test Plan preparation
Test Manager Responsibilities

 Project plan and Review of Test Plan
 Effort estimates
 Project Management
 Training Plan – Identify training need based on Resource skills
 Preparing monthly reports
 Client Communications
 MOM
 Provide regular status updates to core team
 Scheduling meetings with Development and Testing Team
SDLC–Software Development Life Cycle

SDLC is a process followed for a software project, within a software
organization. It consists of a detailed plan describing how to develop, maintain,
replace and alter or enhance specific software.
Phases in SDLC :
 Requirements gathering
 Analysis
 Design
 Coding/Development
 Testing
 Deployment/Production
 Maintains/Support
SDLC Real Time Process Implementation :
8 of 58
9 of 58
Types of SDLC Models
 Waterfall model or Life Cycle Model or Linear Sequential Model
 V- Model or Verification & Validation Model
 Agile …etc
Waterfall model
 This model suggests a systematic and sequential approach to software
development that begins at requirements analysis and progress through all
life cycle phases sequentially
 Suitable for projects where requirements are clearly defined
 Small and medium term duration
 Having Domain knowledge
Advantages :
 Project under Control
 Pre-defined outputs at every phase
 Tracking changes is easy
Disadvantages:
 Not suitable for requirements changes
 Does not support going back to previous phase
 If any defect found need to go back to the originating phase
10 of 58
V - model
 V model means verification and validation model, the V shaped life cycle
is a sequential path of execution process.
Advantages :
 Simple and easy to use
 Testing activities like planning and test design will be done before coding
 Testing planned parallel to development
 Bug detection in early phases
Disadvantages:
 If any changes happen in midway, then the test document along with
requirements documents has to be updated.
 Not Suitable for large and complex projects
 The client sees the only final project ,not intermediate modules
Difference between Verification & Validation :

11 of 58
Verification Validation
check whether we are developing the check whether the developed
right product or not. product is right.
Verification includes different In the validation testing, we can find
methods like Inspections, Reviews, those bugs, which are not caught in
and Walkthroughs the verification process.
In verification testing, we can find Validation includes testing like
the bugs early in the development functional testing, system testing,
phase of the product. integration, and User acceptance
testing.
The goal of verification is The goal of validation is an actual
application and software architecture product.
and specification.
Agile - Process
Overview of Agile Process
 Customer satisfaction by rapid delivery of useful software.
 Welcome changes in requirements ,even late in development
 Working software is delivered frequently (weeks rather than months)
 Close ,daily cooperation between business professionals and developers
 Continuous attention to technical excellence and good design
12 of 58
Typical QA Approach for Agile Projects
Agile - Terms
 User Story – A shorthand requirements document.
 Product Backlog -- A prioritized list of stories that are waiting to be
worked on.
 Product Owner -- person whom holds the vision for the product.
 Scrum Master Role The Scrum Master is a facilitator for the team and
product owner.
 Sprint -- A development process
 Stand-up Meeting– a short (15 minutes or less) daily meeting during
which team members report on what they have accomplished since the
last meeting, what they plan to accomplish today and report any
impediments or blockers to making progress.
 Scrum Meeting – To discuss on Sprint planning, development and
Review.
13 of 58
Software Testing Methodologies
 Block Box Testing
 White box testing
Black Box Testing:
Black box testing involves testing a system with no prior knowledge of its
internal workings. A tester provides an input, and observes the output generated
by the system under test. This makes it possible to identify how the system
responds to expected and unexpected user actions, its response time, usability
issues and reliability issues.
Black box testing is a powerful testing technique because it exercises a system

end-to-end. Just like end-users “don’t care” how a system is coded or
architected, and expect to receive an appropriate response to their requests, a
tester can simulate user activity and see if the system delivers on its promises.
Along the way, a black box test evaluates all relevant subsystems, including
UI/UX, web server or application server, database, dependencies, and integrated
systems.
White Box Testing
White box testing involves testing an application with detailed inside
information of its source code, architecture and configuration. It can expose
issues like security vulnerabilities, broken paths or data flow issues, which
black box testing cannot test comprehensively or at all.
14 of 58
Real Time Folder Structure To implement STLC
STLC – Software Testing Life Cycle

Software Testing Life Cycle (STLC) is a process used to test software and
ensure that quality standards are met. Tests are carried out systematically over
several phases. During product development, phases of the STLC may be
performed multiple times until a product is deemed suitable for release.
 STLC is an part of Software Development Life Cycle (SDLC).STLC
deals only with the testing phases.
 STLC starts as soon as requirements are defined.
 STLC provides a step-by-step process to ensure quality software.
STLC Phases
STLC has the following different phases but it is not mandatory to follow all
phases. Phases are dependent on the software or the product, time and resources
allocated for the testing and the model of SDLC that is to be followed.
 Requirements understanding (BRS, SRS, FRS, Mock-ups)
 Test Plan
 Test Scenarios
 Test Cases
15 of 58
 Test Execution
 Bug Reporting & Re-Testing
 Test Closer
Note:
BRS – Business Requirement Specification
SRS – Software Requirement Specification
FRS – Functional Requirement Specification
Mock-Ups : Screenshots
Requirements understanding:
When the requirement docs are ready and shared with testing team, then testers
starts understanding the requirements to design test scenarios & testcases.
Test Plan:
Test Lead plans the test strategy & approach which is outlined in a test plan
document. This strategy includes tools needed, testing steps, and roles and
responsibilities. Part of determining this strategy is a risk and cost analysis and
an estimated timeline for testing.
Test Scenarios:
(What need to tested)-Design the test scenarios based on scope and criteria’s.
Test Cases:
(How to be tested) test cases are created. Each case defines test inputs,
procedures, execution conditions, and anticipated results. Test cases should be
transparent, efficient, and adaptable. Once all test cases are created, test
coverage should be 100%.
Test Execution:
features are tested in the deployed environment, using the established test cases.
Expected test results are compared to actual and results are gathered to report
back to development teams.
Bug Reporting & Re-Testing : Reporting the bugs using bug template
Test Closer:
This is the last phase of the STLC, during which a test result report is prepared.
This report should summarize the entire testing process and provide
comparisons between expected results and actual. These comparisons include
objectives met, time taken, total costs, test coverage, and any defects found.
16 of 58
Test Plan
Test Plan – A document describing the scope, approach, resources & schedule
of testing activities. It identifies test items ,the features to be tested, the testing
tasks who will be doing and any risks …etc
Entry Criteria to prepare Test Plan :
 Approved PMP
 Approved SRS
 Test Plan guidelines
 Test Plan template
Exit Criteria of preparing Test Plan :
 Test Plan should be reviewed and approved.
Contents in Test Plan

1. Introduction
1.1 Test plan objectives
2.Scope of this document
3.Test Strategy
3.1 Smoke Testing
3.2 Sanity Testing
3.3 Functional Testing
3.4 Database Testing
3.5 Cross browser Testing
3.6 Automation Testing
4.Environment Requirements
5.Test Schedule
6.Control Procedures
6.1 Reviews
6.2 Bug Reviews
7.Functions To be tested
8.Functions not to be tested
9. Resources & Responsibilities
10. Deliverables and mile stones
11. Defect Management
12. Dependencies
12.1 personal dependencies
12.2 Software dependencies
12.3 Hardware dependencies
12.4 Test Data & Database
13. Risks
14. Tools
17 of 58
15. Documentation
16. Approvals
17. Entry / Exit for each Testing activity
18. Test Suspension
19. Test Resumption
20. Test completion
Test Scenarios
Identify all possible areas to be tested or What is to be tested.
A Test Scenario is a statement describing the functionality of the application to
be tested. It is used for end-to-end testing of a feature and is generally derived
from the requirement document.
Test scenarios can serve as the basis for lower-level test case creation. A single
test scenario can cover one or more test cases. Therefore a test scenario has a
one-to-many relationship with the test cases.
How to create a Test Scenario
 Carefully study the Requirement Document – Business Requirement
Specification (BRS), Software Requirement Specification (SRS),
Functional Requirement Specification (FRS) pertaining to the System
Under Test (SUT).
 Isolate every requirement, and identify what possible user actions need to
be tested for it. Figure out the technical issues associated with the
requirement. Also, remember to analyze and frame possible system abuse
scenarios by evaluating the software with a hacker’s eyes.
 Enumerate test scenarios that cover every possible feature of the
software. Ensure that these scenarios cover every user flow and business
flow involved in the operation of the website or app.
 After listing the test scenarios, Get the scenarios reviewed by a team.
Entry Criteria to Identify Test Scenarios :

 Approved Test plan
 Approved SRS
 Test Scenarios Guidelines
 Test Scenario template
Exit Criteria for Test Scenarios :
 Test Scenarios should be reviewed & approved(mapping test scenarios
with requirements)
Test Scenarios Template

18 of 58
Sample Example :
Company Logo : Logo of the company
Project ID : ID of the Project
Project Name : Name of the Project
Identified by : Name of the tester
Date Identified : Day of the started writing the Test Scenarios
Reviewed By : Test Lead Name
Date Reviewed : Future Date
Approved By : Test Lead Name
Date Approved : Future Date
TS# : Test Scenario ID
Req:# : Requirement ID
Main Functionality : Page Name
Test Scenario Description : What need to be Tested
Test casename /ID : Test Case ID for corresponding Test Scenario
Document ID / Reference : Which document we are refering to design the
Scenarios
Comments : In case of any spefic description need to be mention.
Test Case
What is Test case?
A test case is a document, which has a set of test data, preconditions, expected
results and postconditions, 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 postcondition.
19 of 58
It is an in-details document that contains all possible inputs (positive as well as
negative) and the navigation steps, which are used for the test execution
process. Writing of test cases is a one-time attempt that can be used in the future
at the time of regression testing.
Test case gives detailed information about testing strategy, testing process,
preconditions, and expected output. These are executed during the testing
process to check whether the software application is performing the task for that
it was developed or not.
Test case helps the tester in defect reporting by linking defect with test case ID.
Detailed test case documentation works as a full proof guard for the testing
team because if developer missed something, then it can be caught during
execution of these full-proof test cases.
The benefits of an effective test case include:

 Guaranteed good test coverage.
 Reduced maintenance and software support costs.
 Reusable test cases.
 Confirmation that the software satisfies end-user requirements.
 Improved quality of software and user experience.
 Higher quality products lead to more satisfied customers.
 More satisfied customers will increase company profits.
Entry Criteria to Identify Test Cases :

 Approved Test plan
 Approved SRS
 Approved FRS
 Approved Test Scenarios
 Test Case Guidelines
 Test Case Template
Exit Criteria for Test Cases :
 Test Cases should be reviewed & approved(mapping test scenarios with
requirements)
Test Case Template
20 of 58
--Sample Example :
Company Logo : Logo of the company
Project ID : ID of the project
Project Name : Name of the Project
Created By : Tester name
Review By : Test Lead name
Approved By : Test Lead name
Date Created : Day of the Started writing Test Cases
Date Reviewed : Future Date
Date Approved : Future Date
Test Executed By : Tester name
Version : Version of the Test Case Document
Date Executed : Form Which Date Test Case Execution need to start
Build : build number
Total No of Test Cases : The Total number of Test Cases Created for whole
application.
Passed: Total number of Test Cases passed
Failed: Total number of Test Case Failed
Not Executable: not executed test case count
Defects Reported: Bugs reports for the Whole application.
TC# : Test Case ID
TS# : Test Scenario ID mentions in Test Scenario Document
Test Design Steps : Steps To be Followed for Testing particular Functionality
Input Date : Test Data need to be used to test particular Functionality
Expected Result : Result Excepting Based on Requirement Document
Actual Result : Result displayed in Application
PASS : Expected Result & Actual Result both are matching consider as PASS
FAIL : Expected Result&Actual Result both are not matching consider as FAIL
Not Executable : Test Case Which are not executed for that current Release
Comments : In case of any spefic description need to be mention.
Defect ID : Bug ID for failed test Cases
21 of 58
Test Case Design Techniques

Test Case: Design techniques can broadly split in to 2 categories.
Black box techniques
White box techniques
Black box techniques
 Equivalence Class Partitioning(ECP)
 Boundary Value Analysis(BVA)
 State Transition
 Decision Table / Cause Effect Table
White box techniques
 Statement Testing
 Branch/Decision testing
 Data flow Testing
 Branch condition testing
Equivalence Class Partitioning (ECP) :

Divide a set of test conditions into groups which is having similar behavior to
reduce number of test cases.
Boundary Value Analysis(BVA):

BVA is based on testing the boundaries of condition
Formula : Minimum ,maximum ,Min-1 ,Max+1
Valid Boundaries : Minimum , Maximum
Invalid Boundaries : Min-1 ,Max-1
22 of 58
State Transition Table:

Application provides different output for same input based on previous stage
Decision Table :
Testing with different combination of inputs which produce different results.
23 of 58
Test Execution - Bug or Defect Management
Bug / Defect Template
Sample Example :
Defect ID : ID of the new Defect
Status : Status of the Bug
Severity : Need to provide based on Functionality
Priority : Need to provide based on Client Expectation
Module : Page Name
Reported By : Tester Name
Assigned to : Developer or Test Lead Name
Browser Name : Name of the Browser
Found in Build: in which build bug had found
Found in Version: number of the version
Fixed in Version : Developer will provide this
Fixed in Build :Developer will provide this
24 of 58
Defect Status : New ,Open ,Fixed ,closed ,Re-Open ,Not a bug, Duplicate
,Need More information, Can't reproduce .
Severity : Importance of defect with respective to functional point of
view…means criticalness of defect with respective to application.
Severity classification could be : S1-Urgent ,S2-High ,S3-Medium ,S4-Low ,
CRITICAL , HIGH ,MEDIUM ,LOW
Priority : Importance of defect with respective to client point of view … means
how soon it should be fix.
Priority Classification could be : P1-Urgent ,P2-High ,P3-Medium ,P4-Low,
CRITICAL , HIGH ,MEDIUM ,LOW
Sample Examples :
High Priority & High Severity: An error which occurs on the basic
functionality of the application and will not allow the user to use the system.
(Eg. A site maintaining the student details, on saving record if it, doesn’t
allow to save the record then this is high priority and high severity bug.)
High Priority & Low Severity: The spelling mistakes that happens on the
cover page or heading or title of an application.
High Severity & Low Priority: An error which occurs on the functionality
of the application (for which there is no workaround) and will not allow the
25 of 58
user to use the system but on click of link which is rarely used by the end
user.
Low Priority and Low Severity: Any cosmetic or spelling issues which is
within a paragraph or in the report (Not on cover page, heading, title).
Bug or Defect Life Cycle

What is a defect/bug lifecycle in software testing?
A defect lifecycle, or bug lifecycle, is a specific set of states that a software bug
goes through from discovery to fixation.
The lifecycle may vary from organization to organization depending on factors

like company policy, software developmental model (e.g., Agile, Waterfall,
etc.), and project timeline. However, the actual extensive defect lifecycle is as
below:
New: When a defect is logged and posted for the first time, its state is set as
“new”.
Assigned: After the defect has been posted and verified as a bug by the testing
team, it is assigned to the corresponding developer team.
Open: At this stage, the developer team has begun work on fixing the defect.
Fixed: After the necessary code changes are completed by the developers, the
defect’s state is set to “fixed”.
Retest: At this stage, the testing team retests the code given to them by the
developers.
Closed: Once the bug has been verified as fixed, the testing team closes the
26 of 58
issue.
Reopened: If the bug still exists, its state is set back to Open and the lifecycle
restarts.
Duplicate: If the defect is repeated twice or if the defect corresponds to the
same concept as the bug, the status is changed to “duplicate.”
Rejected: If the developer team feels that the defect is not a genuine defect,
they will change the defect’s state to “rejected.”
Deferred: If the defect is not of a high priority and is expected to get fixed in
the next release, then the defect is deferred.
Difference between Defect /Bug/Error/Failure

Defect : Problem which is identified on Developer machine at development
phase
Bug : Problem which is identified on Testers machine at testing phase
Error: Problem which is related to coding.
Failure : Problem which is identified By end users at production phase
JIRA Tool
In JIRA, Test case, Bug, Epic and Story will be called as Issues.
To create a JIRA issue, you need the Create Issue project permission for the
issue's relevant project.
Steps to set up Jira
Launch browser and enter url as - https://id.atlassian.com/login
Click on continue with google
Provide your valid Gmail details

27 of 58
Enter password
Click on Create Your account button
Click on Jira Software Product
Click on Get it Free button

28 of 58
Click on Next button
29 of 58
Enter any name in Your Site textbox and click on Agree button
Wait till whole setup need to complete
30 of 58
Click on Skip button
Click on continue button
31 of 58
Click on Skip button
Click on Scrum Option
Click on Use Template
32 of 58
Click on Team Managed Project button
Enter project name & Click on Create Project
33 of 58
Jira Project Home Page will be displayed
Navigate to Apps Main menu & Click on Manage Apps Submenu
34 of 58
Click on Find New apps
Search for zephyr scale App – Enter zephyr scale in textbox & Click on
ENTER button from keyboard
35 of 58
Click on the App of zephyr scale – Test management for JIRA
Click on Try it Free button
36 of 58
Click on Start free trial button
Your will get success message
37 of 58
Navigate to Projects Main menu and select the Project which is previously
created
Click on Zephyr Scale Option
38 of 58
Click on Project Setting Page
Click - on button
39 of 58
Click on button under permissions
40 of 58
Provide all the required permissions to add test cases and to execute test cases
**By this Setup will be completed
Agile Process in JIRA

41 of 58
Steps to Report Bugs in JIRA Tool
1.Login to JIRA tool
2. Click on Create button
3.Select the Required Project From the list.
4.Select the Bug option from Issue Type dropdown
5.Provide Summary of the bug
6.Provide the Bug Description which includes – Steps to re-produce , Expected

Result and Actual Result
7.Provide Tester name
42 of 58
8.Provide Priority for the bug
9.Mention Environment details
10.in case any screenshot attach the required files
11.Select the developer name from Assignee dropdown
12.Click on Create button
13.Bug will be created.

14.Refer Default dashboard to check created bugs
43 of 58
***Sprint Process
Click on Backlog Option
Click on Epic option & Enable Epic Panel
44 of 58
Click on Create Epic option & Provide all Epic details and Click on ENTER
button from keyboard
Select Required Epic and Create issue
45 of 58
Click on Start sprint & Provide all the sprint details and click on Start button
Sprint Home Page will be displayed as below
46 of 58
Click on BackLog main option and select required issue to create child
issue(User Story)
Provide user stories and click on Create button
47 of 58
Click on Zephyr Scale option To Create Test Cases for required User Story
48 of 58
Click on Create a test cases and write all the required test cases
Click on Save button & Continue in creating all the required test cases.
49 of 58
***Test Execution Steps :
Click on Cycles button To create Test Cycle
Click on New Test Cycle option & Under Details tab provide Name,Owner ,
start date and end date
Click on Test Cases Tab
50 of 58
Click on Add Test Cases option
Select Required Test Cases and click on Add button
Click on Save button
click on Back Link

51 of 58
Click on Required check box and then click on Run button.
Note: Based on Admin rights it will enable the run button.

In case of having admin rights, click on Run button and then will provide
Actual Result and Test Cases status(PASS/FAIL).
52 of 58
Types of Testing
53 of 58
54 of 58
55 of 58
56 of 58
57 of 58
Test Closure :
Test Closure is a document that is prepared prior to formally completing the
testing process. This memo contains a report of test cases executed, passed,
failed and number of defects found, fixed, re-tested, closed.
We will provide the path of all the required documents to client like test
scenarios, test cases, test execution and bug reporting, based on this report it
will decide to stop or continue the testing.
When to stop Testing?
This can be difficult to determine. Most modern software applications are so
complex, and run in such an interdependent environment, that complete testing
can never be done. Common factors in deciding when to stop are:
 Deadlines (release deadlines, testing deadlines, etc.)
 Test cases completed with certain percentage passed
 Test budget depleted
 Coverage of code/functionality/requirements reaches a specified point
 Bug rate falls below a certain level
 Alpha & Beta testing period ends
58 of 58

ManualTesting Suresh V005

Uploaded by

Copyright:

Available Formats

ManualTesting Suresh V005

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ManualTesting Suresh V005

Uploaded by

Copyright:

Available Formats

Selenium Training by Suresh

Manual Testing Notes By

Mr. Suresh – Profile

Why Testing Required

Why Testing Job

Testing Roles & Responsibilities

Software Test Engineer Responsibilities

Sr. Software Test Engineer Responsibilities

Test Lead Responsibilities

Test Manager Responsibilities

SDLC–Software Development Life Cycle

Difference between Verification & Validation :

Black box testing is a powerful testing technique because it exercises a system

Real Time Folder Structure To implement STLC

STLC – Software Testing Life Cycle

Contents in Test Plan

Entry Criteria to Identify Test Scenarios :

Test Scenarios Template

The benefits of an effective test case include:

Entry Criteria to Identify Test Cases :

Test Case Template

Test Case Design Techniques

Equivalence Class Partitioning (ECP) :

Boundary Value Analysis(BVA):

State Transition Table:

Test Execution - Bug or Defect Management

Bug / Defect Template

Bug or Defect Life Cycle

The lifecycle may vary from organization to organization depending on factors

Difference between Defect /Bug/Error/Failure

Provide your valid Gmail details

Click on Jira Software Product

Click on Get it Free button

Click on Next button

Wait till whole setup need to complete

Click on Skip button

Click on continue button

Click on Scrum Option

Click on Use Template

Click on Team Managed Project button

Enter project name & Click on Create Project

Jira Project Home Page will be displayed

Navigate to Apps Main menu & Click on Manage Apps Submenu

Click on Find New apps

Click on the App of zephyr scale – Test management for JIRA

Click on Try it Free button

Click on Start free trial button

Your will get success message

Click on Zephyr Scale Option

Click on Project Setting Page

Click on button under permissions

**By this Setup will be completed

Agile Process in JIRA

3.Select the Required Project From the list.

4.Select the Bug option from Issue Type dropdown

5.Provide Summary of the bug

6.Provide the Bug Description which includes – Steps to re-produce , Expected

7.Provide Tester name

9.Mention Environment details