General guidelines - Revision history

Wikicatglobe at 10:37, 18 October 2013

2013-10-18T10:37:20Z

← Older revision		Revision as of 10:37, 18 October 2013
Line 1:		Line 1:
	<accesscontrol>~~Administrators~~</accesscontrol>		<accesscontrol>Main:MyGroup</accesscontrol>
	== How to write test case ==		== How to write test case ==

Cg_pham at 08:55, 4 October 2011

2011-10-04T08:55:55Z

← Older revision		Revision as of 08:55, 4 October 2011
Line 1:		Line 1:
			<accesscontrol>Administrators</accesscontrol>
	== How to write test case ==		== How to write test case ==

Catglobe at 09:29, 9 April 2010

2010-04-09T09:29:10Z

← Older revision		Revision as of 09:29, 9 April 2010
Line 51:		Line 51:
	=== 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
	*All the objects like textbox, listbox, checkbox, radio buttons, etc. should be in italics 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.
	*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''''''		*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.		*Database table name should be in caps e.g., Emp_Details table name should be EMP_DETAILS.

Catglobe at 09:28, 9 April 2010

2010-04-09T09:28:56Z

← Older revision		Revision as of 09:28, 9 April 2010
Line 18:		Line 18:
	*Quick to determine the result		*Quick to determine the result

	The tests should need no more than a fiew seconds to convey their results to the tester.		The tests should need no more than a fiew seconds to convey their results to the tester.

	*Self explanatory		*Self explanatory

Catglobe at 09:28, 9 April 2010

2010-04-09T09:28:46Z

← Older revision		Revision as of 09:28, 9 April 2010
Line 14:		Line 14:
	*Easy to determine the result		*Easy to determine the result

	&~~amp;~~nbsp;&~~amp;~~nbsp;&~~amp;~~nbsp;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.		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		*Quick to determine the result

	~~&nbsp;&nbsp;&nbsp;~~The tests should need no more than a fiew seconds to convey their results to the tester.		The tests should need no more than a fiew seconds to convey their results to the tester.

	*Self explanatory		*Self explanatory

	&~~amp;~~nbsp;&~~amp;~~nbsp;&~~amp;~~nbsp;The tests should not need an understanding of the specification to be used.		The tests should not need an understanding of the specification to be used.

	*Short		*Short

	&~~amp;~~nbsp;&~~amp;~~nbsp;&~~amp;~~nbsp;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.		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		*Valid

	&~~amp;~~nbsp;&~~amp;~~nbsp;&~~amp;~~nbsp;Unless specifically testing error-recovery features, the tests should all be valid		Unless specifically testing error-recovery features, the tests should all be valid

	*Cross-platform		*Cross-platform

	&~~amp;~~nbsp;&~~amp;~~nbsp;&~~amp;~~nbsp;Test should be a cross-platform as reasonably possible, working across different devices, screen resolutions, paper sizes, etc. Exceptions should be document their assumption		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.		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 ===

Catglobe at 09:28, 9 April 2010

2010-04-09T09:28:00Z

