SOFTWARE TESTING

It is the process of correction of the applications which give QUALITY product which should
meet user/customer/business needs.

We are not manual tester WE ARE QUALITY ANALIST

WHY WE REUIRE SOFTWARE TESTING?

1) What we expect should come.

2) Application behavior varies from one to many.
3) Application should work irrespective or devices /browsers/operating systems.

WHY WE HAVE DEFECTES IN THE APPLICATIONS?

1) Time pressure
2) Unskilled resources
3) Miss _communications between teams.
4) Charge request (CR).

TYPES OF SOFTER WARE TESTING:

Manual testing Automation testing

We will write Test cases to execute the We will write Test Script to execute the
application. application.

PROCESS IN MANUAL TESTING:

1) Test requirements : user need Docs

2) Test Planning: resources, problems, NO. Of persons required.
3) Test Designing: how to write test cases / test scenarios, numbers
4) Test verifications/ Execution: developer application and test application different are
equal to customers requires
5) Test close activates: process of test starting to end, how many defects are found and
many solved. How many days it completed.
>>>>TEST ARTIFACTS:

Test Basics:
>>Or Test Requirements
* A documents which focus on user needs.
* Information needed in order to start test process.
* Well defined and adequate information.

>>Test Case Specification:

 Exact set of inputs required to design test cases.
 They are two categories: Test scenarios and Test cases.
 Test scenarios: verify uses journey or check the functionality or an application

Example:

Go to office:

At what time u started: 9 Am----------TC01

At what time u reached: 10:0 Am-----TC02
Time taken: 90 minutes-----------------TC03
Any traffic: no----------------------------TC04
Distances: 50 KM-------------------------TC05

 Test Cases:

It specifies inputs, steps, process, and it contains few set of attributes.

Attributes in test cases:

Example:

Graduation projects hard copy: Attributes:

Roll no ID: Test ID:

Project name: Test case name:
Abstract: Test case description:
Index Test design steps:
Chapter details Test design description:
Expected results Expected results:

Example:
Test requirements ---->>> Test plan--.>>>Test scenarios-->>>>>>>> Test cases
CREATE GMAIL FOR A NEW USER:
1) FIRST NAME
2) LAST NAME
3) USER NAME
 4) PASSWARD AND CONFORM PASSWARD
5) DOB
6) COUNTRY
7) PHONE NUMBER ect,,,,,,

## TEXT BOX
## RADIO BUTTON
##SELECT BOX
##DORP BOX
##LINK
##BUTTON

User Details ( Test Scenario 1)

FIRST NAME ---------------TC01

LAST NAME -----------------TC02
USER NAME -----------------TC03
PASSWARD ------------------TC04
CONFIRM PASSWARD ----TC05
NEXTBUTTON----------------TC06

Personal Details(Test Scenario 2)

COUNTRY ---TC01
PHONE -------TC02
RECOVERY---TC03
DOB----------TC04
GENDER-----TC05
NEXT---------TC06

DAY 3

>>> Test Process in software testing:

1) It is a process either than a single activity.

2) Quality and effectives of an application is depends process follows.

Phases:

# Planning and Control:

- Objectives and scope of testing (Planning).

- Deviation in the planning will do controlling.
 # Analysis and Design:

- Review and Analyze user documents(Analysis)

- Preparation Test Design Activities (Test Scenarios and Test Case writing).

# Implementing and Execution:

- Test data preparation and Migration of Developer code to QA Environment.

- Test the application by comparing actual results (Application) with Expected results
(Test cases).

# Evaluating Exit criteria and reporting

- We will check the exit criteria report in all phases.

ENTRY CRITERIA PROCESS EXIT CRITERIA

User ideas -->>TEST REQUIREMENTS -->> Test required document

Test required document --->> TEST PLANNING ->> Test planning documents

Test required document --->> TEST DESIGNING --->> Test scenarios and
Test cases prepared

Test scenarios and test cases prepared--->>TEST EXECUTION--->test executions report

Test executions report ---->> TEST CLOSURES --->>>Test report

# Test Closure Activities:

