Software Testing
Fundamental Dictionary
2
Agenda :
Type of Testing
Software Testing Keywords
–
Test Case
–
Test Scenario
–
Validation and Verification
3
4
Testing Types
Manual Testing
– Manual testing includes testing a software manually, i.e., without using any automated tool or any script. In this type, the tester takes over the role of an end-user and tests the software to identify any unexpected behavior or bug.
Automated Testing
– Automation testing, which is also known as Test
Automation, is when the tester writes scripts and uses
5
Manual Testing
The key concept of Manual Testing is to ensure that the
application is error free and it is working in conformance
to the specified functional requirements.
Test Suites or cases ,are designed during the testing
phase and should have 100% test coverage.
It also makes sure that reported defects are fixed by
developers and re-testing has been performed by testers
on the fixed defects.
Basically, this testing checks the quality of the system and
delivers bug-free product to the customer.
6
Automation Testing
Manual testing is performed by a human sitting in
front of a computer carefully executing the test steps.
Automation Testing means using an automation tool
to execute your test case suite.
The automation software can also enter test data
into the System Under Test , compare expected
and actual results and generate detailed
test reports.
Goal of Automation is to reduce number of test
7
8
9
10
Test Case
Test Case
– Test case is a concept which provides detailed information what to test, steps to be taken and expected result of the same
– 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.
11
Test Case
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
12
Test Case
Test Case Example
– Let us say that we need to check an input field that can accept maximum of 10 characters.
– While developing the test cases for the above scenario, the test cases are documented the following way. In the below example, the first case is a pass scenario while the second case is a FAIL.
13
Test Case
Scenario Test Step Expected Result Actual Outcome Verify that the
input field that can accept
maximum of 10 characters
Login to
application and key in 10
characters
Application
should be able to accept all 10
characters.
Application accepts all 10 characters.
Verify that the input field that can accept
maximum of 11 characters
Login to
application and key in 11
characters
Application should NOT accept all 11 characters.
14
Test Scenario
Test Scenario
– A Test Scenario is any functionality that can be tested. It is also called Test Condition or Test Possibility.
– As a tester, you may put yourself in the end user’s shoes and figure out the real-world scenarios and use cases of the Application Under Test.
– Scenario Testing is a variant of Software Testing where
15
Test Scenario
Why create Test Scenarios ?
– Creating Test Scenarios ensures complete Test Coverage
– Test Scenarios can be approved by various stakeholders like Business Analyst, Developers, Customers to ensure the Application Under Test is thoroughly tested. It ensures that the software is working for the most common use cases.
– They serve as a quick tool to determine the testing work effort and accordingly create a proposal for the client or organize the workforce.
– They help determine the most important end-to-end transactions or the real use of the software applications.
16
Test Scenario
Test Scenarios may not be created when
– The Application Under Test is complicated, unstable and there is a time crunch in the project.
– Projects that follow Agile Methodology like Scrum, Kanban may not create Test Scenarios.
– Test Scenario may not be created for a new bug fix or
17
Test Scenario
As a tester, you can follow these five steps to create Test Scenarios
– Step 1: Read the Requirement Documents like BRS, SRS, FRS, of the System Under Test (SUT). You could also refer uses cases, books, manual, etc. of the application to be tested.
– Step 2: For each requirement, figure out possible users actions and objectives. Determine the technical aspects of the
requirement. Ascertain possible scenarios of system abuse and evaluate users with hacker's mindset.
– Step 3: After reading the Requirements Document and doing your due Analysis, list out different test scenarios that verify each
feature of the software.
– Step 4: Once you have listed all possible Test Scenarios, a Traceability Matrix is created to verify that each & every requirement has a corresponding Test Scenario
18
So, what
’
s the difference ?
Test Case is
‘
How to be tested
’
and Test Scenario is
‘
What to be tested
’
– A test case is a set of conditions or variables under which a tester will determine whether an application, software
system or one of its features is working as it was originally established for it to do.
– Scenario testing is to make sure that end to end functionality of application under test is working as
19
So, what
’
s the difference ?
20
So, what
’
s the difference ?
21
So, what
’
s the difference ?
Simple Example (2)
22
So, what
’
s the difference ?
Simple Example (2)
23
24
Validation & Verification
Still remember the first Testing Level slide ?
What
’
s the difference between validation and
Validation & Verification
Validation and Verification
– In other words, software verification is ensuring that the product has been built according to the requirements and design
specifications, while software validation ensures that the product meets the user's needs, and that the specifications were correct in the first place. Software verification ensures that "you built it right".
Software validation ensures that "you built the right thing". Software validation confirms that the product, as provided, will fulfill its
intended use.
Verification is testing that your product meets the specifications / requirements you have written. “Did I build what I said I would?”.
26
Validation & Verification
Simple Example
– Consider following specification
– A clickable button with name Submet
– Verification would be check the design doc and correcting the spelling mistake.
27
Validation & Verification
Simple Example
– So new specification is
– A clickable button with name Submit
– Once the code is ready, Validation is done. A Validation test found
28
29
30
When to Start and Stop Testing ?
When to start
– An early start to testing reduces the cost and time to rework and produce error-free software that is delivered to the
client, read the first slide (why we do test ?)
– However in Software Development Life Cycle (SDLC), testing can be started from the Requirements Gathering phase and continued till the deployment of the software.
– It also depends on the development model that is being used.
For example, in the Waterfall model, formal testing is
31
When to Start and Stop Testing ?
When to stop
– It is difficult to determine when to stop testing, as testing is a never-ending process and no one can claim that a software is 100% tested. The following aspects are to be considered for stopping the testing process:
Testing Deadlines
Completion of test case execution
Completion of functional and code coverage to a certain point
Bug rate falls below a certain level and no high-priority bugs are identified
32
33
Who did the Software Testing ?
Who did the testing ?
– It depends on the process and the associated stakeholders of the project(s).
– For example in the IT industry, large companies have a team with responsibilities to evaluate the developed software in context of the given requirements.
– In most cases, the following professionals are involved in testing a system within their respective capacities:
Software Tester
Software Developer
Project Lead/Manager
34
