Test case module - Revision history

Cg_pham: Redirected page to Category:Test case module

2012-02-24T05:10:57Z

Redirected page to Category:Test case module

← Older revision		Revision as of 05:10, 24 February 2012
Line 1:		Line 1:
	[[Category:~~HelpBooks~~]]		#REDIRECT [[Category:Test_case_module]]


	~~=Test case module=~~

	The test case module is an integrated part of Catglobe, but not focused on the system's core offerings. Rather the test case module is used by clients who mainly use Catglobe for project management of large software projects. The following help file will therefore not go into details on what a test case is and how using test cases can benefit a software development process, since we presume clients wanting to implement this module already know this. Rather we will just explain how the module is used and key elements to consider if implementing the Catglobe Test Case Module.

	~~Initially, let us clarify how Catglobe sees the operational definitions of software development and the testing activities supporting it. We will onwards name the Test Case Module as TCM.~~

	~~TCM is focused on companies doing standardized software in a process similar to below:~~

	* Versions are released regularly and each version will need to be stabilized and tested both before release and during operations.
	* There will be more than one version used by clients at the same time, meaning that we need to support bugs and stabilization of several versions simultaneously.
	* We presume that the software development company will be creating many new features or updates in each version. This is although not a requirement to use TCM.
	* We regard that any test case which has a related open bug, is unstable, and we also require that no bug can be registered without relating it to an existing test case.
	* We will see Catglobe's task resources as only to be used for registering and maintaining bugs. This of course makes a lot of restrictions on using task resources for other processes.

	A test case can in reality not have a state, since it just specifies what to be tested and where, but NOT in which version. When we talk about testing a test case in a version we talk about carrying out a 'test'. We only allow one test for one version of the software. I.e. a test case of a version (= a test) can only have one state at a time - the states they can have are:

	* Untested (newly created and never tested by anyone before)
	* Tested (tested and seen as stable)
	* Unstable (a bug exists that need to be fixed)
	* Potentially unstable (there potentially exists a bug, so we should ASAP test the test case)

	There are two ways in which a test can be deemed unstable. One is if a tester is sitting and testing one test at a time and then finds that it does not pass. If it does not pass the tester will set the test case to unstable. This, in effect, will require the tester to register a bug (create a task).

	The other way in which a test can become unstable is when we receive a bug from an external source (user of the software). We then register the bug as a task, and in addition we need to specify for that task, what test case it belongs to. If it does not belong to any existing test case, the receiver of the bug will be forced to make a new test case and test. This gives us the advantage that bugs force us to make our test case system more extensive thus increasing the chance that we will find bugs before release in future versions.

	~~==Interaction between tests==~~

	It is possible to register that a test case is related to another test case either as an affecting or affected test case. These relationships define when bugs in one test potentially will affect another test. If a test case A is related to another test case B as an affecting test case, then when test A is set to Unstable, the system will automatically set test B to potentially unstable. This will ensure that we do not only fix the bugs that occur, but also check that there are not any bugs in related features tending to break down whenever the primary test case is unstable.

	Another logic found in the system is, that when we register a test as unstable in one version (e.g. version 3), then the same tests (i.e. tests relating to same test case but different versions) in later versions will all be set to potentially unstable. This will ensure us that bugs which are found are corrected in all versions and not just the one it was found in.

	For both of the above interaction logics is although the restriction that when we affect the state of a related test, then it will only change if its status is not already 'unstable'. In this case no change will occur.

	~~Now please click on the below links to start learning how to use TCM.~~
	~~__NOTOC__~~
	~~<!-- imported from file: 1677.htm-->~~

Catglobe: jrfconvert import

2011-03-07T09:01:44Z

jrfconvert import