- Generate the report to show how test process has been done.

>>>STLC (Software Testing Life Cycle)

It deals with test related activities.

_ Phase:

# Test Requirements:

- Here it contains user expectations.

- If QA team has any questions, will be answered by BA(Business Analyst)
- Different comprise will call requirements as :-
(Used in NON Agile) > BRD (Business Required Documents)
(Used in NON Agile) >SRS (Systems Requirements Specification)
 (Used in NON Agile) >FRD (Functional Requirement Documents)
(Used in NON Agile) > User Manual
(Used in NON Agile) >User Cases
(Used in NON Agile) >Excel sheets (Smaller organizations will use this.
(Used in Agile)>>>>>User stories

#Test Planning:

- Here estimation of the project will be discussed.

- Necessary information, scope, objectives, risks, team role, and responsibilities

#Test Designing:

- Will write test scenarios and test cases.

- Test data is also considered

#Test Execution:

- Execution the application by comparing actual results with expected results

- If any deviation from the actual results for expected results , then the text cases
should be failed , this information send to developer team
- Else expected result equal actual results, then the corresponding test cases is
”PASSED”

#Test Closure Activities:

- Here the QA team generate test reports to show how test reports process as be
implemented.
- Other name test reports
o TEST SUMMARY REPORTE.
o TEST CLOSER REPORTS
o TEST STATUE REPORTS
o TEST POST MORTEM REPORTS

WHEN TO STOP TESTING?

- When given product meets user exceptions.

- Any no update is as per needs.
- When projects got cancelled.
DAY 4

>>>SDLC (SOFTWARE DEVELOPMENT LIFE CYCLE)

- Develop team
- QA team
- Stake holders
- BA
- Maintains team

It is aimed to provide defining, designing, developing and gives a quality product which
needs user expectation.

Phases in SDLC:

1) System planning.
 Important phase to create a system.
 Here all team members will brainstorm on user needs.
2) System defining
 Definition of the system will be done.
 Reference documents will gives user needs will be prepared here.
3) System designing
 Architectural design of the system will be prepared here by Dev team.
4) System implementation.
 Actual code of the system will be prepared /developed by Dev team.
5) System testing.(STLC)
 Here QA team will perform test on the application which is give by Dev.
6) System maintenance.
 Support team will support the application for a given period of time

TYPES OF SDLC:

1) Waterfall Model or Linear Sequential flow.

 Each phase implements one after other.
 Easy and well know model in SDLC.
 Easy to understand.
 ADVANTAGES DISADVANTAGES

 Easy to understand. > Not suitable for larger projects

 Easy phase has its own deliverables. > High Risks.
 Suitable for smaller projects. > Dependency phases.
 No back phases

DAY 5

2) V-Model.
 V-model is a sequential flow.
 V-model for verification and validation.
 In v-model, UAT test cases will be prepared at initial stage where UAT will be done
before shipping product to customer
 Unit testing well be done at coding to leakage defects to further stages

Advantages and disadvantages will be similar to waterfall.

 3) ITERATIVE MODEL.
 Iterative time period will be 1 to 4 weeks.
 Any requirement can be added in the middle of the phase.

Advantages Disadvantages

1) Suitable for larger projects 1) it requires skilled resources.

2) Progress can be measured. 2) Not suitable for smaller projects
3) Resource utilization. 3) Management ricks
4) Risks will be low.

4) SPIRAL MODEL.
 Spiral is a combination of waterfall and iterative models.
 It is a incremental method of implementing phases

Disadvantages:

Spiral may go infinity.

 Same as waterfall and iterative models.

 5) BIG BANG MODEL:

 It is model which contains any process document.

 User may not know what his actual needs.
 User may not get his end product.
 User deals with time and money.
 Smaller organization will use this model.
 Very poor model in SDLC.

DAY 6

AGILE: (moving in a smarter way, implementing effectively).

 Here we closely interact with customers.

 Here we are trying to learn about customer needs, which gives clear
understand of his expectations.

AGILEMETHODS:

1. SCRUM(95% Used by real time projects)

