Gcs day1

1. IT Job is No more a Dream
srikanthm@gcs.co.uk
Contact No.:07545863371

2. DAY-1
 Aims of the day
 Introduction
 About GCS
 Format of the Course
 Able to understand
 What is Testing
 Why Testing needed and importance of the Testing
 Testing Methodologies( Waterfall, V-Model and Agile)
 Designing a Test Plan, Test Strategy and Test case Documents

3. Introduction
 Background of Trainees and
Trainer
 Identify yourself
 About GCS

4. About GCS:
 New company with tie ups with Visa Section
 Placements Consultants
 Web development cell - UK
 Mobile Development Cell- India-2 resources
 Web Automation Cell(Company) – London – 3 in London
 Mobile Automation Cell – London
 Future plan to grow people in New castle in GCS
 Mobile Development and Testing
 Interview Preparation
 CV Preparation
 Projects – Live – Mobile and Web
 Experience if required in UK and India
 Internal Infrastructure development
I. JIRA
II. Live test Projects
III. Mail access
IV. Jenkins Access
V. SVN Access
VI. Selenium Grid
VII. VPN

5. Format Of the Course
 Manual Testing
 Agile Scrum Testing
 Java Training
 Automation Testing
 BDD Testing
 Mobile Testing
 Total 5 Weeks.
 Theory
 Project – is like real time
 Come to office at a specified time
 Work as a Team member
 Do testing Tasks

6. Manual Testing
 What are different kind of companies in Market
 Projects base- Microsoft- products
 Who is done in MS- 2-1
 Products – IBM – TCS
 Career growth – testing is always GREEN-
SAP/JAVA/ORACLE/WEB/.net – needs Testing

7. Manual Testing
 Introduction Of Testing
 What is Testing
 Software Testing is a process of evaluating a system by manual or
automatic means and verify that it satisfies specified requirements
or identify differences between expected and actual results.
• Who is a good tester
– Negative thinking
– Good communication
– Vision about technology and have to know better than a
developer(product knowledge)
• Why testing is required
– Complexity of code.
– Money(RBS)/health(software)/research and all applications
which are used by human should be tested to avoid
loss/problems.

8. 8
Who Tests the Software?
developerdeveloper independent testerindependent tester
Understands the systemUnderstands the system
but, will test "gently"but, will test "gently"
and, is driven by "and, is driven by "deliverydelivery""
Must learn about the system,Must learn about the system,
but, will attempt tobut, will attempt to breakbreak itit
and, is driven byand, is driven by qualityquality

9. Testing Methods
 Black Box Testing
The technique of testing without having any Knowledge
of the interior workings of the application is Black Box
testing. Eg. Functional Testing, UAT, Automation
 White Box Testing
White box testing is the detailed investigation of internal
logic and structure of the code. White box testing is
also called glass testing or open box testing
Eg. Unit testing
 Grey Box Testing
Grey Box testing is a technique to test the application
with limited knowledge of the internal workings of an
application. Eg. Inetegration tesitng, Database

10. Manual Testing
 How SDLC started
• When no IT- Productions depts.
Ex:- Bike- Bajaj
• Requirements- Design of bike- Production- QC- Release
• When IT came even IT used same Technique
• Water fall model – from Production Cycle-
– Kick Off- BRS
– Software Requirement Phase(SRS)
– Design Phase(Design Documents)
– Development
– Testing Process

11. Agile Testing(Manual Testing)

12. Waterfall Model
Testing

13. V-Model
• STLC
– We take the copy of SRS and BRS
– Create Acceptance test cases from BRS
– Create Test Plan from SRS
– Crested System test cased from SRS
– Created Integrations Test cases
– Create Unit tests from Developer
– Build is ready
– Execute Unit test cases
– Execute Integration test cases
– Execute System test ceases
– And Execute Acceptance test cases

14. V-Model

15. Test Documentation:

