Manual testing Basics : Chapter 1

                                       Software Testing

“The goal of a Software Tester is to find bugs, and find them as early as possible and make sure they get fixed”

·          Software testing is the process of evaluation a software item to detect differences between current behavior of software and expected behavior defined by client. Software testing is a process used to identify the correctness, completeness, and quality of developed computer software. It includes a set of activities conducted with the intent of finding errors in software so that it could be corrected before the product is released to the end users.

·         In simple words, software testing is an activity to check whether the actual results match the expected results and to ensure that the software system is defect free.

---> What is Manual Testing?

Testing activities performed by people without the help of Softer Testing Tools.

Procedure:

            1) Writing Test Cases by using SRS, FRS and Use Case documents

            2) Reviewing Test Cases

            3) Executing Test Cases

            4) Finding & Reporting Bugs

            5) Getting it Fixed

Quality is defined as meeting the customers’ requirements in the first time and every time. How the system is well designed and performing.

  

Verification is the process confirming that software meets its specifications i.e. “Are we building the Product Right?” – Mostly QA engineers involved in this verification process.

-It includes Static Testing (by reviews, walk through and meeting to appraise document, plans, code and requirement). It is also called In-process testing and Quality Assurance.

-Verification begins in the initial phase and will be always associated with all phases of SDLC.

Validation is the process confirming that it meets the user’s requirements i.e. "Are we building the Right Product?" – Primarily test engineer involved. Also called as end process testing and Quality Control.

-It includes Dynamic testing (Unit testing, System testing, System integration etc.)

it appears after development phase. It is to validate the system against the requirements.”

---> When we know that testing is complete & when we have to stop our testing.

We never do exhausting testing i.e. Complete testing is not feasible for almost all projects. So we try to find optimum level of testing for a given project. 

Below are the points which indicate that testing is complete:

1. The exit criteria that was mentioned in the test plan document is achieved.

2. When we achieved number of successful test case execution at a specified level (all critical &key test cases should be executed and passed, even if certain test cases fail, may not be ‘show stoppers’ or  low priority.). 

In Real time, 100% defect free software is impossible & finding all bugs are impossible. 

So we try to do locate bugs based on priority & risks & defect clustering as root cause analysis that’s why we start testing as early as possible. Testing involved from first level of SDLC (i.e. involved in each level of software development)

3. When rate of bug finding decrease from certain specified level & all high priority & critical defect resolved).

4. When we don't have enough time to perform more test and have achieved a specified level of quality.( Testing should be stop if time allocated to project in test plan is complete)

5.Testing budget of the project or when the continued testing doesnot justify the project cost. The budget allocated to project should not be over than defined limit

6. Functional coverage, code coverage meeting client requirements as per the target benchmark.

**Testing is decided to take an account of the level of risks   eg. Time & budget.

Difference between Quality Assurance (QA) and Quality Control (QC )

Difference between QA and QC  :

What is QA ? what is the difference between QA and QC.

Both QA and QC are important for successful software development.But QA is bigger term under which QC comes.
QA means Quality assurance.it is basically process oriented term. QA usually a bigger term which looks on the process of product.
QA is not just limited to finding bugs.QA can suggest points as enhancement of any feature so that the quality of product increased and prevent bugs possibiltiy in future.
eg.verification (documentation).
QA thinks like what will be,is being and has done to improve the quality of product.
If any bug is caught by QA,he is just not log in defect management tool.QA tries to reach to the root cause of problem and inform developer.
QA involved udring whole process of software development.

QC is shorter term ,also called tester. QC is basically product oriented term.
QC starts after the complete development of software.his activities usually focus on finding defects.
Quality Assurance makes sure you are doing the right things, the right way.
Quality Control makes sure the results of what you've done are what you expected. 

How to start Testing?

How to start Testing?

As to start 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.

The following thing needs to write good test cases:
1.      Mock up ‘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:
1. SRS               2.Test Plan                3. Test Stratergy

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.
1.    Test Case Design                      2. 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, on a transaction by transaction basis from the start to finish.

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:

Requirement traceability matrix, Boundary value Analysis and Equivalence partitioning

What is RTM (Requirement traceability matrix) ?

Mapping 'Client Requirements' with 'Use case', 'test scenario' and 'test case' to ensure whether all the client requirements are covered.

Types of Trace-ability Matrices :

1.Forward Traceability: Mapping of requirements to test cases.
   eg.

2.Backward Trace-ability: Mapping of test cases to requirements.
    eg.

Why RTM is important:
1.It helps to increase test coverage.
2.The trace ability matrix document is prepared to show clients that the coverage is complete. 
3.It help to find out which test cases are impacted or need to be update if any specific requirement gets changed.
eg. Suppose there is RTM 