← Older revision		Revision as of 09:28, 9 April 2010
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 ~~<br>~~Be clear with the design ad the implementation details ~~<br>~~Analyze and Identify all possible scenarios ~~<br>~~Identify the test enviroments and test types ~~<br>~~Should have detailed information related and affected areas of the requirement ~~<br>~~Should be clear of behavior under failure condition (invalid input, boundary values, ect.)		*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 ~~<br>~~System Display this, Do That ~~<br>~~Simple Conversational Language ~~<br>~~Exact, consistent names of fields, not generic ~~<br>~~Don't explain windows basics ~~<br>~~10-15 steps or less. In case of integration test cases try to provide references instead of explaining te functionality again and again. ~~<br>~~Always update your test case with the new build ~~<br>~~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.		*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. ~~<br>~~All the objects like textbox, listbox, checkbox, radio buttons, etc. should be in italics and bold. ~~<br>~~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'''''' ~~<br>~~*Database table name should be in caps e.g., Emp_Details table name should be EMP_DETAILS.		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

Catglobe at 09:26, 9 April 2010

2010-04-09T09:26:18Z

← Older revision		Revision as of 09:26, 9 April 2010
Line 45:		Line 45:
	''Look at'' [[Bug's settings]]		''Look at'' [[Bug's settings]]

	=== General Guidelines ===		=== General Guidelines ===

	Write test cases before implementation of requirement. ~~<br>~~Test cases are written for all the requirements. Test case should map to current requirement and should not be an enhancement to the application. ~~<br>~~Follow a standard template for all test cases. ~~<br>~~User very simple English and general words. ~~<br>~~Format followed (Aglignment, Naming convention, etc.) by test cases should be uniform for the entire application. ~~<br>~~All the scenario/Test case should be easily understandable, clear and to the point. ~~<br>~~Highlight important points by making text bold or assigning it a color or writing it in different font. ~~<br>~~You may add sections to~~&nbsp;~~ a group of test cases to make it more informative. ~~<br>~~You may use double quotes for a paricular display text. ~~<br>~~Maintain the test cases in a flow so that execution order is maintained and time is saved. ~~<br>~~You bullet points for different steps. ~~<br>~~Specify Test case type and priority which would help in determining whether to run the test case in specific scenario or not. ~~<br>~~the prerequisite for the scenario/test case should be mentioned before the test case. ~~<br>~~Use a mix of both 'Positive and Negative' tests. ~~<br>~~Provide test data (if possible) ~~<br>~~Write in details SQL Queries (it will be save time while executing) ~~<br>~~Add reference to bugs or requirement as per your needs. ~~<br>~~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. ~~<br>~~*You can use build number next to your results to keep track of results or determining defect density		*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.		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.

	[[Category: ~~Test case guidelines~~]]		[[Category:Test_case_guidelines]]

Catglobe at 09:24, 9 April 2010

2010-04-09T09:24:49Z

← Older revision		Revision as of 09:24, 9 April 2010
Line 37:		Line 37:
	Use Action case say Do This, Do That <br>System Display this, Do That <br>Simple Conversational Language <br>Exact, consistent names of fields, not generic <br>Don't explain windows basics <br>10-15 steps or less. In case of integration test cases try to provide references instead of explaining te functionality again and again. <br>Always update your test case with the new build <br>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.		Use Action case say Do This, Do That <br>System Display this, Do That <br>Simple Conversational Language <br>Exact, consistent names of fields, not generic <br>Don't explain windows basics <br>10-15 steps or less. In case of integration test cases try to provide references instead of explaining te functionality again and again. <br>Always update your test case with the new build <br>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. <br>All the objects like textbox, listbox, checkbox, radio buttons, etc. should be in italics and bold. <br>The link names should be mentioned in italics, bold and underline below the word e.g.,'Sign Out' link should be mentioned as ~~<u>~~''''''Sign Out''''''~~</u>~~ <br>*Database table name should be in caps e.g., Emp_Details table name should be EMP_DETAILS.		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. <br>All the objects like textbox, listbox, checkbox, radio buttons, etc. should be in italics and bold. <br>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'''''' <br>*Database table name should be in caps e.g., Emp_Details table name should be EMP_DETAILS.

	=== Test case Attributes ===		=== Test case Attributes ===

Catglobe at 09:24, 9 April 2010

2010-04-09T09:24:27Z

← Older revision		Revision as of 09:24, 9 April 2010
Line 41:		Line 41:
	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. <br>All the objects like textbox, listbox, checkbox, radio buttons, etc. should be in italics and bold. <br>The link names should be mentioned in italics, bold and underline below the word e.g.,'Sign Out' link should be mentioned as <u>''''''Sign Out''''''</u> <br>*Database table name should be in caps e.g., Emp_Details table name should be EMP_DETAILS.		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. <br>All the objects like textbox, listbox, checkbox, radio buttons, etc. should be in italics and bold. <br>The link names should be mentioned in italics, bold and underline below the word e.g.,'Sign Out' link should be mentioned as <u>''''''Sign Out''''''</u> <br>*Database table name should be in caps e.g., Emp_Details table name should be EMP_DETAILS.

	=== Test case Attributes ===		=== Test case Attributes ===

	''Look~~&nbsp;~~at'' [[Bug's settings]]		''Look at'' [[Bug's settings]]

	=== General Guidelines ===		=== General Guidelines ===

Catglobe at 09:17, 9 April 2010

2010-04-09T09:17:48Z

← Older revision		Revision as of 09:17, 9 April 2010
Line 50:		Line 50:

	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.		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.

			[[Category: Test case guidelines]]