Gcs day1
27
-
Upload
sriram-angajala -
Category
Technology
-
view
18 -
download
1
Transcript of Gcs day1
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
Introduction Background of Trainees and
Trainer Identify yourself About GCS
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 ProjectsIII. Mail accessIV. Jenkins AccessV. SVN AccessVI. Selenium GridVII. VPN
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
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
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
Who Tests the Software?
developerdeveloper independent testerindependent tester
Understands the system Understands 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 to but, will attempt to breakbreak it itand, is driven by and, is driven by qualityquality
Testing Methods Black Box TestingThe 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 TestingWhite 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 TestingGrey Box testing is a technique to test the application
with limited knowledge of the internal workings of an application. Eg. Inetegration tesitng, Database testing.
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
Agile Testing(Manual Testing)
Waterfall Model
Testing
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
V-Model
Test Documentation:
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
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 LeadTest 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
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 CaseTest 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.
Test Case Template:Test Case ID
Category Feature Description
Prerequisite Test Desc.
Input Data
Expected Result
Actual Result
Status (Pass/Fail)
Defect Id
Build N0.
Comments
Levels of Testing: Functional Non-Functional Functional Testing
Unit Testing Integration Testing System Testing Regression Testing Acceptance Testing
Alpha TestingBeta Testing
Non-Functional Testing Performance Testing
Load Testing Stress Testing
Usability Testing Security Testing Portability Testing
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.
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 defectWhen tester logs any new bug the mandatory fields are:Build versionSubmit OnProduct Module SeveritySynopsis and Description to Reproduce
Types Of Bug Status:-NewDeferredAssignedResolved/FixedCould not re-produceNeed more Info.Re-OpenClosedRejected/Invalid
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
Assigned to: Developer-X
Reported By: Your Name
Reported On: Date
Reason: Defect
Status: New/Open/Active (Depends on the Tool you are using)
Environment: Windows 2003/SQL Server 2005
Home Work
