Manual Testing : Chapter 2

                                                    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.