The 2 Minute Tester

By David Bruce

Discover the Perfect Guide to Become the Best QAT Tester in No Time.

This guide gives you 33 specific areas of testing that will improve your testing skills. Each section can be read in 2 minutes and contains specific actions you can take to improve your testing skills.

What you need are clear explanations and guidance

• Language: English
• Publisher: First Edition
• Release date: Jan 20, 2021
• ISBN: 9781838342418

Book preview

1 EXPLORATORY TESTING

You don’t have much time.

You don’t know the system.

They need it tested.

Exploratory testing is a useful technique when there isn’t much time available, you need the system tested quickly and you know little or nothing about the system under test.

The concept is to move fast and identify the weaknesses in the system.

Documentation is kept to a minimum, normally test collateral is limited to the outputs from testing (i.e. defects found). In some cases, for audit purposes, there may be a need to describe the exploratory approach.

Some approaches are:

1) Timeboxed: as time is usually a constraining factor, this is a frequent approach, for example, a 45-minute run.

2) Paired testing: this technique is useful, two testers work through the system under test and work as a team to test the system.

3) Pre-investigation: talking with devs and BAs to get an overview of the system, where the integration points and where the most complex areas are of the entire system. This is often a useful technique, especially where underlying documentation is either sparse or non-existent.

Image result for treasure map drawing free to use

You can execute exploratory testing at any time in the SDLC. It is often most effective either at the beginning or end of a specific test phase, for example, the start of UAT, or if operating in an agile manner, at the end of each sprint, once automated and other specific functional tests have been executed.

KEY TAKEAWAYS

✓ Keep it short in terms of time.

✓ Leave your documentation to the end, make notes as you go when you find defects.

✓ Focus on integration points.

2 EFFECTIVE TEAM WORKING IN QAT

‘Invert, always invert.’

– Charlie Munger

What makes an effective QAT team? Often it makes sense to invert the question. What makes an ineffective QAT team? If you have experience of more than a few years working in QAT, you will have seen or worked in, ineffective or worse teams. These normally share certain characteristics:

a) Siloed thinking: ‘Well, the bit I tested is fine, not my problem if there is an issue somewhere else.’

b) Sole fount of wisdom: ‘Bob is the only guy who knows how and what these tests actually do.’

c) We are at war with everyone!: ‘The devs hate us, the BAs hate us, hell, even the PM hates us!’

Doubtless you can think of more examples. The aim here is to look at what causes such problems and prevent them from occurring.

Tactics for avoiding them can be seen in the following:

1) Start with the whole solution in mind. While you may be testing one specific area of the system, how does it logically flow into the wider picture? For example, with 10 specific GUI screens under test, you may be responsible for 5, can you build a whole of system smoke test to exercise all 10, even though they are not specifically under your