Disclaimer, following article is my own writing based upon the ISTQB Foundation Level Syllabus, which is owned and copyrighted by the ISTQB.
The following are my notes for Chapter 5 - Test Management
5.1 Test Organization
Tester: The person who tests a system
Test leader/manager: The person responsible for project management of testing activities and resources, and evaluation of a test object. The person who directs, contorls, administers, plans and regulates evaluation of the test object.
There are tradeoffs to have testers more or less independent of the developers. The benefits of indepdence are the avoidance of bias, and the verification of assumptions mande during speification and implementation. The drawbacks are isolation from the development team, developers' losing their sense of responsibility for quality, and testers being viewed as a bottleneck/delay in release (due to developers losing sense of responsibility)
We will distinguish between two broad testing roles: Tester and Test Leader.
The test leader is generally responsible for creating and coordinating test strategy with other project leaders and providing the testing perspective in other departments' strategy planning. They initiate each step of the testing processset up metrics, select tools, automation and environment, and write summary reports.
The tester is responsible for contributing to test plans, reviewing test plans, requirements and specifications, setting up the test environment, preparing test data, implementing tests, using any monitoring tools specified, measuring the performance of systems, and reviewing other testers' tests.
Note that specialists can exist. An automation pro may handle only the environment setup and implementation of regression tests, for example. In general, "Tester" is just a hat worn by anyone who happens to be doing some testing.
5.2 Test Planning and Estimation
Test Strategy: A high-level description of the test levels to be performed, and the testing withing those levels.
Test Approach: The implementation of a test strategy, usually in the form of test plans.
Test planning is an ongoing process throughout the life cycle, accounting for the objectives, risks and resources available to the tester. Test planning involves identifying those factors, defining an approach for testing, integrating test activities into the overall software development lifecycle, scheduling test activities and assigning resources, defining the format of test documentation and selecting metrics.
Test planning determines not only the levels of testing to be used, but also the entry and exit criteria for each level. Typical entry criteria might be environment and tool readiness, or testable code and data availability. Typical; exit criteria might be code coverage, unresolved risks, cost or time limits.
The amount testing effort needed for a project can be estimated in two ways: metrics based on similar projects, or expert analysis. The test effort can vary depending on many factors in the product itself (size, complexity, spec detail), the development process (stability of team, tools used, skills). The outcome of testing also matters (number of defects,a nd debugging effort necessary).
A Test Approach is the starting-point for the creation of test plans. It might be an Analytical apprach ("create tests according to where we see the most risk"), Standard-compliant (follow what is demanded of you), Dynamic (exploratory), or something else. Different approaches can be combined.
5.3 Test Progress Monitoring and Control
Defect density: The number of defects identified in a system divided by the size of the system
failure rate: The ratio of failures in a category to some unit of measure (e.g. time)
test control: The test management task which involves developing and applying corrective actions to get a test project on track when monitoring shows deviation from what was planned.
test monitoring: The test management task of checking the status of a test project to compare against the plan of the project.
test summary report: A document summarizing test activities, results, and evaluation of test items against exit criteria.
Test monitoring is meant to provide both visibility and feedback to test activities. Monitoring may be manual or automatic, and typically is used to compare against a planned schedule and budget. Some common metrics are percentage of preparation done, defect density found, test coverage of requirements, etc.
Test reporting involves summarizing information about the testing endeavor, including what happened (dates when exit criteria were met), and metrics + analysis to support decisions about future actions.
Test control means applying guidance / corrective actions, usually as a result of test monitoring and reporting. Tests might be reprioritized and rescheduled, the core testing process might be changed (additional entry / exit-criteria), etc.
5.4 Configuration Management
Configuration management: The discipline of identifying, documenting, controlling and reporting changes to functional and physical characteristics of a configuration item.
Version control: A kind of configuration control, consisting of the evaluation, approval/disapproval and implementation of changes to a configuration item. Typically the configuration item is the build-version of the system being tested.
Configuration management is a necessary task in the testing process. The system being tested must have its version trakced and controlled so that traceability can be maintained.
5.5 Risk and Testing
Risk: A factor that could result in future negative consequences, usually expressed as impact and likelyhood.
Product risk: A risk relating directly to the product (e.g. unreliable behaviour, extremely damaging failures)
Project risk: A risk related to the management and control of the (test) project. (e.g. lack of staff, strict deadlines, changing requirements)
Risk-based testing: An approach to testing to reduce the level of product risk and inform stakeholders of their status. Identify product risks early, and use those risk levels to guide the test process.
Nothing to add that wasn't covered in the definitions
5.6 Incident Management
Incident management: The process of recognizing, investigation, taking action and disposing of incidents.
Incident logging: Part of incident management, involves the recording the details of any incident that occured (e.g during testing)
Incident report: A document reporting an event that occured
Since one of the objectives of testing is to find defects, the discrepencies between expected and actual events must be logged as incidents so that they can be investigated for defects. An incident resolution process should be decided, and incidents tracked from discovery to classification, correction and confirmation.
Incident reports exist to give developers and other parties the feedback they need to identify, isolate and correct issues as necessary. They also give test leaders a means of tracking the quality of the system under test, and to track testing progress.
An incident report might include the date, author, expected and actual results, identify the test item and environment, priority, incident status and so on.