My introduction to software testing

Testing can start before there is anything to run

One idea that stayed with me was that testing can begin while a feature is still being discussed. A written requirement can sound clear until two people explain what they think it means. Asking for an example, questioning an assumption or reviewing a design can reveal a problem before anyone has written the code. That makes testing part of the conversation about what to build.

For a course exercise, I considered software used in Cornwall's bus services. I listed things such as journey planners, payments, live tracking, disruption alerts and maintenance systems. It helped me think beyond the visible app: passengers and the people running a service need different information from the same wider system. This was an exercise in considering uses of software, not a test of any bus service.

Taking a journey planner as an example, “show the next bus” leaves room for questions. Does that mean the scheduled departure or an estimate based on live information? What should a passenger see when that information is unavailable? A design review could look at whether the distinction is understandable. During development and release, checks could examine whether the agreed behaviour works in the intended environment. Once people use it, monitoring and feedback could reveal where the information is failing them. Those are possible lines of investigation, but they helped me understand how testing can continue through the life of a feature.

An expectation and an unanswered question

I found it useful to separate checking an agreed expectation from investigating something we do not yet understand. An agreed rule gives a test a basis for comparison. A risk or unknown gives us a reason to explore. Both can tell us something valuable, but they do not start from the same position.

The comment-box example in my notes makes this concrete. If the agreed rule says a comment cannot be blank, submitting an empty box has a clear expected result: it should not create a comment. Spaces, emoji and symbols bring up further questions. Do spaces count as content? Are they removed before validation? Which characters should the feature support? These are examples I considered, not results from an application I tested. Without clarifying the rules, it is easy to label behaviour a bug simply because it differs from my assumption.

The same thinking applies to risk. A feature might satisfy a narrow requirement while still being confusing or inaccessible. I learnt to think about who could be affected and what the consequences could be. That gives testing a direction, especially when there is more to investigate than time allows.

Giving checks and exploration some structure

Written test cases made me think more carefully about the details needed to repeat a check. A case needs a clear starting point, the data to use, steps to follow and an expected outcome. When it is run, the actual result needs to be recorded separately. Something that feels obvious while I am using a feature may be far less obvious to the next person reading my notes.

I also learnt why a set of written cases cannot cover everything worth noticing. Exploratory testing gives room to follow a question, observe what happens and use that information to choose the next step. The direction can change as understanding improves, rather than being fixed entirely in advance.

That does not mean random clicking. A charter can give a session a purpose, such as exploring how a form handles unexpected input. Notes can capture what was tried, what was observed and what still needs investigation. A debrief then makes that learning available to other people. I found this helpful because it gives exploration enough structure to explain its value without pretending every step was planned beforehand.

Ad hoc checking is closer to the quick, informal checks I recognised from coding. It can help me learn something about a change with little preparation. The distinction I took from the course is that purposeful exploration needs more attention to its focus and record. Quick checks have a place, but relying on memory makes it difficult to say afterwards what was actually covered.

Where acceptance, automation and monitoring fit

User acceptance testing helped connect these activities back to the reason for building the software. Its focus is whether the product meets the needs and expectations of the business or end user. It can involve written cases and exploration, with people such as a product owner or business analyst helping to judge whether the delivered behaviour is useful. Working code alone does not answer that question.

I learnt to see automation as support for testing. A tool can repeat a defined check or help gather information, but a person still has to decide what matters, interpret the evidence and investigate new questions. I have also tried Selenium IDE in a practical exercise. That was an introduction to browser automation, and I still have more to learn about choosing useful checks and maintaining them.

Monitoring extends the picture after release. Information about availability, errors or how a product is being used can draw attention to problems that need investigation. It does not prove that everything is correct, but it can provide feedback from an environment that matters to users. This was another reminder that testing is not finished simply because a release has gone out.

Making a finding useful to someone else

Finding something unexpected is only part of the work. A useful defect report needs to help another person reproduce it and understand why it matters. From my development work, I can see how much harder it is to investigate a report that only says something does not work. The course made me pay more attention to the information that closes that gap:

• The starting conditions, test data and reproducible steps.
• The expected result, its basis, and what actually happened.
• The environment and software version, with relevant evidence such as a screenshot or log.

Explaining the effect on the user matters too. A screenshot might show a symptom, but it may not explain what task is blocked or how often the problem occurs. Keeping observations separate from guesses about the cause should make a report clearer and easier to investigate.

My notes also challenged the idea that a bug count says much on its own. Several small presentation issues and one problem that prevents an important task are very different situations. Counts can help describe progress, but they need context about impact, coverage and what remains unknown. I took away that a useful testing update should explain what has been learnt, not just how many items have been recorded.

What I want to carry into my next exercise

A recent practical recruitment exercise gave me a chance to review user stories, consider risks, design and run tests, and record defects. Writing clear tests took more time than I expected. My exploratory work also found things my structured cases had missed. I am keeping the exercise materials and specific findings private, but that contrast gave me something useful to reflect on.

I want to get better at documenting results clearly enough that somebody else can follow the work without needing me beside them. That means giving the starting conditions enough attention, recording evidence as I go and making gaps visible. I also want to keep using both structured checks and exploration on my own projects, then review where each approach helped.

Completing this introduction has given me a starting point for more practice. I am still learning, but I now think more about what a check tells me and how to communicate it. If you would like to discuss my learning or my development work, you can get in touch through my contact section.