If Suppose 'forgot password' functionality is changed,then it is easy to identify with the help of RTM that which test scenario and test cases will be impacted.


                       Test Data Techniques/methodologies

Test Data:
Boundary value Analysis and Equivalence partitioning are test data/test case methodology of black box testing.

eg. Suppose for input box,there is expected acceptable range is from 1 to 1000.


1. Equivalence Partition:
It focus on finding error in center of input domain.
Under this testing,we makes three sets .(three equivalence classes)

Lets take an example of any text field which accept only data between range of 1 to 1000.

1st Class:(with valid values) eg. Pick Any single value from between range range 1 to 1000.
2nd Class:(lower invalid value) eg. Pick any value below 1.
3rd Class:(Upper invalid value) eg. Pick any value above 1000.

(Lower Invalid value) < ( Valid Range : 1 ---- 1000) < (upper invalid value)

Equivalence partitioning uses fewest test cases to cover maximum requirements.


2. Boundary value analysis: 
Basic logic: There is always maximum possibility of bugs at the boundaries of input domain.So,BVA focus on boundary of input domain.

It is a next part of Equivalence partitioning for designing test cases where 
test cases are selected at the edges of the equivalence classes.


1st:: Value at exact input boundary. i.e. values 1 and 1000 in our case.
2nd:: Value just below the extreme edges of input domains i.e. values 0 and 999.
3rd:: Value just above the extreme edges of input domain i.e. values 2 and 1001.

eg.     (invalid 0 ) < ( Valid: 1---- Valid:1000) < (invalid 1001 )

If range: 1---1000
then boundary value is 1 & 1000. so '1' is min & '1000' is max.
1.)valid: min,max  eg.  '1'  & '1000'
2.)valid: min+1,max-1 eg. '2' & '999'
3.)Invalid : min-1,max+1  eg. '0'  & '1001'
   
Boundary value analysis is often called as a part of stress and negative testing.
So,we can say Boundary value analysis is best practice for software testing.


Example:
In online form of any entrance exam,there is always a some eligibility criteria for students that
'The minimum age limit is 21 years and maximum age limit is 32 years and the number of attempts is 06'.
Now the questions is how many test cases we need to test this 'Age' and 'Attempt' functionality.
you can test by any date of birth.But large no. of scenario will waste your time.Then we always look for the way by which we can test any functionality by minimum no.of test cases which cover your functionality correctly and save your time. The best practice is B.V.A. because we know there is always of chance of bugs at boundary.

As per Boundary value Analysis:
'Minimum no. of test Scenario' needed  is '6'.
Since Age limit  from 21 to 32.

Valid:
TS#01: Test Age field with  min.'21' yrs old. (i.e. Min )
TS#02: Test Age field with  max.'32' yrs old. (i.e. Max )

Valid:
TS#03: Test Age field with '22' yrs old. (i.e. Min+1 )
TS#04: Test Age field with '31' yrs old. (i.e. Max-1 )

Invalid:
TS#05: Test Age field with '20' yrs old. (i.e. Min-1 )
TS#06: Test Age field with '33' yrs old. (i.e. Max+1 )


While for testing 'Attempt' field.
Since validation limit is 6 attempts.it means as person can try upto 6 attempts.
So,there are '3' minimum no. of test cases to test 'Attempt' field.So,We will test only with these 3 TC.
So As per BVA,

Valid:
TS#01: Test Attempt field with '6' . (i.e. Max. )


Valid:
TS#02: Test Age field with '5' . (i.e. max-1 ).it means If 5 is accepted by application.it means there is high possibility of accepting 4,3,2,1,0. So,now there is no need of testing with Age values 4,3,2,1,0

Invalid:
TS#03: Test Age field with '7' . (i.e. Max+1 ).it means If 7 is not accepted by application.it means there is high possibility of accepting 4,3,2,1,0. So,now there is no need of testing with Age values 8,9,10 etc.

lets take another example of 'Age' date range for 'Date of Birth' field.
There is 'Date of Birth' field on exam form which can accept only those candidate form whose age is between of 21 years to 32 years old.
now to test this 'Date of Birth' field ,we have to identify minimum number of test cases to test its validation limit.

Defect Life Cycle

What is Defect ?

"Defect is any variance of actual result from expected result."

It is the difference between expected result and actual result.

Expected result is the something that actually client expects behavior of his product.

This may be related to UI ,functionality ,performance of application etc.

If application is not behaving what client is expected.then its 'Defect'.

The client provides product requirement doc(PRD)/Functional requirement specification (FRS)doc/Behavior requirement doc(BRD) as reference document to convey its expectation from his product.

After getting requirement from client,Developer starts work on UI and functionality of application according to Requirement doc.After building application,Developer provides build to tester for testing.If tester finds any discrepancy in application that is not as per client requirements.Then,tester will log this as bug/defect.