What is Testing

Is a Process of executing the software with the intent of

finding errors
To verify that it behaves as specified"
To detect errors and deliver a Quality Software
To validate that what has been specified is what the user
actually wanted.

Quality Software: Quality software is reasonably bug-free,
delivered on time and within budget, meets requirements
and/or expectations, and is maintainable.


Test Case
Test Case:
A set of test data and test programs (test scripts) and their expected results.
A test case validates one or more system requirements and generates a pass or
fail


TEST CASES
Quality
Attributes
Information
objectives
Details required to kick off Test design
Read specification and requirements carefully.

Be clear with the design and implementation detail

Analyze and identify all possible sentences

Identify test environment and test types

Should have details information related to affected areas of the
requirement

Should be clear on behavior of failure

Attributes of a Good Test Case
Accurate
tests what its designed to test
Economical
no unnecessary steps
Repeatable, reusable
keeps on going
Traceable
to a requirement
Appropriate
for test environment, testers
Self standing
independent of the writer
Self Cleaning
picks up after itself

Test case design- Dos (1/2)

Self explanatory
Write test steps in simple sentences in conversational language and should
be understandable by naive user.
Mention Navigation steps cleary
steps requires, Key verification is Screenshot, then in the last line mention
"Take a Screenshot" in Bold in the instructions.
Easy language:
simple conversational language
Use Active Case Say do this,
Use present tense for Expected Result(Eg: system displays Home Page )


Test case design - Dos (2/2)

Simple and Short
Avoid multiple user actions in one step, split the same where ever its
necessary
20 -25 steps or less .in case of integration test cases try to provide pre-
requisite/reference instead of explaining/testing functionality again.
Valid Generic test cases
Apply test techniques to convert requirements to test cases
Write all Positive test cases which includes composite cases, edge cases
,failure cases and Negative test cases
Parameterize the variable so that values can be fed at run time.
Cross-platform
Test should be cross-platform as reasonably possible


Test Execution - Dos
Test cases Approval
Approvals are necessary before starting test case execution(App to reg env)
Sanity Testing ( if Applicable)
Sync with Test Plan and Test Strategy
entry/exit criteria
Features to be tested/not tested
Test Data population in QC
Populate correct test Data the parameters
Screenshot
For any critical test steps executed, irrespective of whether its failed or passed.
capture evidence before and after while test step executes any action (ex, deleting
a file, DB submission), as needed
for the failed step, Actual result is mentioned clearly with a screenshot is though
step does not say Key verification is screenshot.
Language:
Use present perfect tense for Actual Result(Eg: Home Page is displayed, system
displayed homepage)





Defect raising - Dos
Defects:
Raise defect immediately , and attach the defect to test step and fail the test case
supporting Screenshot should be attached.
Description of the defects should be clear and has reproducible steps,expected,actual result
Test data used for testing
Any workaround
Environment


Software Testing Donts
DO NOT
Use draft (unapproved) test plans for reference
Ignore the test strategies identified in the test plan during testing.
use words like Should / Must in the expected result
Parameterize Password
Use if else, should and will words while constructs in the test steps,
Update the test cases while executing it for testing. Track the changes and update it based on a
written reference (SRS or functional specification etc).
Track defects in many places
Spend time in testing the features that are not part of this release
Focus your testing on the non critical areas
Forget to document it. even if the defect identified is of low priority,
Leave room for assumptions while verifying the fixed defects. Clarify and then close!
Focus more on negative paths, which are going to consume lots of time
Overtake developers
Tired of testing, do as much as you can,What you have done is enough
Dont be Harsh to explain your views to others in tough situation