1 / 18

Requirements review, Test Case design, Bug reporting Practice session

Requirements review, Test Case design, Bug reporting Practice session. Iana Mourza Sr. Quality Engineering Manager, VMware, Inc. 2007-2016. Homework for this class. Testcase creation – create as many test cases as you can think of. Application to test. Applicaton:

sarahdennis
Download Presentation

Requirements review, Test Case design, Bug reporting Practice session

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements review, Test Case design, Bug reporting Practice session Iana Mourza Sr. Quality Engineering Manager, VMware, Inc. 2007-2016

  2. Homework for this class Testcase creation – create as many test cases as you can think of

  3. Application to test Applicaton: Class Search page at ianacoach.com is a web-based online form created for searching through the catalog of proposed classes. URL: http://www.ianacoach.com/qa_web/class_search_qa_page.html

  4. Requirement Review General Requirements: 1. Search classes page should allow perspective and existing students to search through the classes by: Class ID Class Title Class Type Class Dates Class location (state) Class location (city) (based on selected state) Zip code Enrollment status 2. The page should support results ranges from 10 to 100 per page. 3. Users should be able to save results into a text file and/or print it out.

  5. Requirement/Spec Review Detailed Text Field Specification: Search Classes panel: Class ID: unique identifier of the class. Text field, digits only. No more than 20. Optional field. Class Title: text field, accepts all characters. No more than 40. Optional field. Class Type: Drop down list. Choices: Group session, Individual session, All. Required field. Defaults to “All”. Class Start date: date range for class search. Date in MM/DD/YYYY format. Required field. Defaults to the current year (Jan 1st to Dec 31st) Class End date: date range for class search. Date in MM/DD/YYYY format. Required field. Defaults to the current year (Jan 1st to Dec 31st) Class location (state): list box offering the list of all 50 US states. Optional field. Class location (city): List Box offering the list of cities based on the state selection. Optional field. ZIP code: text field, accepts 5 characters (digits only). Optional field. Enrollment Status: drop down list. Choices: All, Open, Wait List. Required field. Defaults to “All”.

  6. Requirement/Spec Review Detailed Text Field Specification: Results table should contain the following columns (non-editable): Class ID Class Type Class Title Class Start date Class End date Enrollment Status Class Frequency Class location (state) Class location (city) ZIP code Enrollment status The last column of the table should have “Enroll” button. Button should be enabled for classes in status “Open” and “Wait list”, and disabled for classes in status “Full”.

  7. Requirement/Spec Review UI Specification:

  8. Testing Web forms • Start with positive testing first. • Required Fields: • - Each required field has an asterisk (or other visual indication that the field is required) • - Error message provided if required field has no input • 2. Data Retained in Database - test for each field • -correct address, name etc. • correct data for each field • 3. Values in lists: • one value represents the entire list - try just one • make sure values are consistent • make sure values are complete (compare with similar services). • make sure "Other"/"None"/"Less than"/"Over" is present when applicable - negative test case - assign nothing - get the error message

  9. Testing Web forms (cont’d) • 4. Controls: • - identical controls in different forms are consistent (look, name, behavior) • Checkboxes/radio buttons • Drop-down lists • Various buttons and text boxes • have reasonable initial values • consistent fonts, proper grammar and punctuation for strings/text values

  10. Testing Web forms (cont’d) • 5. Edit/Text Boxes: • Capacity Testing (5 test cases) • Valid/Invalid Input (3+ test cases) • ZIP CODE (digits only, 5-digits only) • Phone Number: No letters, No special Characters (possible exceptions: dash, round brackets, dot, space). 10 digits (11 if begins with one). Might have 3 edit boxes per number. • EMail (accepts letters, digits, some special characters - @ . - _ ) • are wild cards accepted? • DATE field needs validation for month (01-12), day (01-31), year (1900 - current) • TIME needs validation for minutes (00-59), hours (00-23), seconds (00-59)

  11. Testing Web forms (cont’d) • 6. Data Input Rules: • - use Lists whenever possible versus text boxes • - calculate rather than ask for input (for example: calculate county by ZIP) • - functionality/Validation • 7. Exception handling: • - messaging • - data loss

  12. Test Case Design Test Case Creation (Lab exercise): Analyze the requirements and create as many testcases as you can. Record testcases into excel spreadsheet.

  13. Test Case Execution Test Case Execution (Lab exercise): Execute the testcases you created in Test Case Creation lab and mark results in the spreadsheet.

  14. Bug Reporting Bug Reporting (Lab exercise): Report two (selective) bugs found in Test Case Execution lab into: http://elementool.com

  15. Bug Reporting Bug Reporting (Lab exercise – con’d): Create various test/bug reports: http://elementool.com

  16. Software documentation • PRD (Product Requirement Document) • What: set of software requirements • Who: Product Marketing, Sales, Technical Support • When: planning stage • Why: we need to know what the product is supposed to do • QA role: • Participate in reviews • Analyze for completeness • Spot ambiguities • Highlight contradictions • Provide feedback on features/usability

  17. Software documentation • FS (Functional Specification) • What: software design document; • Who: Engineering, Architects; • When: (planning)/design/(coding) stage(s); • Why: we need to know how the product will be designed; • QA role: • Participate in reviews; • Analyze for completeness; • Spot ambiguities; • Highlight contradictions.

  18. Software documentation • Test Plan • What: a document describing the scope, approach, resources and schedule of intended testing activities; identifies test items, the features to be tested, the testing tasks, who will do each task and any risks requiring contingency planning; • Who: QA; • When: (planning)/design/coding/testing stage(s); • Why: • Divide responsibilities between teams involved; if more than one QA team is involved (ie, manual / automation, or English / Localization) – responsibilities between QA teams ; • Plan for test resources / timelines ; • Plan for test coverage; • Plan for OS / DB / software deployment and configuration models coverage. - QA role: • Create and maintain the document; • Analyze for completeness; • Have it reviewed and signed by Project Team leads/managers

More Related