Connecting Practice

And what are the inputs, guidelines, and outputs to bear in mind in obtaining estimates for testing phase of a software project?

Inputs

• Defined statement of project scope for clear goals and focus work
• Defined user requirements - use cases and functional specs for delivering the required functionality
• Defined technical requirements
• Other supporting documents

Guidelines to create a detailed estimates

• Determine all the effort (lists of tasks the testing work entails) to be performed. This includes getting all the next actions visible.
• Determine complexity of the system.
• Form initial estimate for each task. This includes involving the individuals who will be doing the tasks to figure out how long a task will take based on their experience implementing similar things.
• Assign each task a ‘risk.’ Assign ‘High‘ risk to tasks that you lack knowledge and/or experience; assign ‘Medium‘ risk to tasks that you are familiar with and can complete the tasks; and assign ‘Low‘ risk to tasks that you are confident about and/or have been done many times before.
• Document any other risks that might affect the test work deliverables to address and bring test work in on time.
• Document assumptions made. Note that each task figure should be accompanied by a note on the assumption(s) that you’ve made in coming to this figure and/or interpreting the task requirements.
• Apply adjustments and reserve allowances to account for external factors that the project will depend upon. External factor examples: Tasks that require approval; incomplete component from another project - here document the effect of the dependency if task is not being met; and failure from delivering the required component to a satisfactory standard that cause development delays.
• Include contingency in the estimate. The contingency should be listed separately. If tasks need to use some of the contingency for certain reasons then the Lead should ask the PM for a portion of the contingency. The reasons for needing to use some of the contingency will be discussed and the impact on the test work timelines will be shown in the test plan and shared with the team.

Guidelines to schedule the test work

• Work out how many people will be needed on the team in order to complete the test work in the required time.
• Add test work milestones. Note that every test work task listed in the estimate should become a task in the schedule.
• Assign test work tasks to people who have the skills needed to do the task. There should be some gaps between tasks to represent risk.
• Add dummy tasks to represent known outages, such as: Public holidays, annual leave, training courses, and so on.
• Try to move high risk tasks as near to the beginning of the schedule as possible so that there is as much time as possible to deal with problems.
  Ensure that dependencies between tasks are respected - reorganise the schedule if necessary.
• Keep the schedule up-to-date with latest progress and changes regularly.

Outputs

• A project schedule with allowances for risk, internal dependencies, and known outages
• A list of other assumptions made during the estimation
• A list of the project’s external dependencies
• A list of other risks to the project schedule

Join QAST Practitioner Group, download the attached sample detailed estimate template file in MS Excel version, and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=60.0

The attached sample detailed estimate template file is meant to be used to create detailed estimates for testing phase (support and regression testing) of a software project.

In “How Can You Develop A Test Specification Documents?” topic, it describes the specific activities to perform and achieve the development of test specification documents. In this piece, it describes the typical contents of test specification template for documenting test cases characteristically below.

Template Header
1. Project number - It should describe the project number accurately.

2. Test Specification name - It should describe the test specification name clearly.

Template Details
1. Test No. - It should describe the test number to ensure every test cases in a project has a unique number for traceability. Note: To ensure every test case in a project has a unique number for traceability, this number should start with the Use Case number (for example Use Case 3 Search, numbering will be 3.1, 3.1.1, 3.2, etc.) - 3.1, 3.2, etc will be section headings and not have tests associated with them, while 3.1.1…., 3.2.1 will contain the test cases. If a test does not have a Use Case associated with it, the test number must start with 0. There must be no blank rows in the “Test No.” column (Column A).

2. Tracking No. - It should describe the associated defect tracking number reference with the particular test case for traceability.

3. Found in Build - It should be the date of the build when the test case was run.

4. Use Case No. - It is important for traceability of every test case that this number matches the use case number.

5. Subject, Object, or Function Name - It should be the subject, object, or function Name where the test case was run.

