FREE SOFTWARE TESTING LEARNING PATH

WikiFree original practice workbook

The test matrix

CASE STATUS: fictional/synthetic teaching material. Do not present the example as real research, employment experience or measured business performance.

OUTCOME
Design and execute a small manual test suite, report a reproducible defect and verify a fix against a shipping-price specification.

BEFORE YOU START
Basic browser use and arithmetic. Coding is optional; the supplied practice page can be opened locally.

CASE
The fictional Ash Delivery calculator accepts an integer quantity from 1 through 10. Shipping costs 5+2×quantity units. Members receive a fixed 3-unit reduction. A deliberately faulty practice version rejects quantity 10, giving learners a real boundary defect to investigate.

INPUTS
Quantity,Member,Expected shipping
1,No,7
1,Yes,4
10,No,25
10,Yes,22
0,No,Invalid
11,No,Invalid


ENTRY CHECK

Question: Is a test case just a click sequence?

Self-check: It also needs a condition and an expected observable result.

Question: Does one passing example prove correctness?

Self-check: No.

Question: Is severity the same as fix priority?

Self-check: No. Impact and scheduling are related but distinct.

STAGE 1: Turn the specification into checks

Prerequisite: Basic browser use and arithmetic. Coding is optional; the supplied practice page can be opened locally.

Instruction: A requirement must be precise enough to judge an outcome. Identify the accepted quantity range, integer rule, price formula and member discount. Separate valid behavior from rejection behavior. The provider videos are short introductions, so the original specification and hands-on exercises carry most of the practice in this path.

Practice task: Write four testable requirements and a coverage table linking each to at least one planned case.

Deliverable: A requirement-to-test map.

Acceptance check: The integer rule, inclusive upper boundary and once-per-order discount are explicit.

If stuck: If expected behavior uses words like reasonable, replace them with a concrete result.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 2: Select useful partitions and boundaries

Prerequisite: Bring your previous output: A requirement-to-test map.

Instruction: Partition inputs into groups expected to behave similarly, then test boundaries where behavior can change. For quantity, include below range, minimum, ordinary valid, maximum and above range. Add decimal, blank and nonnumeric values. Combining every possible input is unnecessary here, but omitting the upper boundary leaves a meaningful risk uncovered.

Practice task: Create at least ten cases with input, membership, expected outcome and requirement ID.

Deliverable: A compact boundary-focused test suite.

Acceptance check: Cases include 0, 1, 10, 11, 1.5, blank and text input, plus both membership states.

If stuck: Do not fill the suite with ten ordinary middle-range values.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 3: Execute and preserve evidence

Prerequisite: Bring your previous output: A compact boundary-focused test suite.

Instruction: Execution records actual behavior, not what should have happened. Record the practice-page version, browser and the input used. Mark a case pass, fail or blocked with a concise reason. Screenshots can support a report, but exact values and steps make it reproducible. Keep unexecuted cases visibly unexecuted.

Practice task: Run the suite against the intentionally faulty page. Record the quantity-10 result and all other observed outcomes.

Deliverable: An executed test log with version and environment.

Acceptance check: The upper-boundary defect is reported as observed, with expected 25 or 22 depending on membership.

If stuck: Never prefill pass statuses from the expected-results column.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 4: Write a useful defect report

Prerequisite: Bring your previous output: An executed test log with version and environment.

Instruction: A defect report should contain a short title, preconditions, minimal steps, expected result, actual result and impact. Separate severity from proposed priority. A static review may reveal an incorrect comparison, but a reproducible runtime example explains why that code matters. Keep the report focused on one problem so the fix can be checked clearly.

Practice task: Write a report for quantity 10, including exact inputs and a suggested regression case.

Deliverable: A reproducible boundary-defect report.

Acceptance check: Another learner can reproduce the failure from the report without guessing membership or version.

If stuck: Avoid vague titles such as calculator broken when the failure is a specific inclusive boundary.

Record your work, decisions and evidence:




Record your result against the acceptance check:



STAGE 5: Retest the fix and report residual risk

Prerequisite: Bring your previous output: A reproducible boundary-defect report.

Instruction: Retesting checks the original failing case on the corrected version. Regression testing checks nearby behavior that the change might affect. The fixed page should accept 10 while still rejecting 11 and decimals. A completion report states what was tested, the result and what remains outside scope; it does not promise the absence of all defects.

