Software
Testing
How can be test a
software?
1. Manually.
2. Automation tool (with the help of test script written in
specific programming language).
Difference
among Exception, Bug, Error, Fault ,Failure and Defect:
Exception: Unexpected
event or happening, not related to SRS
Bug: Related
to SRS, Found by testers.(the deviation between Expected and Actual Result)
Error: not
related to SRS. Found by user (mistake in coding due to human activity called
Error)
→
Refers to difference between Actual Output and Expected output.
→
the deviation occurs in Coding is known as Error. It is at Developers Level.
Fault: It
is a condition that causes the software to fail to perform its required
function.
Failure: It
is the inability of a system or component to perform required
function according to its specification
Defect
: If same bug is given to developer to fix it then it is
called Defect.The deviation occurs in out come of a System. It is at
Customer/End-user Level.
Difference
between Testing and debugging?
Testing: Testing
is the process of finding the bugs.
Debugging: Fixing
the logged bug. Debugging is conducted by a programmer and the programmers
fix the errors during debugging phase. Testers never fix the errors, but rather
fined them and return to programmer.
Testing
|
Debugging
|
a.) Finding defect in the product
|
a.) Fixing that defect in the code
|
b.) Done by tester
|
b.) Done by Developer
|
c.) Intention is to find as many as bug to make product
bug free.
|
c.) Intention is to remove bug from the product which is
identified by tester.
|
Before
Starting testing:
Tester needs test
scenario & test cases because Test scenario tells ‘What to be test’ and
test case tells ‘how to be test’ which includes a detailed procedure and
expected behavior.
There are different types of documents may provide by client for
understanding product functionality(requirements).It may be have any type of
below documents.
1. Mockup ‘Screen’&
Use Cases : (it includes pictorial representation of screen & workflow)
2. User Story. it
includes screen, flows and functionality.
3. High Level Document:
It is the overall system design covering the system architecture and database
design. It describes the relation between various modules and functions of the
system. data flow, flow charts and data structures are covered under HLD.
Acceptance Testing is used in this design process.
High
level documents are:
a.) SRS b.) Test
Plan c.) Test Strategy
4. Low level document: Low
Level Design is like detailing the HLD. It defines the actual logic for each
and every component of the system. Class diagrams with all the methods and relation
between classes comes under LLD. Programs specs are covered under LLD.
Unit and Integration Testing is used in this design
process.
a.)Test Case Design b.)
Defect Logging etc. (includes every Action)
Use
case: Use Case is a pictorial representation of the business
logic and work flow that includes series of steps an actor performs on a
system to achieve a goal. i.e. a description of a particular use of the
system by an actor or user. Use Case is written in Business Design
Document (BDD) by the Business Analyst.. It is for understanding the
functionality for the person who is involved in writing/identifying the test
cases that cover the entire system.
eg. Leave Approval System
Mock up
:
eg.
Login Page :
eg. Leave Approval System:
User
stories: (requirement doc)
User Stories are short, simple descriptions of a feature
told from the perspective of the person (client) who desires the new
capability, usually a user or customer of the system. It is actually a test
requirement of client. They typically follow a simple template:
As a
<type of user>, I want <some goal> so that I can <reach some
goal>.
After collecting details from clients, The user stories should
be written by the business Analyst in the language of the customer so
that it is clear to both the business , the development & testing team what
the customer wants and why he wants it. The development team's job is to take
care of how to develop the code that will satisfy the requirements of the user
story. After that, testing team derived their test scenario from user story.
i.e. User Story / Mock up docs / Use
cases à Test scenario à Test cases
Test Scenario - A Scenario is any
functionality that can be tested. It is also called Test
Condition or Test Possibility. It tells superficially that what
functionality to be test have based on client requirement. While Test cases is
a detailed description of how to be test ,what is expected functionality or
what type of test data do we need to test this.
Test Scenario are derived from
the Use Case/User Story
& client Requirement (eg. Functionality req.) Of the Application.
While Test Case: From Test Scenario (Use
Case & Functionality Requirement) of App.
Based on the Test Scenario, Test engineer are writing test
cases.
Test Scenario is a collection of test cases. Test scenario is
like a high level test case that comprises low level test cases.
Test Data: Test
data is actually the input given to a software program i.e. the
multiple sets of values or data are used to test the same functionality of a
particular feature. •
Eg.
a. Test data may be alphabets e.g. username: Jassi – (to test
same login functionality).
b. Test data may be numeric e.g. username: 123 – (to test same
login functionality).
c. Test data may be alphanumeric e.g.Username: Jassi@12 –
(to test same login functionality)
d. Test data may be long integer e.g. Username:
Jassssiii….23e@@a123^&#^%E^EE^
e. Test data may be long after decimal e.g. Amount=
10.9999999999999999999
Test Data can be derived by many types:
· No data: Check
system response when no data is submitted
· Valid
data : Check system response when Valid test data is submitted
· Invalid
data :Check system response when Invalid test data
is submitted
· Illegal
data format: Check system response when test data is in invalid format
· Boundary
Condition Data set: Test data meeting bounding value conditions
· Equivalence
Partition Data Set : Test data qualifying your equivalence partitions.
• All the test values and changeable environmental components
are collected in separate files and stored as test data. It is also useful to
provide this data to the client and with the product or a project.
--------------------------------------------------------------------------------------------------------
Test Scenarios:
TS_01: Validate login page functionality when user enter invalid
credential
TC_01: Test case to test
Login functionality with valid username, valid password.
Test
Data: username: Jassi password: 123
TS_02: Validate login page functionality when user enter invalid
credential.
Test cases of Test
Scenario (TS_02): Login with invalid data:
TC_01: Test case to test
Login functionality with valid username, invalid password.
Test
Data: username: Jassi password: 123@W
TC_02: Test case to test
Login functionality with invalid username,invalid password.
Test
Data: username: Jasee password: 001020212
TC_03: Test case to test
Login functionality with invalid username, valid password.
Test
Data: username: jasse password: 123
TC_04: Test case to test
Login functionality with blank username & password.
Test
Data: username: password:
TC_05: Test case to test
Login functionality with valid username& blank password.
TC_06: Test case to test
Login functionality with blank username& valid password.
(Note: As we never do exhausting testing and here TC_6 is like very
low priority and rare case)
TS_03: Test Login functionality after deleting cache or delete
history.
TS_04: Test Recover password functionality or forgot password functionality.
Test cases of Test Scenario (TS_04): Test
forgot password functionality.
TC_01: Test case to verify whether the login page have 'forgot
password?' link.
TC_02: To check whether when we click the forgot password link
it is directing to forgot password link page.
TC_03: To check whether in that page it must ask for alternative
email id to send the link
TC_04: To check whether the link has sent to the mail to which
the user has provided
TC_05: To check whether the link can be used once.
TC_06: To check whether when the user using the link for more
than one time it should be dissolved
TC_07: To check whether the user opens the link it should ask
the security question same at the time he registered
TC_08: To check whether the answer given by the user at that
time and he has given while at the time of registering must be the same
TC_09: To check whether the user gives any wrong answer then it
must ask for the user to wait and to get more details to get his password
TC_010: To check whether the user gives the correct answer then
the link should move to new password page
TC_011: To check whether the user enters the new password and
retype the password both should match until new password should not be settled.
TC_012: To check whether once the password is settled then the
account should ask the user to move to his account or exit
What's the Test Case?
It is a document that includes all set of instructions like test
inputs, action(test steps), precondition, expected post condition (expected
result) developed for a particular objective i.e. Test case is a description of
what to be tested, what data to be given and what actions to be done to check
the actual result against the expected
Test case items are:
- Ø Test Case ID : ( unique id that generated automatically by defect management tool)Ø Test Case Name/Summary : (Short details about test cases )Ø DescriptionØ Pre-condition : (pre-requisite condition before testing this test case.)Ø Test Data, : ( type of test data require to test this test case)Ø Test steps : (mention all Steps to tell how you will test this test case)Ø Expected Result : ( What is expected outcoome from this test case)Ø Actual Result : (After execution,what result came)Ø Status : (Pass/Fail) ( If your expected result matches with actual then 'Pass' otherwise 'Fail)Ø Defect ID: ( If this test case failed, Raised defect in Defect management tool & mention here unique defect id against this failed test case)Ø Remarks (Anything that you think if it is necessary eg. Tested on both browsers etc.)
When can we start writing test cases?
It is the tester team who develops test case based on their
experience,sometime with the help of of developers and clients.
So, Product knowledge & Feature understanding are very
important to design good test cases to cover maximum functionality.
Once you get document related to any functionality, start
understanding the requirement & figure out test cases & other impacted
areas.