2. KANBANN
Agile Management Tools:

1. RALLY(CA Technologies)
2. JIRA(it has trailer version, low cost )
3. TFS(Microsoft, trailer, version, low cost)

SCRUM:

Development product should be divided into small part. Each part is in ready to use
customer.

Product Backlog:

 It contains US stories implements for all the sprints.

Sprint Backlog:

 It contains US implements for the current sprint.

Sprint backlog/ sprint 1:

 US-456
 US-xyz
 US-123
 US-check

For sprint backlog owner is SCRUM MASTER.

SCRUM Master: roles

 Take care about this team SCRUM(DEV&QA)

 Removes miscommunications between teams.
 Protects his team.
 Implement agile in effective manner.
 Can’t be technical.

SCRUM METHOLOGIES:

 Product backlog.
 Sprint backlog/ sprint planning
 Scrum meeting / daily standup calls (DSC)
 Demos/review meetings.
 Retrospective meetings.
SPRINT PLANNING (D1, 3Hr):-

 US assignments.
 User points assignments to US.
 Hour’s allocations.

USER POINTS:

1, 2, 3, 5, 8, 13. (POKER CARD METHOD).

SCRUM Meeting (D2 15mins):-

Daily status of team, what you have done yesterday, what is your plan on today?

DEMO/ REVIEWS:

QA team will send a mail (office) to DEV with evidences to accept the US. US will be
accepted by DEV.

RETROSPECTIVE MEETING (D10, 3Hr):

 Thing went well.

 Things don’t go well.
 Things need to be updated.

Important points to remember to INTERVIEW:

 There is NO project manager /QA/DEV/MANAGER in Agile.

 There is NO test cases/Req. documents involved in Agile.
 You are not a manual tester in Agile proud to be QA.

Product owner

Roles and responsibilities:-

 Define the US and prioritize them

 Sprint duration (normal 1-4 weeks).
 Can be client take care about project timeline.

DAY 7

TESTING LEVELS / LEVELS OF TESTING

Functional Levels Non –Functional Levels

It deals with functional requirements. It deals with nonfunctional requirements.

1. Unit testing. 1. Performance testing.

2. Integration testing 2. Security testing.
Top bottom approach 3. Load testing
Bottom up approach 4.stress testing
Sandwich approach. 5. Compatibility testing.
Big bang approach 6. Usability testing
3. System testing/functional testing/black box method.
4. System integration testing
5. UAT(user acceptance testing)
Alpha
Beta
6. Regression testing
7. Smoke testing
8. Sanity testing
9. E2E testing

1. UNIT TESTING:
Checking smaller components of an application.
Done by: Method
Developer White Box Method
QA
2. INTEGRATION TESTING:
Checking the communication/interaction/ integration between two or more
components in an application.
Done by: Method
Developer White Box Method
QA
i. Top bottom approach:
Checking the application from top to bottom components by considering
higher levels first.
ii. Bottom up approach:
Checking the application from top to bottom components by considering
lower levels first.
iii. Sandwich approach:
It is combination of both top bottom and bottom up approach.
iv. Big bang approach:
Considering all components at once.
3. SYSTEM TESTING:
Checking the system as a whole.
Done by method
QA black box method
4. SYSTEM INTEGRATION TESTING:
Checking The Communication /Interaction Between Two Or More System.
5. UAT(user acceptance testing )

It is done before shipping the product to customers. User involves to accept/reject

the product.

ALPHA TESTING: user will go to developer site and check the product.
 BETA TESTING: Product should be sent to user to check. User will have
separate UAT team to check the product.

DAY8

6. SMOKE Testing:
If application launches at initial stage it will have major issues.
Check the critical functionalities in the application.
7. SANITY Testing:

After may releases of an application, if any new change happened, will focus on
the new change.

It can have many regression happens.

 8. REGRSSION Testing:

If any new code (new req, defect fix) added to the application it can side effect the
components associated with this change.

To check whether the side affected components are working fine or not will do regression.

RETESTING:

