A presenetation on basics of software testing, explaining the software development life cycle and steps invovled in it and detials about each step from the testing point of view.

1. Software Testing
• What do you think software testing could be?
• Software testing is nothing but checking the quality of the
applicationsystem manually or by automating it to check whether
the actual result matches the expected result

2. SDLC
• Software Development Life Cycle is a step by step procedure to
develop a software and it consists of following phases,
 Requirements
 Feasibility study
 Designplan
 Coding
 Testing
 Installationdeployment
 Maintenance

3. SDLC Models
• Water fall model
• Spiral model
• Prototype model
• V and V model
• Hybrid model
• Agile methodology (mostly used)
Each will be dealt in detail

4. STLC

5. Black box testing
Testing the behavior of an application according to the requirement
specification is black box testing.
Types are,
Functional testing
Integration testing
System testing
UAT
Smoke and Sanity testing
Adhoc testing
Compatibility
Usability testing

6. Conti..
• Functional testing: Testing each and every component of the application.
• Integration testing: Testing the data flow between 2 modules or checking if interface
is happening between modules.
• System testing: Testing the end to end flow of an application.
• UAT: User acceptance testing is a type of testing done by customers before
accepting the product.
• Smoke: Testing the basic and critical features of an application.
• Adhoc testing: Testing the application randomly.
• Compatibility: Testing the functionality of an application across different SW and
HW platforms.
• Usability: Testing the user friendliness of an application.

7. Test Plan & Test Strategy
It is a dynamic document that drives the complete testing activities.
It consists of following attributes,
Objective: The aim of this test plan is to test functionality of the application.
Scope: It describes the features in scope and out of scope.
Approach: Flow of the application or process of testing the application.
The way we go about testing the Application in future,
 By writing high level scenarios
 By writing flow graphs
Testing methodologies: Types of testing to be performed.
Assumption: Is if any TE leaves the company is between the project.

8. Conti…
Risk: The quality of that module or testing of that module may be
delayed or affected.
Contingency or mitigation plan: To avoid the above risk we can have
primary & contact for every module that is tested.
In the absence or primary contact, secondary contact should take care
of the module. It’s a back up plan prepared to avoid the assured risk

9. Conti…..
Estimation: How much time required to test,
Effort estimation techniques,
1. Work break down approach
2. Use case based
3. Delphi technique
4. Based on functional point
5. Based on kilo lines of code
Schedules :This section contains – when exactly each activity should start and
end? Exact date should be mentioned and for every activity, date will be
specified.
Roles & responsibilities:
• Role of a team members and lead.

10. Conti…..
Templates: Contains all the templates for the documents which will be used in the
project. Ex:
• Test Case
• Traceability Matrix
• Test Execution Report
• Defect Report
• Test Case Review Template
Automation: Details of automation testing to be carried out.
Defect tracking tool: Details of tool used for defect tracking.
Test deliverables: It is the output from the testing team. It contains what we will
deliver to the customer at the end of the project.
Entry and Exit criteria: Criteria for each testing level to enter next level.

11. Test Strategy
 It is a document which captures the approach on how we go about
testing the product.
 We can call Test plan as the parent document and Test Strategy as
the child document.
 It again depends on the process followed by company.

12. Test Scenarios and Test cases
Test scenario is a high level document which consists of all possible
ways or combinations of testing the application.
Points to be remembered while writing scenario could be,
 Every scenario should be simple and understandable
 Each scenario should be written in 1 or 2 sentences
 Every scenario should have “Do’s” and “check’s”.
 All the scenario should be in proper order or sequence

13. Examples of test scenarios
CUP
 Check it can properly contain liquid and not leaked.
 Test that its size and shape as per user requirement or not.
 Test its color as per user requirement or not.
 Test its material as per user requirement.
 Test it with maximum hot/cold and minimum hot/cold liquid.
 Check its strength that whether it can be broken easily.
 Check its with heat and cold environment.
 Put it in front of direct sun light for hours.

14. Test Case
It is in detailed step by step procedure to test the application which consists of
the navigation steps and all the inputs.
 Types of test case:
High level Test cases are those which cover major functionality in the
application (i.e. retrieve, update display, cancel (functionality related test
cases), database test cases).
Low level test cases are those related to User Interface (UI) in the application.
Advantages of test cases
 To have Maximum test coverage.(all the test cases are covered)
 To have better test consistency.
 Testing depends on process rather than person
 Time saving.

15. Examples
Examples of writing test cases according to the type,
1. Login functionality: write for functional, integration and system
testing.
2. Gmail inbox

16. Test case design techniques(TCDT)
TCDT is the way to define the test data.
There are mainly 3 types,
 Error guessing
 Equivalence partitioning
 Boundary value analysis
• Error guessing: In this the TE keeps guessing the value based on his
understanding.
• Equivalence partitioning: If the inputs are range if values then derive
the test case for 1 valid and 2 invalid data.
• Boundary value analysis: Values are derived like this, if (a,b) then
data will be a, a+1, a-1,b, b+1,b-1.

17. Defect life cycle

18. Different statuses of bug
1. Invalid rejected: the reason for getting invalid bug could be,
 TE has misunderstood the requirementdev misunderstood
 TE dev referring to the old req
2. Duplicate: name itself says duplicate bugs
3. Not reproducible: unable to reproduce the bug when dev tests it
Reasons:
 Improper bug report
 Environment mismatch
 Data mismatch
 Build mismatch
 Inconsistent bug
4. Wont be fixedcannot be fixed:
No technology support, bug is in the core of the application, fixing of bug is
costlier than retaining it.

19. Conti…
Postponeddeferred :
5. Request for enhancementQA suggestion

20. DefectBug report
Points that need to be considered while Reporting bug,
 Module
 Requirement number
 Test case name
 Status
 Assigned to
 Author
 Test data used
 Environment: Browser and OS information.
 Severity and priority
 Brief description of the defect
 Steps to reproduce the defect
 Observationactual result
 Expected result
 Attachments

21. Severity and Priority
• Severity: impact of bug on the application
• Priority: which bug to be fixed first
Write examples for,
• High severity high priority: blocker bugs
• High severity low priority
• Low severity high priority
• Low severity low priority: UI issues

22. Regression Testing
• Re-executing the old test cases across multiple releases or builds to
make sure that changes has not affected the existing functionalities
is called as Regression testing.
Types of Regression testing,
1. Unit regression testing
2. Regional regression testing
3. Full regression testing.

23. Conti…..
• Unit Regression Testing: re-testing that fixed bug or feature(no
impact area)
• Regional Regression Testing: testing new feature and the impact
area.
• Full Regression Testing: testing new feature and plus the
complete old features.
Impact area can be found based on the impact analysis which is done
at the very early stage when we get the requirements.

24. Exploratory Testing
• When there are no proper requirements or when requirements are
not clear we go for Exploratory Testing.
 Explore the application.
 Understand the application.
 Document the understanding in terms of TC’s and Test Scenarios.
 Then test the application accordingly to the documents is called as
Exploratory testing.

25. Build, Patch, Release
• Build: is a piece of software that contains set of features, bug fixes
& installed onto the test server which needs to be tested for stability.
 Each new build is a modified version of previous build.
 Test cycle: it is the time duration taken to test each build.
• Patch: is a small piece of code which acts as an immediate fix for
any kind of blockers issues so that test engineer can proceed with
his testing without any time delay.
• Release: is a software that contains complete set of features which
are developed, tested & once these featured are stable it is handed
over to the customer.

26. Any Questions