16.  Test Documentation:
Testing documentation involves the documentation of artifacts which should
be developed before or during the testing of Software. Documentation for
Software testing helps in estimating the testing effort required, test
coverage, requirement tracking/tracing etc. This section includes the
description of some commonly used documented artifacts related to
Software testing such as:
 Test Plan
 Test Strategy
 Test Scenario
 Test Cases
 Traceability Matrix
 Bug reports

17.  Test Plan:
A test plan outlines the strategy that will be used to test an application, the resources
that will be used, the test environment in which testing will be performed, the
limitations of the testing and the schedule of testing activities.
 Who Designs? --Quality Assurance Team Lead
Test Plan Includes:
 Introduction to the Test Plan document
 Assumptions when testing the application
 Features to be tested
 What sort of Approach to use when testing the software
 List of Deliverables that need to be tested
 The resources allocated for testing the application
 Any Risks involved during the testing process
 A Schedule of tasks and milestones as testing is started
 End of Day 1

18.  Day 2
 Test Scenario:
A one line statement that tells what area in the application will be tested. Test
Scenarios are used to ensure that all process flows are tested from end to
end
 Test Case
Test cases involve the set of steps, conditions and inputs which can be used
while performing the testing tasks. The main intent of this activity is to
ensure whether the Software Passes or Fails in terms of its functionality
and other aspects. There are many types of test cases like:
functional, negative, error, logical test cases, physical test cases, UI test
cases etc.
 Test case ID.
 Product Module
 Product version
 Revision history
 Purpose
 Assumptions
 Pre-Conditions.
 Steps.
 Expected Outcome.
 Actual Outcome.
 Post Conditions.

19. Test Case Template:
Test
Case
ID
Category Feature
Descriptio
n
Prerequisite Test
Desc.
Input
Data
Expected
Result
Actual
Result
Status
(Pass/Fa
il)
Defect
Id
Build
N0.
Comm
ents

20. Levels of Testing:
 Functional
 Non-Functional
 Functional Testing
 Unit Testing
 Integration Testing
 System Testing
 Regression Testing
 Acceptance Testing
Alpha Testing
Beta Testing
 Non-Functional Testing
 Performance Testing
 Load Testing
 Stress Testing
 Usability Testing
 Security Testing
 Portability Testing

21.  Traceability Matrix:
Traceability Matrix (also known as Requirement Traceability Matrix -RTM) is
a table which is used to trace the requirements during the Software
development life Cycle. It can be used for forward tracing (i.e. from
Requirements to Design or Coding) or backward (i.e. from Coding to
Requirements).
 The main goals for this matrix are:
 Make sure Software is developed as per the mentioned requirements.
 Helps in finding the root cause of any bug.
 Helps in tracing the developed documents during different phases of SDLC.

22. Bug Life Cycle:
What is Bug/Defect?
“A computer bug is an error, flaw, mistake, failure, or fault in a computer
program that prevents it from working correctly or produces an incorrect
result. Bugs arise from mistakes and errors, made by people, in either a
program’s source code or its design.
Life cycle of Bug:
Log new defect
When tester logs any new bug the mandatory fields are:
Build version
Submit On
Product
Module
Severity
Synopsis and Description to Reproduce

23. Types Of Bug Status:-
New
Deferred
Assigned
Resolved/Fixed
Could not re-produce
Need more Info.
Re-Open
Closed
Rejected/Invalid

24. Bug Fields
 SAMPLE BUG REPORT:
 Bug Name: Application crash on clicking the SAVE
button while creating a new user.
 Bug ID: (It will be automatically created by the BUG
Tracking tool once you save this bug)
 Area Path: USERS menu > New Users
 Build Number: Version Number 5.0.1
 Severity: HIGH (High/Medium/Low) or 1
 Priority: HIGH (High/Medium/Low) or 1

26. Home Work

27. THANK YOU
srikanthm@gcs.co.uk
Contact No.:07545863371