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:

This is pretty open right?

Now my testing notes may look something like this:

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:

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:

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

This post is also shared on the House of Test blog:

For more plenty of more tips targeted at beginners, check out my eBook: Starting Your Software Testing Career.

#Ideas #Learning and Improvement #Starting in Testing #Testing