0% found this document useful (0 votes)
68 views

Testing Class

The document provides an overview of software testing concepts including different types of testing (manual vs. automated), types of testing (white box, black box, grey box), definitions of key terms like testing, defects, requirements, quality, and more. It also covers specific testing techniques like boundary value analysis, defect lifecycle, test case design, documents used like test plans, and non-functional vs. functional testing. Database concepts are briefly covered including SQL commands like select, update, joins.

Uploaded by

ravinyse
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
68 views

Testing Class

The document provides an overview of software testing concepts including different types of testing (manual vs. automated), types of testing (white box, black box, grey box), definitions of key terms like testing, defects, requirements, quality, and more. It also covers specific testing techniques like boundary value analysis, defect lifecycle, test case design, documents used like test plans, and non-functional vs. functional testing. Database concepts are briefly covered including SQL commands like select, update, joins.

Uploaded by

ravinyse
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 10

Software testing

Manual testing:

Theoretical part

Selenium Java

Qtp or uft with vb script

Definition:

Testing:

To assure quality…QA

Executing an application with AN intention of finding defects.

Defect:

Variation from the requirement.

Requirement:needs of the customer

Quality:

Meeting with customers requirements for the first time and every time.

Types of testing:

White box

Blackbox

Grey box

Whitebox testing:

Testing the source code .

.checking for syntax errors,loops and logical statements.

Developers will do wbt.

Blackbox testing:

Functionality or behavioural testing or opaque testing:

Testing the functionality of the application according to requirements.

Input ……check the functionality…output

Grey box testing:

Wbt and bbt

Testlink
Alm application life cycle management microfocus

Coding: converting requirements into p/l

Testing types in blackbox:

Functional testing:

Component level testing or fieldlevel testing or unit testing:

One module

Checking the fields inside the module with valid and invalid inputs.

Integration testing:interface testing

Checking the data transfer between two modules by combining them together.

System tsting or end to end tsting:

Checking the whole application by navigating through each and every module in the application.

User acceptance testing:

Alpha testing

Beta testing

Alpha:

Done by te in controlled environment

Beta:

Done by customers in uncontrolled environments

Software testing:

Executing an application with an intention of finding defects.

Defect:

Variation fro the requirements.

White box testing:gloss box or transparent box testing

Testing source code for syntax errors ,logical errors and loops.