← Older revision		Revision as of 09:01, 7 March 2011
Line 2:		Line 2:


	~~===~~=Test case module~~===~~=		=Test case module=

	~~In the left side~~ of the ~~navigation overview dialog you will see~~ the ~~list~~ of ~~all main modules~~. ~~When clicking~~ on ~~any~~ module ~~you~~ will in the ~~right frame see the navigation functions that exist for that~~ module~~. For all modules there will be a 'main' navigation function on top, which normally~~ is used to ~~grant access to~~ the ~~entire module or at least the most important part of the module~~.		The test case module is an integrated part of Catglobe, but not focused on the system's core offerings. Rather the test case module is used by clients who mainly use Catglobe for project management of large software projects. The following help file will therefore not go into details on what a test case is and how using test cases can benefit a software development process, since we presume clients wanting to implement this module already know this. Rather we will just explain how the module is used and key elements to consider if implementing the Catglobe Test Case Module.

	~~Below you see~~ how ~~this main navigation function looks when chosen for~~ the Test ~~case module~~.		Initially, let us clarify how Catglobe sees the operational definitions of software development and the testing activities supporting it. We will onwards name the Test Case Module as TCM.

	~~[[Image~~:~~7279.png\|193px\|TestCaseModule]]~~		TCM is focused on companies doing standardized software in a process similar to below:

	When ~~checked~~ it ~~means~~ that the ~~user~~ will ~~have access~~ to the ~~Test~~ case ~~resource list via Tools -> Projects~~ and ~~folders -> Test cases~~.		* Versions are released regularly and each version will need to be stabilized and tested both before release and during operations.
			* There will be more than one version used by clients at the same time, meaning that we need to support bugs and stabilization of several versions simultaneously.
			* We presume that the software development company will be creating many new features or updates in each version. This is although not a requirement to use TCM.
			* We regard that any test case which has a related open bug, is unstable, and we also require that no bug can be registered without relating it to an existing test case.
			* We will see Catglobe's task resources as only to be used for registering and maintaining bugs. This of course makes a lot of restrictions on using task resources for other processes.

			A test case can in reality not have a state, since it just specifies what to be tested and where, but NOT in which version. When we talk about testing a test case in a version we talk about carrying out a 'test'. We only allow one test for one version of the software. I.e. a test case of a version (= a test) can only have one state at a time - the states they can have are:

			* Untested (newly created and never tested by anyone before)
			* Tested (tested and seen as stable)
			* Unstable (a bug exists that need to be fixed)
			* Potentially unstable (there potentially exists a bug, so we should ASAP test the test case)

			There are two ways in which a test can be deemed unstable. One is if a tester is sitting and testing one test at a time and then finds that it does not pass. If it does not pass the tester will set the test case to unstable. This, in effect, will require the tester to register a bug (create a task).

			The other way in which a test can become unstable is when we receive a bug from an external source (user of the software). We then register the bug as a task, and in addition we need to specify for that task, what test case it belongs to. If it does not belong to any existing test case, the receiver of the bug will be forced to make a new test case and test. This gives us the advantage that bugs force us to make our test case system more extensive thus increasing the chance that we will find bugs before release in future versions.

			==Interaction between tests==

			It is possible to register that a test case is related to another test case either as an affecting or affected test case. These relationships define when bugs in one test potentially will affect another test. If a test case A is related to another test case B as an affecting test case, then when test A is set to Unstable, the system will automatically set test B to potentially unstable. This will ensure that we do not only fix the bugs that occur, but also check that there are not any bugs in related features tending to break down whenever the primary test case is unstable.

			Another logic found in the system is, that when we register a test as unstable in one version (e.g. version 3), then the same tests (i.e. tests relating to same test case but different versions) in later versions will all be set to potentially unstable. This will ensure us that bugs which are found are corrected in all versions and not just the one it was found in.

			For both of the above interaction logics is although the restriction that when we affect the state of a related test, then it will only change if its status is not already 'unstable'. In this case no change will occur.

			Now please click on the below links to start learning how to use TCM.
	__NOTOC__		__NOTOC__
	<!-- imported from file: ~~7133~~.htm-->		<!-- imported from file: 1677.htm-->

Catglobe: jrfconvert import

2011-03-07T08:59:36Z

jrfconvert import

New page

[[Category:HelpBooks]]

====Test case module====

In the left side of the navigation overview dialog you will see the list of all main modules. When clicking on any module you will in the right frame see the navigation functions that exist for that module. For all modules there will be a 'main' navigation function on top, which normally is used to grant access to the entire module or at least the most important part of the module.

Below you see how this main navigation function looks when chosen for the Test case module.

[[Image:7279.png|193px|TestCaseModule]]

When checked it means that the user will have access to the Test case resource list via Tools -> Projects and folders -> Test cases.
__NOTOC__