Testing from scratch: a learning route

Month one: the foundations

What testing is and why. Not "finding bugs" but reducing the risk that the product doesn't work for people. The difference is one of mindset, and it's noticed at interview.

Types and levels. Checking new functionality versus checking nothing old broke; testing a component versus the whole system; manual versus automated.

Test design techniques. Equivalence partitioning, boundary values, decision tables. It sounds dull, but this is exactly what separates a systematic tester from someone poking at random.

The bug lifecycle. From discovery to confirmation of the fix.

Month two: practical skills

Writing test cases. Clear steps, expected results, preconditions.

Writing bug reports. The most important skill; it gets an article of its own.

Working with issue trackers. Creating, linking, following up.

Browser developer tools. Network requests, the error console, inspecting markup. Needed to tell an interface failure from a server one.

Month three: the technical side

How the web works. Requests and responses, status codes, headers. Without this you can't state clearly where something broke.

Testing service calls. Send a request by hand, read the response, check behaviour with invalid data.

Databases. Selecting with a condition and joining two tables. Needed to verify that data really was saved.

Command line basics. Reading logs, starting an application.

Month four: going out

By now you can compile a test set for a section, find and describe a bug clearly, exercise a service call, and inspect data in a database.

That's enough to start applying. The rest accumulates faster in practice than in preparation.

How long it takes

Three to five months at a couple of hours a day. Faster than development — hence the reputation for an easy entry.

A caveat: faster doesn't mean easier. A good tester is someone who can think about how things might break, and that's a distinct cast of mind. People who come "because it's easier" usually hit a ceiling quickly.

What to do while you have no experience

Test existing services. Take an application, build a test set for one section, find bugs and write them up properly. Publish it — that's already a portfolio.

Find bugs in open source. Report them by the project's rules. An accepted bug report is public proof of your skill.

Test somebody's pet project. The most valuable option: a live author, discussion of priorities, and the need to explain why a defect should be fixed. That's closest to the real job.

The last also solves the beginner's main problem in testing: without a job there's nowhere to show you can work with developers. And that's half the profession.

Where to grow next

Test automation is the most in-demand direction. The move takes six months to a year and raises the pay bar noticeably.

Less commonly: into development, analysis or product management. Testing gives a good understanding of how the whole thing fits together, which is decent starting capital.