Public void main(){

Int a,b,c;
a=b+c;

sopl(a);

Black box testing:functionality testing or behavioural testing or opaque testing:

Checking the functionality of the application according to requirements by giving valid and invalid
inputs.

Grey box testing:

50% bbt+50%wbt

Stub and driver:

Both are dummy modules .used for testing.

Performance testing

Testing the application under load stress and volume.

Load testing: with in the limit

Consider an application which can handle 100 users at a time.

We will increase the load like 1,2,3…100.

1 ,2,3,…what is the access time and response time..

Stress testing:

Exceeding the limits.

Response time and access time.

1,11,101,102 to know the breaking point

Volume testing:

It deals with data transfer..not about users and timing constraints.

When u r transferring huge amount of data from one server to another.


A -------b

Sending and receiving.

Soak testing:

To know the exact breaking point..we will do stress testing continuously over a period of time 24 or 48
hours.

Functional testing:

Done according to business requirements.

Smoke

Sanity

Integration

System

Regression

Uat

Usability testing:

Testing the look and feel of the application.

Customer will give checklist for usability.

Help menus,colours,alt tags or tooltips,font size,images ..etc.

Adhoc testing:monkey testing

Without writing any testcases just by giving valid and invalid inuts and checking the functionality.

Compatibility or portability or environmental testing:

Testing the application with different environments..os,browsers and servers.

Smoke tsting
Build verification testing BVT

.this is the initial type of testing on the application.

If build is not working properly in smoke testing,we will reject the build…saying it is not fir for testing.

..testing the critical features of the application.

.breadth level testing

Sanity testing:

Testing the pplication with minute details.

.after smoke testing

.depth level testing.

Recovery testing:

Forcing the application to crash and how fast it is recovering from the crashes.

.whether it is recovering automatically or human intervention is required?

.it is done for windows based applications.

TestCase design techniques Or testing techniques

1.error guessing:

Predicting the defects..based on experience and domain knowledge.

2.equivalence class partition: this is not a practical approach.

In this method we will divide the input into equivalent classes like

1 to 100

100 to 201

3.boundary value analysis:

BVA:
A a-1 a+1

1-1000

1,1-1,1+1

1000,1000-1,1000+1

.defect life cycle

Defect report format

Testplan

Simple sql queries

Defect Life Cycle:

How defect or bug propagates throughout testing activity?

1.when a tester finds or raises a new defect the status of the defect will be “OPEN”

2.this defect will be assigned to development lead through test lead

Now the status is “ASSIGNED”

3.now development lead will assign the job to concerned developer ..status is FiXED” ie debugging.

4.now tester will “REOPEN” th e defect to check whether fixed properly or not.

5.if the defect is fixed properly it will be “CLOSED”

Meanwhile we have sub statuses in “OPEN” status

They are:

1.not a defect:give sufficient proofs for the defect ..like snapshots,online meeting.

2.duplicate:if the same defect is raised twice..then it will be a duplicate.

3.RFE requirement for enhancement:

In the starting of the project customer will give same set of requirements to tester and dev.

If they want to add any features they will give directly to dev.about these changes dev team should
inform tt also.

4.will be fixed in the next release:

Some defect which is not critical,I cant fix in this release ..will be fixed in next release.

5.deferred:fixing of the defect is postponed uncertainly.

6.Not reproducible:
Good tester always reproduce the defects.

7.can not be fixed:using some rigid technologies we can not fix the defects at very later stage.

Defect Report:

After execution of testcases failed tc are the defects.

Defect id:

Detected by:

Assigned to:

Module name:

Release or version:

Severity:

Priority:

(severity is of four types:

Blocker or showstopper: ex:sign in not happening

Critical : some major module is not working.

Major:some important option is not working .ex:checkbox age

Minor:grammatical mistakes,font size,colours etc.

Depending on severity we will assign priority like p1,p2,p3,p4

Reproducible:y/n

Steps to reproduce:

Environment:

Attachements:

Screenshots,file,url

Standard documents for writing testcases:

1.crs customer requirement specification

2.srs
3.frs

4.use cases:

Pictorial representation of requirements.

Set of interactions between actor and his actions.

RTM:reuirement traceability matrix :

For example:customer gives 2000 req…how to ensure that all the req are covered in tc…

While reviewing they refer the original req spec and checks whether every rc has tc or not.

Mapping between req and tc. Is called as rtm.

Traceability matrix:

Total no of tc total no of executed tc passed failed reasons for failure reasons for non
execution

Test plan:

Is a document which describes whole testing activities.

Objective:

It writes about testplan itself.

What is the goal of test plan.

Scope:

In scope:features to be tested:

Out of scope:features not to be tested.

Approach:

Top down: starting from higher module to lower module

Bottom up:lower module to higher module.

.stub:dummy module used in top down

Driver:dummy module used in bottom up.

Configuration management:

Version control also.


It is used to maintain different versions of the e software.

There are cm tool like:

VSS visual source safe

Cvs concurrent version systems.

Rational rose

Non functional testing:

It checks the system how it operates than its behavior.

Ex:

Performance testing

Load stress and volume

Usability

Reliability

Functional testing:

Functional testing:

Smoke

Sanity

Integration

System

Rt

Uat

Database

Collection of data

Select:

Select * from orders

It will display total contents from the table “orders”

Select distinct customer_name,contact_number from customers

Select * from customers where city=”Mexico”


Select customers. Cust UPDATE Customers
SET ContactName='Alfred Schmidt', City='Hamburg'
WHERE CustomerName='Alfreds Futterkisteomername from customers where city=Mexico

Left

Right

Inner and outer joins

Customers first table

Orders second table

You might also like