Practice task: Run the failing case and nearby boundaries against the reference fix. Write a short release recommendation for the practice app.

Deliverable: A retest log and bounded quality summary.

Acceptance check: Quantity 10 succeeds; 11 and decimals remain invalid; the tested version is identified.

If stuck: Do not close the defect after checking only that the edited code looks right.

Record your work, decisions and evidence:




Record your result against the acceptance check:



WORKED CASE
The faulty comparison excludes 10 even though the specification includes it. Expected shipping for ten nonmember items is 25. A meaningful retest checks that correction and confirms that 11 still fails.

FINAL PROJECT
Deliver the requirement map, test suite, execution log, defect report and retest summary. Add a new requirement that the discount never changes quantity validation and design two cases to cover it.

REQUIRED CRITICAL CHECK
Actual execution results are recorded honestly and the boundary fix is retested without weakening input validation.

SCORING
Score each of the five stage acceptance checks from 0–16 (0 missing/incorrect; 8 partially supported; 16 complete and evidenced). Score the final integrated project from 0–20 (0 missing; 10 incomplete handover; 20 complete, reproducible and consistent with the case). Target: at least 80/100 AND the critical check must pass. A total score never overrides a failed critical check.

SCOPE LIMIT
The short provider videos introduce terminology; this path is not complete ISTQB preparation, certification or exhaustive application testing.

SOURCES AND ACCESS
Assigned public videos can be watched free. Complete the original case in a text editor, on paper or in a spreadsheet you already have. No paid course, exam or provider certificate is included.

Free Simplilearn Course: Software Testing Foundations and Test Design
WikiFree: https://wikifree.com/courses/free-simplilearn-software-testing-foundations-and-test-design/
Official source: https://www.youtube.com/playlist?list=PLEiEAq2VkUUJjXzWoRYP2QsMN-SqID1-y
Why selected: The existing short software-testing lessons provide terminology and lifecycle context; the original faulty app, specification and execution work build practical depth.

Stage 1 selected lessons:

1. Introduction To CTFL Training Course — Certified Tester Foundation Level (6:11)
https://www.youtube.com/watch?v=slNGfHRv4xQ&list=PLEiEAq2VkUUJjXzWoRYP2QsMN-SqID1-y&index=1

4. Fundamentals of Software Testing — Introduction to ISTQB — What is Testing? (3:02)
https://www.youtube.com/watch?v=ay6QJrgucG8&list=PLEiEAq2VkUUJjXzWoRYP2QsMN-SqID1-y&index=4

Stage 2 selected lessons:

6. Test Design Techniques — Common Testing Terms — CTFL Tutorial Videos — CTFL Certification (2:55)
https://www.youtube.com/watch?v=FvDNYbA3nsQ&list=PLEiEAq2VkUUJjXzWoRYP2QsMN-SqID1-y&index=6

Stage 3 selected lessons:

2. Software Development Models — What is SDLC? — Software Development Life Cycle (3:02)
https://www.youtube.com/watch?v=IKkPXpUKp8Q&list=PLEiEAq2VkUUJjXzWoRYP2QsMN-SqID1-y&index=2

5. Types Of Testing Tools — How to Use Testing Tools? — CTFL Video Tutorials (3:02)
https://www.youtube.com/watch?v=feHmUjLCQQM&list=PLEiEAq2VkUUJjXzWoRYP2QsMN-SqID1-y&index=5

Stage 4 selected lessons:

3. What is Test Management ? — What is Test Organization? — CTFL Online Certification (3:02)
https://www.youtube.com/watch?v=0Naogn0zZ58&list=PLEiEAq2VkUUJjXzWoRYP2QsMN-SqID1-y&index=3

7. Static And Dynamic Techniques — Static Analysis — CTFL Online Certification Course (3:01)
https://www.youtube.com/watch?v=XdIh0em8vJ4&list=PLEiEAq2VkUUJjXzWoRYP2QsMN-SqID1-y&index=7

REUSE
Original WikiFree teaching text and synthetic fixtures are supplied for personal learning and adaptation with attribution. Provider lessons remain on their original sites and retain their own terms. No provider certificate is included.