Complete the form together before class. Leave gray tutor fields and signatures empty. Testing must be systematic: follow a plan, record what was done, and report what happened. Aimless clicking is not enough.
A1 is assigned by the tutor. Choose a short name in A2, such as Registration Browser Test. Use B1-B4 for the requesting and testing teams.
Use C1-C3 to freeze exactly what will be tested: a deployed address, package, commit, tag, or release. A GitLab reference is an exact pointer, such as courses/team-fox/app plus release v0.3.0, commit a1b2c3d4, or file path.
In C4-C6, provide installation and usage instructions, test accounts/data, configuration, known limits, and unsafe actions to avoid.
Select the quality focus in D1-D2. In D3, write a question testing can answer; in D4, explain why the answer matters.
Use E1 for included flows, E2 for exclusions, and E3 for exact browsers, devices, operating systems, or environments.
Select at least one method in F1-F4 and complete its details. Written cases specify input, steps, and expected result. A user journey follows a realistic goal. An exploratory charter defines area, goal, risks, and time box. Input combinations name categories to cover. Use F5 for another repeatable method.
Choose report requirements in G1-G6. Do not require a fixed number of defects: passed tests and “no defect observed” are valid results. Put measurable additions in G7.
Use H1 for the planned test-report location. Select separate defect issues in H2 when reproducible problems should be tracked. Use H3-H5 for logs, screenshots, explanation, and report structure.
Write whole points in I1 and an exact fixed deadline in I2, for example 2026-10-19 23:59. Use J1 only for non-conflicting additions.
The requesting team confirms whether the agreed testing and reporting were completed; it cannot reject the work simply because few defects were found. Required representatives sign K1-K2 in person. The tutor fills A1 and L1-L4.