Your SlideShare is downloading. ×
0
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Testing artifacts   test cases
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Testing artifacts test cases

7,121

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,121
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Testing Fundamentals Module 1: Introduction into Software Testing Software Testing Artifacts
  • 2. Software Testing Artifacts Test Cases2 ® 2011. EPAM Systems. All rights reserved.
  • 3. Software Testing DefinitionTest Case – a set of test inputs, execution conditionsand expected results developed for a particularobjective, such as to exercise a particular program pathor to verify compliance with a specific requirement.3 ® 2011. EPAM Systems. All rights reserved.
  • 4. Conclusion1. Start with obvious and simple tests. Test the program with easy-to-pass values that will be taken as serious issues if the program fails.2. Look for more powerful tests. How to break it? Once the program can survive the easy tests, put on your thinking cap and look systematically for challenges.3. Pick boundary conditions. There will be too many good tests.You need a strategy for picking and choosing.4. Do some exploratory testing. Run new tests every week, from the first week to the last week of the project.5. Learn from experience. 4 ® 2011. EPAM Systems. All rights reserved.
  • 5. Software Testing Artifacts Writing Down Test Cases5 ® 2011. EPAM Systems. All rights reserved.
  • 6. Writing Down Test Cases Introduction into Test Cases  What is it?  Why do we need them?  Templates to use Writing Good Tests Cases Test scenarios 6 ® 2011. EPAM Systems. All rights reserved.
  • 7. Test Case: What is it?IEEE Standard 610 (1990) defines test case as follows:A set of test inputs, execution conditions, and expected resultsdeveloped for a particular objective, such as to exercise aparticular program path or to verify compliance with a specificrequirement.(IEEE Std 829-1983) - Documentation specifying inputs, predictedresults, and a set of execution conditions for a test item. 7 ® 2011. EPAM Systems. All rights reserved.
  • 8. Test Cases: Why do we need them?  Why should we spend time writing our tests down?  We could run so many tests instead!With test cases we can: • Plan, only then run -> structured and systematic approach-> less bugs missed (!) • Store information • Test the Requirements documentation before application is available • Accelerate regression testing • Pass information to new members of the team • Remember ourselves what tests we„ve designed half a year ago • Reuse “checklists” between projects • Track testing progress (X% tests executed,Y% tests passed (failed), Z% requirements covered) 8 ® 2011. EPAM Systems. All rights reserved.
  • 9. Software Testing Artifacts Relationship of Test Documents to Testing Process9 ® 2011. EPAM Systems. All rights reserved.
  • 10. Functional Testing WorkflowSoftware Testing Stages Test Test Designing Executing Test Analyze & Planning Reporting Initiation Completion 10 ® 2011. EPAM Systems. All rights reserved.
  • 11. Relationship of Test Documents to Testing Process Test Plan Test Specification Test Design Specification Test Case Specification Test Procedure Specification Test Reporting Test Item Transmittal Report Test Log Test Incident Report Test Summary Report11 ® 2011. EPAM Systems. All rights reserved.
  • 12. Software Testing Artifacts Test Specification12 ® 2011. EPAM Systems. All rights reserved.
  • 13. Software Testing Artifacts Test Specification – IEEE 82913 ® 2011. EPAM Systems. All rights reserved.
  • 14. Test Specification IEEE829Test Design SpecificationTest Case SpecificationTest Procedure Specification14 ® 2011. EPAM Systems. All rights reserved.
  • 15. Test Design SpecificationPurpose To specify refinements of the test approach and to identify the features to be tested by this design and its associated tests.Outline a) Test design specification identifier; b) Features to be tested; c) Approach refinements; d) Test identification; e) Feature pass/fail criteria.15 ® 2011. EPAM Systems. All rights reserved.
  • 16. Test Case SpecificationPurpose To define a test case identified by a test design specification.Outline a) Test case specification identifier; b) Test items; c) Input specifications; d) Output specifications; e) Environmental needs; f) Special procedural requirements; g) Intercase dependencies.16 ® 2011. EPAM Systems. All rights reserved.
  • 17. Test Procedure SpecificationPurpose To specify the steps for executing a set of test cases or, more generally, the steps used to analyze a software item in order to evaluate a set of features.Outline a) Test procedure specification identifier. b) Purpose; c) Special requirements; d) Procedure steps.17 ® 2011. EPAM Systems. All rights reserved.
  • 18. Software Testing Artifacts Test Specification – EPAM18 ® 2011. EPAM Systems. All rights reserved.
  • 19. Test Case Anatomy We want to document a test. What information should we record?  Steps  Expected results  Passed or failed  Title  Some ID  Related requirement  Priority (Smoke, Critical, Extended; or A, B, C, D or any other)  Module, submodule  Initial data we need for test  Author, last time run, actual result, related bug 19 ® 2011. EPAM Systems. All rights reserved.
  • 20. EPAM Testthat is Priority Requirement Case: Title – summary what Excel Template result Expected (low) tested we are testing after each stepARC_ L R25 Save Upload Upload, file name with 1. Upload dialog appears NotC10.1 item file special symbols 2. Browsers "choose file" tested95 Setup: On your computer dialog appears create file named `~!$^()- 3. "choose file" dialog Test _+[]{},.html , not empty closes, `~!$^()- Status in the Case ID 1. Click Upload button _+[]{},..html appears in build Setup 2. Click Browse button the FROM field. (passed/failed/no 3. Select `~!$^()- 4. Upload dialog closes, t tested) _+[]{},..html file and click file name from the TO Open. field is substituted in the Module and 4. Click upload long description file name Submodule 5. Click Add To List field. File contents is shown below. 5. Attachment is added Steps to perform 20 ® 2011. EPAM Systems. All rights reserved.
  • 21. Test Scenarios (Test Suite) Test scenario = a set of test cases for some purpose. Good test scenario flows along some logic - typical usage, convenience to test, by modules. 21 ® 2011. EPAM Systems. All rights reserved.
  • 22. Writing Test Scenarios Choose a part, use grouping. Write Smoke and Critical scenarios. Move from simple tests to more complex. Organize scenarios logically (do not use test cases from other parts, scenario should be convenient to pass). 22 ® 2011. EPAM Systems. All rights reserved.
  • 23. EPAM Test Cases Template Title page Smoke test page Excel Groups by features Author(s) Pages for Smoke, Critical, Extended test levels Automatic History of changes Statistics Last changes are Legend marked in blue23 ® 2011. EPAM Systems. All rights reserved.
  • 24. Test Scenarios in PMC Run Scenario Scenarios Test Cases Test cases list Run Test Case24 ® 2011. EPAM Systems. All rights reserved.
  • 25. Writing Test scenarios… continuation One test for one check. Titles reveal the main point of tests. Preparation (initial data, that can be used while passing the scenario). Do not repeat exact steps to achieve the same result (can be given in the first test only). Alternate cases giving one result with cases giving another. 25 ® 2011. EPAM Systems. All rights reserved.
  • 26. Several tricks to write test cases Copy-paste. Write questions right into test case and mark with a color: if you still have question on any requirement and you cannot write a test case definitely, you can mark the issue with red and write comments. Use several colors to mark new (just added), old test cases, test cases with questions. Cases should have a good logical structure: use Excel grouping. Create a history for the file with test cases. 26 ® 2011. EPAM Systems. All rights reserved.
  • 27. Software Testing Artifacts How To Create Good Test Case?27 ® 2011. EPAM Systems. All rights reserved.
  • 28. Good Test Case: ConclusionAn excellent test case satisfies the following criteria:  Reasonable probability of catching an error.  Exercises an area of interest.  Does interesting things.  Doesn‟t do unnecessary things.  Neither too simple nor too complex.  Not redundant with other tests.  Makes failures obvious.  Allows isolation and identification of errors.What else? 28 ® 2011. EPAM Systems. All rights reserved.
  • 29. Steps to Create Test Cases1. Start early – before the first build.2. Break application into functions/modules to be tested.3. Write checklist for each function/area.4. Add any questions, as you go.5. Fill in details, resolve questions.6. Add cosmetics – for better reading.7. Get review from other tester, developer, customer.8. Update as soon as mistake is found.9. Update as functionality changes. 29 ® 2011. EPAM Systems. All rights reserved.
  • 30. Step 1Start early- before the first build What sources of information do we have at this time? What sources do we not have? You cannot see working application. Learn all sources of information you have, first (documents, people, etc). Your questions may find and correct serious holes in design. Test cases creation goes parallel with requirements review. You cannot predict all bugs. Design still may change. 30 ® 2011. EPAM Systems. All rights reserved.
  • 31. Step 2Break application into functions/modules to be tested Break into pieces until each piece is simple enough to list all tests 31 ® 2011. EPAM Systems. All rights reserved.
  • 32. Step 3Write checklist for each function/area.Easy to check that all tests included.Easy to reorder.Easy to see where to use copy-paste.We separate 2 different kinds of work (thinking and writing).Do not just copy requirements into cells.1 line=1 test case.If something is not clear – write a question right NOW. 32 ® 2011. EPAM Systems. All rights reserved.
  • 33. Steps 4,5,6Add any questions, as you go.Fill in details, resolve questions.Add cosmetics – for better reading.Then use copy paste. 33 ® 2011. EPAM Systems. All rights reserved.
  • 34. Step 7Get review from other tester, developer, customer.  Are some interesting tests missed?  Are some tests redundant?  Are test cases easy to understand by other person? Novice tester?  Is it what customer expects?  Are there any errors? (there is always at least one more ) 34 ® 2011. EPAM Systems. All rights reserved.
  • 35. Step 7Get review from other tester, developer, customer.  Another point of view (developer, marketing).  It‟s hard to notice your own mistakes.  Often we do not have some information.  Developer can have another opinion; we can clarify before the code is created.  Often getting review is not easy, but if done thoroughly, it is very useful.  Raises standard for test cases. 35 ® 2011. EPAM Systems. All rights reserved.
  • 36. Steps 8,9Update as soon as mistake is foundUpdate as functionality changes  Small corrections: do right now, until you forget!  Big changes – you can find time for them: • At the beginning new phase. • At the end of a build cycle. • Sudden free time due to build delay, etc. 36 ® 2011. EPAM Systems. All rights reserved.
  • 37. Your Global Technology Outsourcing Partner Thanks for your attentionEPAM Systems, Inc.http://www.epam.comNTUU “KPI” EPAM POWER POINT TITLEhttp://kpi.ua Sub Topic ® 2011. EPAM Systems. All rights reserved.

×