HEN-GEAR - Test Management
Comments
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

 
%
123
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ABCDEFGHIJKLMNOPQRST
1
2
HEN GEAR PROJECT
3
TESTING
4
HOME PAGEhttp://international.almalaurea.it/armenia-test/
5
TEST STATUSRUNNING
6
7
Instructions
8
Execute the tests following the list of functionalities and test case:
9
1. SELECT
select the "TEST CASE" you want to test. E.g. "T.S.R.1", "Registration";
10
2. PREPAREadd a new line in the "TEST EXECUTED" sheet. Define all the "yellow fields". Insert the test case code (e.g. T.S.R.1) into the column "test case ID"
11
3. EXECUTEadd a new line into the DEFECTS sheet for all the issues you encounter during the test (bug, defect): insert the code of the TEST into the column "TEST ID", insert the url of the page where you found the issue and enter a detailed description of the problem
12
suggestions:Before listing a new defect, please verify if it has been already inserted.
13
When a user is necessary to execute the test, select one of the right group (student, company, staff) from the "TEST USERNAMES" sheet.
14
YELLOW COLUMNSEditable fields. The tester should enter values for those columns
15
GREY COLUMNReadonly (derived) columns. These columns should not be edited. Theirs values are assigned directly by the spreadsheet according to lookup tables.
16
AZURE COLUMNSThese fields should not be edited by testers. Test manager and programmers only should edit these columns.
17
18
19
20
DEFECT LIFE CYCLE(Bug Life cycle) is the journey of a defect from its identification to its closure. The Life Cycle varies from organization to organization and is governed by the software testing process the organization or project follows and/or the Defect tracking tool being used.
21
NEWTester finds a defect and posts it with the status NEW. This defect is yet to be studied/approved. The fate of a NEW defect is one of ASSIGNED, DROPPED and DEFERRED.
22
ASSIGNEDTest / Development / Project lead studies the NEW defect and if it is found to be valid it is assigned to a member of the Development Team. The assigned Developer’s responsibility is now to fix the defect and have it COMPLETED.
23
COMPLETEDDeveloper ‘fixes’ the defect that is ASSIGNED to him or her. Now, the ‘fixed’ defect needs to be verified by the Test Team and the Development Team ‘assigns’ the defect back to the Test Team. A COMPLETED defect is either CLOSED, if fine, or REASSIGNED, if still not fine.
24
CLOSEDIf the Tester / Test Lead finds that the defect is indeed fixed and is no more of any concern, it is CLOSED / VERIFIED. This is the happy ending.
25
DROPPEDTest / Development/ Project lead studies the NEW defect and if it is found to be invalid, it is DROPPED / REJECTED. Note that the specific reason for this action needs to be given.
26
DEFERREDIf a valid NEW or ASSIGNED defect is decided to be fixed in upcoming releases instead of the current release it is DEFERRED. This defect is ASSIGNED when the time comes.
27
REASSIGNEDIf the Tester finds that the ‘fixed’ defect is in fact not fixed or only partially fixed, it is reassigned to the Developer who ‘fixed’ it. A REASSIGNED defect needs to be COMPLETED again.
28
29
SEVERITYThe degree of impact that a defect has on the development or operation of a component or system.
30
S1 - CriticalThe defect affects critical functionality or critical data. It does not have a workaround.
31
S2 - MajorThe defect affects major functionality or major data. It has a workaround but is not obvious and is difficult. Example: A feature is not functional from one module but the task is doable if 10 complicated indirect steps are followed in another module/s.
32
S3 - minorThe defect affects minor functionality or non-critical data. It has an easy workaround. Example: A minor feature that is not functional in one module but the same task is easily doable from another module.
33
S4 - trivialThe defect does not affect functionality or data. It does not even need a workaround. It does not impact productivity or efficiency. It is merely an inconvenience. Example: Petty layout discrepancies, spelling/grammatical errors.
34
PROBABILITY(Defect Visibility or Bug Probability or Bug Visibility) indicates the likelihood of a user encountering the defect / bug.
35
P1 - HighEncountered by all or almost all the users of the feature
36
P2 - MediumEncountered by about 50% of the users of the feature
37
P3 - LowEncountered by very few or no users of the feature
38
PRIORITYDefect Priority (Bug Priority) indicates the importance or urgency of fixing a defect. Though priority may be initially set by the Software Tester, it is usually finalized by the Project/Product Manager.
39
UrgentMust be fixed in the next build.
40
HighMust be fixed in any of the upcoming builds but should be included in the release.
41
MediumMay be fixed after the release / in the next release.
42
LowMay or may not be fixed at all.
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
Loading...
 
 
 
INSTRUCTIONS
FUNCTIONS
TEST CASES
END TO END TEST
TEST EXECUTED
DEFECTS
DEFECTS-archive
TEST USERNAMES
translations
recap of translations
Foglio1