4 testing tips for beginners

New to testing?

In your first year as a software testing?

Here are 4 useful testing tips for beginners.

1. Explicitly State your Assumptions

Before I start testing (and ideally before the developers start coding), I like to go through the requirements/acceptance criteria/user stories, then write testing notes on my assumptions. That is, based on what I have read, what am I assuming?

Not all of the expected behaviour of the application/feature will ever be explicitly stated, a lot of expected behaviour is implied – therefore it’s useful to state your assumptions and then either tag the developers/ business analyst in your comments or share your thoughts with them face to face.

While doing this, I also like to state how I would test the application/feature, based off my assumptions – this doesn’t have to be written test cases, but more like test ideas; this is followed by the sort of behaviour I would expect for each test idea. (This isn’t a promise to the developers that this is exactly what I would test, but more like an indication of what I plan to cover, at this point in time.)

If stating my assumptions is not enough to clearly communicate how I plan to approach testing an application/feature, then stating how I would test the application/feature tends to do the trick.

Here’s an example:

Let’s say you’re building a bed eCommerce site  and you want to add functionality so that on the Search Results page, the user can now filter based off the width of the bed. (For this case, let’s assume we don’t have any designs either for this feature, because the designers are busy)

The acceptance criteria would say:

  • As a user, I can search for beds and filter by width.
  • As a website owner, I can add the width as a searchable characteristic of each bed.

This is pretty open right?

Now my testing notes may look something like this:

  • I assume that the searchable widths are 90cm, 120cm, 140cm, 160cm and 180cm.
  • If my assumption is correct, do we have any beds that do not fall into one of the above categories, if so, what would happen to them?
  • I assume this is a checkbox filter (that is, users can apply multiple widths to the search).
  • I assume it’s possible to clear the filter
  • I assume the width of a bed MUST be added for a bed to be added to this website.

2. Test in the gaps

In general, I have found that you’re more likely to find bugs in areas that aren’t explicitly stated on the  requirements/acceptance criteria/user stories.

Most developers (I have worked with) tend to write their code with a focus on making sure the behaviour is as stated on the requirements/acceptance criteria/user stories. Therefore, chances are those scenarios tend to work.

 But the gaps? The grey areas?

That’s where things get interesting.

To expand on my first tip, try and read the requirements/acceptance criteria/user stories and ask yourself:

  • What scenarios are not covered?
  • What could a user do that is not explicitly stated?
  • What if X? What if Y?

Then focus on those scenarios and see what happens.

3. Instead of “How can I prove it works?” ask yourself: “How can I prove it doesn’t work?”

This is similar to my previous point – in assuming that most developers (I have worked with) tend to write their code with a focus on making sure the behaviour is as stated on the requirements/acceptance criteria/user stories.

But here, the mindset is even more different. You’re not trying to prove the application/feature works, but instead you are trying to focus on test ideas that prove the application/feature does not work.

If you want to practice how to do this, try playing the dice game. 

4. Learn how to write a clear, actionable bug report.

I’ll probably go into this more in a future blog post but at the very least your bug report should include the following information:

  • Actual behaviour
  • Expected behaviour
  • Steps to replicate
  • Screenshots/screen recording
  • If it can’t be replicated or difficult to replicate consistently, state this.
  • Build version

One very useful thing I learned in the BBST Bug Advocacy course a few years ago is also to pay attention to formatting so your bug reports are easy to read.

For example: Utilise bold or underlines for the section headings (such as Actual behaviour or Steps to replicate); utilise numbered lists for Steps to replicate.

Please do NOT ever write “the XXX doesn’t work”. This isn’t helpful. If something doesn’t work, explain clearly what exactly happened? What were you expecting? What error appeared? etc

Leave a Reply

Your email address will not be published. Required fields are marked *