ISTQB Foundation Level Exam Crash Course Part-28
This is Part 28 of 35 containing 5 Questions (Q. 136 to 140) with detailed explanation as expected in ISTQB Foundation Level Exam Latest Syllabus updated in 2011
Deep study of these 175 questions shall be of great help in getting success in ISTQB Foundation Level Exam
Q. 136: What are the different test-control activities?
We have referred above to the collection and reporting of progress data. Test control uses this information to decide on a course of action to ensure control of the test activities is maintained and exit criteria are met. This is particularly required when the planned test activities are behind schedule. The actions taken could impact any of the test activities and may also affect other software life-cycle activities.
Examples of test-control activities are as follows:
1) Making decisions based on
information from test monitoring.2) Re-prioritize tests when an identified project risk occurs (e.g. software delivered late).
3) Change the test schedule due to availability of a test environment.
4) Set an entry criterion requiring fixes to be re-tested (confirmation tested) by a developer before accepting them into a build (this is particularly useful when defect fixes continually fail again when re-tested).
5) Review of product risks and perhaps changing the risk ratings to meet the target.
6) Adjusting the scope of the testing (perhaps the amount of tests to be run) to manage the testing of late change requests.
<<<<<< =================== >>>>>>
Q. 137: Which test-control activities don�t fall under the responsibility of test leader?
The following test-control activities are likely to be outside the test leader’s responsibility. However, this should not stop the test leader making a recommendation to the project manager.
1) Descoping of functionality, i.e. removing some less important planned deliverables from the initial delivered solution to reduce the time and effort required to achieve that solution.
2) Delaying release into the production environment until exit criteria have been met.
3) Continuing testing after delivery into the production environment so that defects are found before they occur in production.
<<<<<< =================== >>>>>>
Q. 138: What is Incident Management
An incident is any unplanned event occurring that requires further investigation. In testing this translates into anything where the actual result is different to the expected result. An incident when investigated may be a defect, however, it may also be a change to a specification or an issue with the test being run. It is important that a process exists to track all incidents through to closure.
Incidents can be raised at any time throughout the software development life cycle, from reviews of the test basis (requirements, specifications, etc.) to test specification and test execution.
Incident management, according to IEEE 1044 (Standard Classification for Software Anomalies), is �The process of recognizing, investigating, taking action and disposing of incidents.� It involves recording incidents, classifying them and identifying the impact.
The process of incident management ensures that incidents are tracked from recognition to correction, and finally through retest and closure. It is important that organizations document their incident management process and ensure they have appointed someone (often called an incident manager / coordinator) to manage / police the process.
<<<<<< =================== >>>>>>
Q. 139: What are the general objectives of Incident reports?
Incidents are raised on incident reports, either electronically via an incident management system (from Microsoft Excel to sophisticated incident management tools) or on paper.
Incident reports have the following objectives:
1) To provide developers and other parties with feedback on the problem to enable identification, isolation and correction as necessary. It must be remembered that most developers and other parties who will correct the defect or clear up any confusion will not be present at the point of identification, so without full and concise information they will be unable to understand the problem, and possibly therefore unable to understand how to go about fixing it. The more information provided, the better.
2) To provide test leaders with a means of tracking the quality of the system under test and the progress of the testing. One of the key metrics used to measure progress is a view of how many incidents are raised, their priority and finally that they have been corrected and signed off.
3) To provide ideas for test process improvement. For each incident the point of injection should be documented, e.g. a defect in requirements or code, and subsequent process improvement can focus on that particular area to stop the same defect occurring again.
<<<<<< =================== >>>>>>
Q. 140: What are the general contents of an incident report?
The details that are normally included on an incident report are:
1) Date of issue, issuing organization, author, approvals and status.
2) Scope, severity and priority of the incident.
3) References, including the identity of the test case specification that revealed the problem.
4) Expected and actual results.
5) Date the incident was discovered.
6) Identification of the test item (configuration item) and environment.
7) Software or system life-cycle process in which the incident was observed.
8) Description of the incident to enable reproduction and resolution, including logs, database dumps or screenshots.
9) Degree of impact on stakeholder(s) interests.
10) Severity of the impact on the system.
11) Urgency/priority to fix.
12) Status of the incident (e.g. open, deferred, duplicate, waiting to be fixed, fixed awaiting confirmation test or closed).
13) Conclusions, recommendations and approvals.
14) Global issues, such as other areas that may be affected by a change resulting from the incident.
15) Change history, such as the sequence of actions taken by project team members with respect to the incident to isolate, repair and confirm it as fixed.
As per IEEE 829 an outline of a test incident report contains different sections shown in following table.
| Section No. | Heading | Details |
| 1 | Test incident report identifier | The unique identifier assigned to this test incident report |
| 2 | Summary | A summary of the incident, detailing where expected and actual results differ, identifying at a high level the items that are affected, and the steps leading up to the recognition of the incident, e.g. if in test execution, which test was executed and the actual keystrokes and data loaded |
| 3 | Incident description | A detailed description of the incident, which should include:
# Inputs # Expected results # Actual results # Anomalies # Date and time # Procedure step # Environment # Attempts to repeat # Testers’ comments # Observers’ comments Should also include any information regarding possible causes and solutions |
| 4 | Impact | If known, document what impact the incident has on progress |
Part – 29 of the Crash Course – ISTQB Foundation Exam
Access The Full Database of Crash Course Questions for ISTQB Foundation Level Certification
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.