Learning note / Reflections on my studies
Quality Assurance
Quality assurance makes me ask what evidence would show that software meets a need. A screen appearing correctly is useful, but it does not tell me how the application behaves in less convenient situations.
Deciding what should count as correct
I want to understand the expected behavior before deciding how to test it. Otherwise, a test can repeat the implementation's assumptions and pass while the underlying requirement is still misunderstood.
A useful check should make a claim about behavior that someone else can recognize.
Looking beyond the happy path
Missing input, empty results, repeated actions, and failed requests are all part of an application's behavior. I find these cases useful because they expose assumptions that a straightforward demonstration may never touch.
Reviews and tests also catch different kinds of problems. Reading the design can reveal a misunderstanding that checking one output would not.
Making a failure useful
The result I want from a failing check is a clearer next step: what was expected, what happened, and where to investigate. That makes quality work part of improving the software rather than a separate pass-or-fail ceremony.
What I take forward
- Start with an expected behavior.
- Check boundaries and failure paths.
- Make failures understandable enough to act on.