EASEBRAIN ACADEMY — OFFLINE MISSION PACK

Automate a small thing

https://easebrain.live/curriculum/automate-a-small-thing


CHALLENGE

Build a small spreadsheet, block-code or text-code tool that supports your project. Test normal inputs, edge cases and recovery from an error.


LEARNING OBJECTIVES

Clean a small dataset without silently changing its meaning.

Explain a rule and test missing, normal and boundary inputs.


LEARN & APPLY

1. Describe the rule
Inputs are the information a system receives. Rules transform them into outputs. Start with a written example so another learner can predict the result.
Practice: Write an input-rule-output diagram.

2. Build the smallest useful version
Choose a spreadsheet or coding tool that matches the task. One clear working rule is more valuable than many unexplained features. Keep versions so you can compare changes.
Practice: Build a minimal version and save an example input and output.

3. Test the awkward cases
Check empty input, unexpected values and boundaries. Explain errors clearly and preserve the user’s work where possible. Do not hide failure behind a success message.
Practice: Record at least five tests, including two edge cases.


WORKED EXAMPLE

Readings are 10, 12, 11, 50 and blank. The mean of four observed values is 20.75; the median is 11.5. Blank is missing, not zero. The 50 may be genuine or an error: investigate and document your decision rather than deleting it.


YOUR PRACTICE QUESTION

What happens if the blank is silently changed to zero?

Write your answer before reading the explanation below.


EXPLANATION

The mean becomes 16.6 across five values, changing the claim. A missing-value policy and data dictionary must say what is absent, which units apply and how the summary is calculated.


STRETCH

Build a spreadsheet or block-code version and compare it with hand calculations. Include five tests and a clear error message.

PRACTICAL: Build a rule you can trace

Suggested time: 60–90 minutes

Illustrated crew scenario (fictional learning example)

My cost calculator works for 30 units.

What does it do with zero, a blank entry, −2, or the word ‘thirty’?

PREDICT: Why should a blank input not quietly become zero?

STARTER: Build a cost calculator on paper, in a spreadsheet or JavaScript. Inputs: quantity, price and unit cost. Formula: quantity × (price − unit cost). Use the budget lab as a reference result, not as a substitute for your own build.

1. Trace variables and a condition
A variable names a value. Write quantity=3, price=250, unitCost=170. Trace the multiplication to 240. A condition chooses a branch: if quantity is missing, nonnumeric, negative or not whole, show an explanatory error.

2. Build and repeat
Implement the formula and validation in your chosen medium. A function groups that operation; a loop can run the same function on several test rows. Do not use eval or execute user-entered code.

3. Test boundaries
Record expected and actual results for 3, 0, blank, −2, ‘thirty’, and 1.5 units. Zero is valid; blank and the last four invalid cases must not become a believable total. Fix and rerun failures.

COMPARE AFTER TRYING: For 3 units at 250−170, the result is 240. For 0 it is 0. Number('') produces 0 in JavaScript, so check an empty string before conversion. A good failure message says which input needs correction. Testing one ordinary example misses that bug.

SELF-CHECK

I can explain each variable and condition.

My log contains normal, zero, blank, negative, text and fractional-quantity cases.

Invalid entries produce a useful message and the corrected tests pass.

TRANSFER: Extend to two products using a list and a loop. Explain whether prices may contain decimals while quantities must remain whole.

WORKBOOK TEMPLATE

Input | Expected output | Actual output | Pass/fail | Fix
Variables and units:
Rule or pseudocode:
Test 1 normal:
Test 2 zero:
Test 3 blank:
Test 4 negative:
Test 5 text:
Test 6 fractional quantity:


EVIDENCE CRITERIA

Explainable rules or code

Working normal example

Edge cases and one revision documented

Deliverable: Tool or model, examples and test log


SESSION PLAN (adapt with your facilitator)

Recall & plan: 30 minutes

Model & discuss: 45 minutes

Guided practice: 75 minutes

Build & test: 120 minutes

Feedback & revise: 60 minutes

Reflect & next step: 30 minutes


RESOURCES

MakeCode micro:bit simulator — https://makecode.microbit.org/device/simulator

Kenya National Bureau of Statistics: Statistical Abstracts — https://www.knbs.or.ke/statistical-abstracts/


AI DISCLOSURE TEMPLATE

Tool/version; date; task; information shared; claims checked and sources; what I changed; what I can explain myself.


No AI or equipment purchase is required. Keep personal information out of project evidence.