Difference between revisions of "General guidelines"
m |
|||
| Line 1: | Line 1: | ||
| − | == How to write test case == | + | == How to write test case == |
| − | === Details required before writing test cases === | + | === Details required before writing test cases === |
| − | *Read Specification and Requirements carefully | + | *Read Specification and Requirements carefully |
| + | *Be clear with the design ad the implementation details | ||
| + | *Analyze and Identify all possible scenarios | ||
| + | *Identify the test enviroments and test types | ||
| + | *Should have detailed information related and affected areas of the requirement | ||
| + | *Should be clear of behavior under failure condition (invalid input, boundary values, ect.) | ||
| − | === Qualities of a Good Test Case === | + | === Qualities of a Good Test Case === |
*Easy to determine the result | *Easy to determine the result | ||
| Line 33: | Line 38: | ||
Note: Properly written test cases help both testers as well as developers while execution and debugging. | Note: Properly written test cases help both testers as well as developers while execution and debugging. | ||
| − | === Improving Testability (Easy to Test) - Language === | + | === Improving Testability (Easy to Test) - Language === |
| − | *Use Action case say Do This, Do That | + | *Use Action case say Do This, Do That |
| + | *System Display this, Do That | ||
| + | *Simple Conversational Language | ||
| + | *Exact, consistent names of fields, not generic | ||
| + | *Don't explain windows basics | ||
| + | *10-15 steps or less. In case of integration test cases try to provide references instead of explaining te functionality again and again. | ||
| + | *Always update your test case with the new build | ||
| + | *Follow Naming Convention - Naming Convention helps to differentiate between function, control, dbname, etc. It helps in easy identification of different controls, functions, Labels, hyperlink, etc. | ||
=== Naming Conventions === | === Naming Conventions === | ||
| − | *Module names should be in Capitals and Bold <br>*Screen names should be in bold and have camel notations i.e., the first word in capital letters and rest all in small letters. | + | *Module names should be in Capitals and Bold <br>*Screen names should be in bold and have camel notations i.e., the first word in capital letters and rest all in small letters. |
| + | *All the objects like textbox, listbox, checkbox, radio buttons, etc. should be in italics and bold. | ||
| + | *The link names should be mentioned in italics, bold and underline below the word e.g.,'Sign Out' link should be mentioned as ''''''Sign Out'''''' | ||
| + | *Database table name should be in caps e.g., Emp_Details table name should be EMP_DETAILS. | ||
=== Test case Attributes === | === Test case Attributes === | ||
| − | ''Look at'' [[Bug's settings]] | + | ''Look at'' [[Bug's settings]] |
=== General Guidelines === | === General Guidelines === | ||
| − | *Write test cases before implementation of requirement. | + | *Write test cases before implementation of requirement. |
| − | *Test cases are written for all the requirements. Test case should map to current requirement and should not be an enhancement to the application. | + | *Test cases are written for all the requirements. Test case should map to current requirement and should not be an enhancement to the application. |
| − | *Follow a standard template for all test cases. | + | *Follow a standard template for all test cases. |
| − | *User very simple English and general words. | + | *User very simple English and general words. |
| − | *Format followed (Aglignment, Naming convention, etc.) by test cases should be uniform for the entire application. | + | *Format followed (Aglignment, Naming convention, etc.) by test cases should be uniform for the entire application. |
| − | *All the scenario/Test case should be easily understandable, clear and to the point. | + | *All the scenario/Test case should be easily understandable, clear and to the point. |
| − | *Highlight important points by making text bold or assigning it a color or writing it in different font. | + | *Highlight important points by making text bold or assigning it a color or writing it in different font. |
| − | *You may add sections to a group of test cases to make it more informative. | + | *You may add sections to a group of test cases to make it more informative. |
| − | *You may use double quotes for a paricular display text. | + | *You may use double quotes for a paricular display text. |
| − | *Maintain the test cases in a flow so that execution order is maintained and time is saved. | + | *Maintain the test cases in a flow so that execution order is maintained and time is saved. |
| − | *You bullet points for different steps. | + | *You bullet points for different steps. |
| − | *Specify Test case type and priority which would help in determining whether to run the test case in specific scenario or not. | + | *Specify Test case type and priority which would help in determining whether to run the test case in specific scenario or not. |
| − | *the prerequisite for the scenario/test case should be mentioned before the test case. | + | *the prerequisite for the scenario/test case should be mentioned before the test case. |
| − | *Use a mix of both 'Positive and Negative' tests. | + | *Use a mix of both 'Positive and Negative' tests. |
| − | *Provide test data (if possible) | + | *Provide test data (if possible) |
| − | *Write in details SQL Queries (it will be save time while executing) | + | *Write in details SQL Queries (it will be save time while executing) |
| − | *Add reference to bugs or requirement as per your needs. | + | *Add reference to bugs or requirement as per your needs. |
| − | *Add some notes in case you want to convey adtional information or explain the test case with example in case the scenario is not much clear. | + | *Add some notes in case you want to convey adtional information or explain the test case with example in case the scenario is not much clear. |
*You can use build number next to your results to keep track of results or determining defect density | *You can use build number next to your results to keep track of results or determining defect density | ||
Revision as of 11:28, 9 April 2010
Contents
How to write test case
Details required before writing test cases
- Read Specification and Requirements carefully
- Be clear with the design ad the implementation details
- Analyze and Identify all possible scenarios
- Identify the test enviroments and test types
- Should have detailed information related and affected areas of the requirement
- Should be clear of behavior under failure condition (invalid input, boundary values, ect.)
Qualities of a Good Test Case
- Easy to determine the result
Tests are viewed one after the other in quick succession, usually in groups of serveral hundred to a thousand. As such, it is important that the results be easy to interpret.
- Quick to determine the result
The tests should need no more than a fiew seconds to convey their results to the tester.
- Self explanatory
The tests should not need an understanding of the specification to be used.
- Short
Tests should be very short (a paragrapt or so) and certainly not require scrolling on even the most modest of screens, unless the test is specifically for scrolling or paginating behaviour.
- Valid
Unless specifically testing error-recovery features, the tests should all be valid
- Cross-platform
Test should be a cross-platform as reasonably possible, working across different devices, screen resolutions, paper sizes, etc. Exceptions should be document their assumption
Note: Properly written test cases help both testers as well as developers while execution and debugging.
Improving Testability (Easy to Test) - Language
- Use Action case say Do This, Do That
- System Display this, Do That
- Simple Conversational Language
- Exact, consistent names of fields, not generic
- Don't explain windows basics
- 10-15 steps or less. In case of integration test cases try to provide references instead of explaining te functionality again and again.
- Always update your test case with the new build
- Follow Naming Convention - Naming Convention helps to differentiate between function, control, dbname, etc. It helps in easy identification of different controls, functions, Labels, hyperlink, etc.
Naming Conventions
- Module names should be in Capitals and Bold
*Screen names should be in bold and have camel notations i.e., the first word in capital letters and rest all in small letters. - All the objects like textbox, listbox, checkbox, radio buttons, etc. should be in italics and bold.
- The link names should be mentioned in italics, bold and underline below the word e.g.,'Sign Out' link should be mentioned as 'Sign Out'
- Database table name should be in caps e.g., Emp_Details table name should be EMP_DETAILS.
Test case Attributes
Look at Bug's settings
General Guidelines
- Write test cases before implementation of requirement.
- Test cases are written for all the requirements. Test case should map to current requirement and should not be an enhancement to the application.
- Follow a standard template for all test cases.
- User very simple English and general words.
- Format followed (Aglignment, Naming convention, etc.) by test cases should be uniform for the entire application.
- All the scenario/Test case should be easily understandable, clear and to the point.
- Highlight important points by making text bold or assigning it a color or writing it in different font.
- You may add sections to a group of test cases to make it more informative.
- You may use double quotes for a paricular display text.
- Maintain the test cases in a flow so that execution order is maintained and time is saved.
- You bullet points for different steps.
- Specify Test case type and priority which would help in determining whether to run the test case in specific scenario or not.
- the prerequisite for the scenario/test case should be mentioned before the test case.
- Use a mix of both 'Positive and Negative' tests.
- Provide test data (if possible)
- Write in details SQL Queries (it will be save time while executing)
- Add reference to bugs or requirement as per your needs.
- Add some notes in case you want to convey adtional information or explain the test case with example in case the scenario is not much clear.
- You can use build number next to your results to keep track of results or determining defect density
Note: Test case should be such that any person going to execute it or read it gets a clear picture of what needs to be done without needing any explanations.