If developer gives the code fix for failed test CASES (QA member will raised it), QA
member have to check the code fix is working fine or not.

Different between REGRSSION AND RETESTING

RETESTING REGRSSION

It starts before regression. It starts after retesting

It works failed test case. It works on multiple passed test cases.

It prefers manual testing. It prefers Automation.

It is priority to regression. It depends on resources availability.

 9. E2E TESTING/CHAIN TESTING:
Testing all applications which are involved in the product. It involves
backend and front end application also.
It starts checking from start to finish point.

SYSTEM TESTING END2END TESTING

It focuses on system behavior. It focus on both backend and frontend approach.

It starts before E2E. It starts after system testing.

It considers manual and automation. It prefers manual testing.

It goes for integration levels also

DAY-9

TESTING METHODS/METHODOLOGIES:-

1. Black Box Method

Testing the application without know the internal code/structure of the
application.
 QA will act as USER
 QA doesn’t know how code has been processed.
 QA will check the outputs for their corresponding inputs

ADVENTAGES DISADVENTAGES

* No need of skilled resources. *the coverage issue while doing it

*used for larger input systems. *we won’t get the desired output.
*QA will act as USER
 2. White box method/CLEAR BOX/OPEN BOX
 testing the application by considering the internal code logics
 QA will know how internal code work.
 QA will act as “DEVELOPER”

ADVENTAGES DIS ADVENTAGES

*QA will get desired output. *Required skilled resources.

*Accuracy in output. * not suitable for large systems
*Code optimization. * Each and every phase can’t be checked
TYPES:
1. UNIT TESTING LEVEL.
2. INTEGERATION TESTING LEVEL.

3. Grey Box Method

 It is the combination of Black Box and white Box Methods.
 QA will have limited access to see the internal code.
 QA will act as both USER and DEVELOPERR.

*Major disadvantages: QA will have limited to see the code.

DAY-10

Testing Techniques/Design Techniques/Techniques/Testing Case Techniques:

 In order to optimize the number test cases for a given input.

 It focus on maximum test coverage.

TYPES:

1. Equivalence Partioning.
*for a given input we are going to divide into equal/not equal pations/parts by
considering valued and invalided condition.
2. Boundary Value Analysis.
 Will only at boundary conditions only.
We have default BVA values:

 - Min
 +Max
 Normal
 -Max
 +Max
3. Decision Table/Cause effect table:
If user requirements are complex will use Decision Table.

4. Orthogonal Array:
 For given input we are going to consider test cases by permutatutions and
combination.
Day 11

DEFECT MANAGEMENT:

1. Defect : Issue deviated from expected results.

DLC(Defect Life Cycle)/BLC(Bug Life Cycle):
DAY -12

DEFECT MANAGEMENT

Defect will be classified into two:

1. Priority.
2. Severity.

1.Priority:

How fast developer needs to fix the defect.

2. Severity:

Degree of impact on the system (or) How bad is the defect.

Priority Severity

How fast DEV needs to fix. How bad on the application,

Status: Status:

LOW CRITICAL

MEDIUM MAJOR

HIGH MODERATE

MINOR

COSMOTIC

It is on the schedule. It is depend upon the functionality of application.

It derived from user values it is derived from system values

It will be decided by user it will be decided by QA team.

It identifies at UAT It identifies at system testing.

HIGH PRIORITY AND LOW PRIORITY

1. LOG of the company. REEBOK----REEDOK

2. ATM DISPLAY MESSAGES
Open account before 25th Dec xxx and get 10% annual interest
 Dec 24th—valid
 Dec25th-----valid
  Dec26th----valid error
3. MOBILE ALERT MESSAGE FROM ATM IS INCORRECT

LOW PRIORITY AND HIGH SEVERITY:

1. I have three boxes: first name .last name and middle name here when I enter exact
250+250+250 text in this three text boxes, browser closes and application shut down.

HIGH PRIORITY AND HIGH SEVERITY:

1. Data Base Front Application Server Issues

LOW PRIORITY AND LOW SEVERITY:

1. Cosmetic Issues> Text Color And Text Style….. etc