You are on page 1of 15

TESTING - TEST CASES SQA

Aroosa Naseer
WHAT IS TEST CASE?
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.
Test cases for software help guide the tester through a sequence of steps to validate
whether a software application is free of bugs and working as required by the end
user.
Learning how to write test cases for software requires basic writing skills, attention to
detail, and a good understanding of the application under test (AUT)
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
HOW TO WRITE TEST CASES FOR
SOFTWARE?
Use a Strong Title
A good test case starts with a strong title. As a best practice, it’s good to name the
test case along the same lines as the module which you’re testing. For example, if
you’re testing the login page, include “Login Page” within the title of the test case.
Include a Strong Description
The description should tell the tester what they’re going to test and include any other
information such as the test environment, test data, and preconditions/assumptions.
Include Assumptions and Preconditions
You should include any assumptions that apply to the test and any preconditions that must be
met prior to the test being executed. This information can include which page the user should
start the test on, dependencies on the test environment, and any special setup requirements
that must be done before running the test. This information also helps keep the test steps short
and concise.
Keep the Test Steps Clear and Concise
The test steps should include the data and information on how to execute the test. This is
perhaps the most important part of a test case. Keep this section clear and concise, but don’t
leave out any necessary details.
Include the Expected result
The expected result tells the tester what they should experience as a result of the test
steps. This is how the tester determines if the test case is a “pass” or “fail”.
Make it Reusable
A good test case is reusable and provides long-term value to the software testing
team. When writing a test case, keep this in mind. You can save time down the road by re-
using the test case instead of re-writing it.
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.
Scenario Test Step Expected Result Actual Outcome

Verify that the input field Login to application and Application should be Application accepts all 10
that can accept maximum key in 10 characters able to accept all 10 characters.
of 10 characters characters.

Verify that the input field Login to application and Application should NOT Application accepts all 10
that can accept maximum key in 11 characters accept all 11 characters. characters.
of 11 characters

If the expected result doesn't match with the actual result, then we log a defect. The
defect goes through the defect life cycle and the testers address the same after fix.
TEST CASE DESIGN TECHNIQUE
Following are the typical design techniques in software engineering:
1. Deriving test cases directly from a requirement specification or black box test
design technique. The Techniques include:
Boundary Value Analysis (BVA)
Equivalence Partitioning (EP)
Decision Table Testing
State Transition Diagrams
Use Case Testing
CONTINUE…
2. Deriving test cases directly from the structure of a component or system:
Statement Coverage
Branch Coverage
Path Coverage
LCSAJ Testing
3. Deriving test cases based on tester's experience on similar systems or testers
intuition:
Error Guessing
Exploratory Testing
TEST CASE: LOGIN SUCCESSFULLY ON GMAIL
TEST CASE: LOGIN SUCCESSFULLY ON GMAIL
Title: Login Page – Authenticate Successfully on gmail.com
Description: A registered user should be able to successfully login at gmail.com.
Precondition: the user must already be registered with an email address and password.
Assumption: a supported browser is being used.
Test Steps:
1. Navigate to gmail.com
2. In the ’email’ field, enter the email of the registered user.
3. Click the ‘Next’ button.
4. Enter the password of the registered user
5. Click ‘Sign In’
Expected Result: A page displaying the gmail user’s inbox should load, showing any new message at the top of the page.
HERE’S WHAT THIS TEST CASE WOULD LOOK LIKE
IN TESTLODGE:
CONCLUSION
Writing test cases for software takes a little practice and knowledge of the software
that’s being tested. Well-written test cases can make your testing process smoother,
and save you time in the long run.
DEVELOP THE TEST CASE FOR REGISTER PAGE
Scenario:
Try To register with Email which is already in Use.

You might also like