Stretch tasks Testing and evaluation

Round 1: Quiz Blitz

1. A title of exactly 50 characters Boundary data sits right at the edge of what is allowed: 1 character or 50.
2. Compatibility Compatibility testing makes sure it works across devices.
3. Robustness Robustness is how well the app copes when things go wrong.
4. False Tests that pass prove little. The value is in the tests that find the problems.
5. Test data; Expected result; Actual result What you test with, what should happen, and what did happen.
6. Fix the code, then run the test again A failed test is a bug report. Fix it, then retest to prove the fix works.
7. Re-read the original requirements → Check each one: met, partly met or not met → Note what testers struggled with → Decide what to improve next Start from what you promised, judge it honestly, then plan the next version.
8. Three of five testers could not find Delete, so I would move it into each task Specific evidence plus a planned improvement shows real understanding.
9. True If they need help, the design needs work.
10. To check the app rejects it politely instead of crashing Real users type silly things. The app should cope with a helpful message.
11. functionality Functionality testing checks each feature against the requirements.
12. You know where everything is, so you miss what confuses others Watch someone else and count how often they hesitate.

Round 2: Quick Fire

1. • They show the bugs and problems that need fixing
   • Finding them before users do is the point; tests that pass prove little
   Model answer

   A failing test finds a bug or problem that needs fixing, before real users find it. Tests that pass only confirm what you already expected, so they prove little.

2. • Normal: an age such as 15
   • Boundary: 13 or 18
   • Erroneous: a value such as 12, 19 or a word
   Model answer

   Normal: 15. Boundary: 13 or 18. Erroneous: hello, or 19, which is outside the range.

3. • Functionality testing checks each feature works as its requirement says
   • Usability testing checks a real person can use it easily without help
   Model answer

   Functionality testing checks that each feature works and does what its requirement says. Usability testing checks that a real person can actually use the app easily, without help.

4. • The design is unclear: the button is hard to find
   • Move it, make it bigger or clearer, then test again
   Model answer

   It tells me the design is unclear: the save button is hard to find. I would move it somewhere more obvious, make it bigger with a clear label, and then test again with new users.

Round 3: Big Think

1. • A normal test, such as adding Maths homework, which should be added
   • An erroneous test, such as an empty title, which should show a message
   • A boundary test, such as a title at the maximum length
   • Each test has an expected result to compare with the actual result
   • The tests catch crashes and bugs before users meet them
   Model answer

   Test 1 is normal data: a task called Maths homework, with the expected result that it is added to the list. Test 2 is erroneous data: an empty title, which should show a message asking for a title rather than crashing. Test 3 is boundary data: a title of exactly the maximum length, which should be accepted without overflowing the box. For each one I would record the expected result and compare it with the actual result, because the tests that fail show the crashes and bugs to fix before users find them.

2. • It gives no evidence and is not specific
   • It does not check the app against the original requirements
   • It is not honest about problems: it only gives positives
   • A strong one uses test results and watching real users
   • It says which requirements were fully met, partly met or not met
   • It says what to improve or do differently next
   • It gives a specific example, such as three of five testers struggling
   Model answer

   The statement is weak because it gives no evidence and is not specific: it does not say which features were tested or how many people tried it. It does not check the app against the original requirements, and saying everything is perfect is not honest, because every app has weaknesses. A strong evaluation goes back to the requirements and says which were fully met, partly met or not met, using test results and evidence from watching real users. It is honest about problems, for example: three of five testers could not find the delete button. Finally it says what would be improved next, such as moving the delete button into each task.

This or That

1. Adding a task with an empty title Tests that might fail, such as empty or extreme input, are the ones that find problems.
2. Robustness Robustness is how the app copes with no internet, empty lists or silly input.
3. The test passed When the actual result matches the expected result, the test passes.
4. Actual result You decide the expected result before testing, then record what actually happened.
5. By checking each original requirement Go back to the requirements and check them one at a time: met, partly met or not met.
6. banana Erroneous data is the wrong type entirely, and the app should reject it politely.
7. The screen needs redesigning Wherever users hesitate is a design problem, not a user problem.
8. What you would improve or add next A good evaluation says what you would do differently and what you would add next.

Memory Match

• A 5 Functionality: Every feature does what was required
• B 4 Usability: A real person can finish tasks without help
• C 6 Compatibility: Works on different screens and devices
• D 3 Robustness: Copes with no internet or silly input
• E 1 Test plan: A table of tests, data and expected results
• F 2 Evaluation: Checking the finished app against its requirements