6. Test Case Description - It should be clear, concise, and accurately describe the test case. It should have some mandatory fields like:

• Objective - General objective of the test case that clearly and accurately describe it.
• Pre-Test Condition - Optional, Pre-requisite for testing the feature
• Verification - Optional, Need to verify against the pre-condition or requirement
• Steps to Reproduce - It should be the clear step by step instructions on how to reproduce the test case. It should provide a verbatim transcript of the session and show what commands you typed and what output in response. It should be minimized and easy-to-follow steps.
• Expected Behavior - It should be the description of the correct or expected results where the defect is not present.
• Actual Result - It should be the clear and detailed description of what happens after the step by step instruction are followed. If you saw test failures then describe the errors, carefully and precisely, what they were. The developers need to know what has gone wrong. If available, include the error message number to get information or search for clues.

Important:

• All scenarios must be considered including negative testing.
• Boundary Analysis must be performed.
• It is not simply a case of sticking verify in front of each requirement - analysis must be carried out for completeness, effectiveness and efficiency.
• If something is not clear in the use case, now is the time to raise questions and ensure the answers form part of this document - it’s too late in the test execution phase.
• Consider information and/or things you will need to support testing, again now is the time to request for these information and/or things.

7. Test Data - Test Data to support every single test scenario must be included

8. Run - It is used to indicate which test are to be run for re-testing and regression testing. Setting the field to 1 indicates that the test case must be executed for re-testing.

9. Pass/Fail

• Pass - Test Passed
• Fail - Test failed if the actual results differ significantly from the test expectations.
• Can’t Test (CT) - A bug in another piece of functionality is restricting you from running this test
• Functionality Not available (FNA) - Functional no longer available or will be available in further phases
• Not Tested - Leave the pass/fail cell blank if you decide not to test the test case.

10. Comment - It should be any additional comments - keep them as consise as possible.

11. Tested By - It should be the tester’s name for traceability and accountability.

12. Tested Date - It should be the date when the test case was run.

13. Test Time (Hours)

• Estimated - Time estimated to execute test case
• Actual - Actual time spent executing test case (include time logging Defects, etc.)

14. Guidelines

a. The layout / format must not be changed from the original template.
b. There must be no blank rows in the “Test No.” column (Column A).
c. To insert further rows to allow you add more defects, highlight a row and click insert row (standard excel). Do not highlight row 5 when inserting rows!
d. If you need to add more test cycles, highlight the last eight columns and copy, then highlight the next eight columns and paste. Don’t forget to change the test cycle number. If you follow this instruction the formulas will also be copied and work!
e. Remember, you must keep the revision history sheet updated. If you update something - put a comment in the revision history. All test cycles must be tracked in the revision history. This number should match the SI revision number - this makes rolling back easier if needed.
f. To group test cases for convenience:

• Click on Data
• Then Settings
• Select “Summary Columns to right of detail” only
• Steps 2 and 3 will only need to be done once
• Select rows beneath your heading that you wish to group (heading should not be selected)
• Click Group and select Rows (Data/Group and Outline/Group)

Join QAST Practitioner Group, download the material in MS Excel version, and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=56.0

In “Mantis - A Free Popular Web-based Bug Tracking System“ topic, it describes Mantis as free popular web-based bug tracking system. In this piece, it describes the defect workflow used by the QA Team and Dev Team in Mantis characteristically with the following activities:

1. Reporter - Reporting Issue Basics
2. QA Team - Reviewing
3. Reporter - Giving Feedback
4. Software Development Team - Reviewing
5. Software Developer - Marking Defect as Fixed
6. QA Team - Testing
7. QA Team - Acknowledging Defect for Closing
8. Reporter - User Acceptance Testing
9. Reporter - Closing Defect

Join QAST Practitioner Group, download the material in MS Word version, and/or give comment(s) at: http://daniloalsonado.com/qastforum/index.php?topic=59.0