Test Case Training

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

12 comments

Comments 1 - 10 of 12 previous next Post a comment

Comments 1 - 10 of 12 previous next

Post a comment
Embed Video
Edit your comment Cancel

18 Favorites & 1 Group

Test Case Training - Presentation Transcript

  1. Manual Test Script
  2. Agenda
    • Software Testing - Introduction
    • Testing Techniques and Testing Strategy
    • Test Plan and Test Case
    • Test Case design Techniques
    • Test Case Format
    • Integration Test Cases
    • Guidelines for Test Cases
    • Improving testability
    • Test case review check list
    • Q/A
  3. Introduction
    • What is Software Testing?
    • Software testing is a process of analyzing or operating software for the purpose of finding bugs
    • The word “process” is used to emphasize that testing involves planned, orderly activities
    • Testing cannot show the absence of defects, it can only show that software defects are present
    • Why is Software Testing Required?
    • To find defects
    • To ensure that it meets user requirements
    • To reduce cost of quality by delivering defect free product
    • To achieve customer satisfaction
    • Continuously improving test process
    • Reduce risk of software failure
    • To determine the state of software
  4. Testing Techniques
    • Testing Techniques
    • Black - Box Testing In using this strategy, the tester views the program as a black - box, tester doesn't see the code of the program: Equivalence partitioning, Boundary - value analysis, Error guessing, AdHoc Approach.
    • White - Box Testing In using this strategy, the tester examine the internal structure of the program: Statement coverage, Decision coverage, condition coverage, Decision/Condition coverage, Multiple - condition coverage
  5. Test Plan and Test Case
    • What's a 'test plan'?
    • A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it
    • What's a 'test case'?
    • A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results
    • Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it's useful to prepare test cases early in the development cycle if possible
    • Test Case can be of Two type I.e. Positive Test case and Negative Test Case
  6. Test Case Design Techniques
    • Boundary Value Analysis - A data selection technique in which test data is chosen from the “boundaries” of the input or output domain classes data structures and procedure parameters. Choices often include the actual minimum and maximum boundary values the maximum value plus or minus one and the minimum value plus or minus one
    • Boundary Value Analysis: If Valid Input is 100
    • Boundary + 1 = 101
    • Boundary Value = 100
    • Boundary – 1= 99
    • Equivalence partitioning – Divide the input domain into classes of data for which test cases can be generated. Attempting to uncover classes of errors. Based on equivalence classes for input conditions. An equivalence class represents a set of valid or invalid states An input condition is either a specific numeric value, range of values, a set of related values, or a Boolean condition. Equivalence classes can be defined by:
      • Equivalence Partitioning: If Valid Input is in the Range of 10 and 15
      • Invalid Below the Partition = 8
      • Valid In the Partition = 12
      • Outside of the Partition = 18
    • Error Guessing - Its testers experience to test the functionality creating such a data which may cause failure. – Feb 29, 2001
      • Boundary value analysis and equivalence partitioning are inevitably linked together
  7. Test Case Format Test Case and Test Scenario Format
  8. Integration Testing
    • Integration testing is the most crucial steps in Software Development Life Cycle. Different components are integrated together and tested. This can be a daunting task in enterprise applications where diverse teams build different modules and components.
    • Prerequisites for Integration Testing
    • Before we begin Integration Testing it is important that all the components have been successfully unit tested.
    • Integration Testing Steps
    • Integration Testing typically involves the following Steps: Step 1: Create a Test Plan. Step 2: Create Test Cases and Test Data. Step 3: Once the components have been integrated execute the test cases. Step 4: Fix the bugs if any and retest the code. Step 5: Repeat the test cycle until the components have been successfully integrated.
  9. How to write an Integration Test Case?
    • Simply put, a Test Case describes exactly how the test should be carried out. The Integration test cases specifically focus on the flow of data/information/control from one component to the other.
    • So the Integration Test cases should typically focus on scenarios where one component is being called from another. Also the overall application functionality should be tested to make sure the app works when the different components are brought together.
    • The various Integration Test Cases clubbed together form an Integration Test Suite Each suite may have a particular focus. In other words different Test Suites may be created to focus on different areas of the application.
    • Integration Test Cases should be as detailed as possible.
    • Integration test case should include Name of Main Module , Name of Sub Module and Respective Dependency , Name of Function which is calling or get called , name of Database tables which will get affected after Saving offshore.
  10. Guidelines For Writing Manual Test Cases/Scenarios
    • Guidelines For Writing Manual Test Cases/Scenarios
    • The First component in the Scenario/Test Case ID should be the type of testing for which the Scenario/Test Case is being written.
    • The Second component in the Scenario/Test Case ID should be Module Name/ Module Name–Sub Module Name
    PT Performance Test Case IT Integration Test Case ST System Test Case Notations Types of Test Cases SA_ACT Accounts SA Subagent BO_RPT Reports BO_ADM Administration BO BackOffice Sub Module Name Notation Module Name
  11. Improving Testability - Language
    • Testability = easy to test
    • Use active case, do this, do that
    • System displays this, does that
    • Simple, conversational language
    • Exact, consistent names of fields, not generic
    • Don’t explain Windows basics
    • 10-15 steps or less. In the case of integration test case’s try to provide references instead of explaining the functionality again and again.
    • Always updated your test cases along with new build.
    • Always maintain a Data table.
  12. Object Naming Conventions
    • Module Names should be in all capitals and bold. E.g. to mention BackOffice Module in the Scenario/Test Case, usage should be “BACKOFFICE”.
    • Screen Names should be bold and have Camel Notation, i.e. the first letter of the word in Capitals and rest in Small letters. If there are multiple words in the screen name, then the 1st letter of all the words should be in Capitals and the rest of the word in small letters.
    • i.e. for Agent Detail screen name will be “Agent Details”
    • All the objects like Text Box, List Box, Check Box, Radio Button, Combo Box names should be in italics and bold.
    • i.e. Login Text box should be mentioned as Login .
    • The Link Names should be mentioned with an Italics, bold and underline below the word.
    • i.e. Sign out link will be named as Sign Out .
    • Database table name should be in Caps
    • I.e. for Emp_Detail table name will be EMP_DETAIL
  13. General Guidelines
    • All the Scenario/Test Case should be easily understandable, clear, concise and to the point.
    • The pre-requisite for the Scenario/Test Case should be mentioned before the test cases.
    • The Scenario/Test Case for different module should be maintained in a single Worksheet in an Excel File. The Name of the Excel File should be -
    • TypeOfTesting_ModuleName.xls I.e. ST_BackOffice.xls
    • Whenever new Scenario/Test Case is been added in between two existing one it should be named after the previous Scenario/Test ID with decimal places.
    • I.e. If we have to add new Scenario in between scenario ID ST-SA-BKG-0015 and ST-SA-BKG-0016, then new scenario id will be ID ST-SA-BKG-0015.1 and so on.
    • Defect ID of a Scenario/Test Case should match the Defect ID submitted against that defect in Defect Tracking System/Excel file.
    • Traceable - to a requirement
  14. Test Case Review Check List
    • All the test cases should reviewed at least once and checklist should be filled by respective person.
    • General Points of a Review Check List:
      • Test cases follow agreed standard format.
      • The Test cases are complete with respect to the Specifications Document on which they are based.
      • Test data is mentioned explicitly for each test condition.
      • 'Expected result' section of each test case is complete
      • Pre-conditions for executing a test case or a set of test cases are specified.
      • It is specified which test cases are to be executed together (or in a specific order).
      • Test cases cover the entire functionality of the integrated module.
      • There are test cases for checking the integrity of the global variables or database being accessed.
      • Test cases follow the order of integration as defined in the HLD document or test plan.
  15. Best Practices Q/A Thank you

+ abcabc, 3 years ago

custom

13984 views, 18 favs, 3 embeds more stats

More info about this document

© All Rights Reserved

Go to text version

  • Total Views 13984
    • 13936 on SlideShare
    • 48 from embeds
  • Comments 12
  • Favorites 18
  • Downloads 1288
Most viewed embeds
  • 44 views on http://gurpreetblogs.blogspot.com
  • 3 views on http://www.gurpreetblogs.blogspot.com
  • 1 views on http://natyuken.slideshow.com

more

All embeds
  • 44 views on http://gurpreetblogs.blogspot.com
  • 3 views on http://www.gurpreetblogs.blogspot.com
  • 1 views on http://natyuken.slideshow.com

less

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

Cancel
File a copyright complaint
Having problems? Go to our helpdesk?

Categories

Groups / Events