This article is an extract from the book, What Did You Even Do? By Jake Bennett
All the applications on your computer have to be made by somebody. If somebody was writing a new calculator application, for instance, a software tester would check that it actually works. This means making sure that the add button allows you to add numbers, that each of the buttons for the numbers 0-9 work, that you can’t enter letters, and anything else you can think of. If the tester finds something that doesn’t work, they’ll report the problem. You’ll regularly hear this described as “Raise an issue”, “Log a ticket”, “Submit a bug report”, “Raise a bug”, or similar. This process would be the same for the calculator application I just mentioned, the latest computer game, software you need for work, an app on your phone, or anything else.
A software tester’s role can and often does include a whole host of other tasks, particularly as your career progresses. The average software tester does much more than just pushing buttons in an application to check that it all works.
Here is a list of tasks which a typical software test engineer might undertake, depending on the product being developed, the circumstances surrounding its development and their own skills and desires. It’s OK if some or all of these don’t make sense right now, we’ll be covering all of them in more detail as we progress.
- Run scripted test cases: Read a list of written instructions that tell you how to test a product, then follow the instructions to check the product does the expected thing. (These might be new tests for a new feature, or tests to make sure an old feature did not break in a new version or environment, for instance).
- Write bug reports: When the product does not perform as expected, write information describing the issue so that the team can consider fixing it.
- Investigate bugs: Often, as part of discovering a bug and writing the report, a tester will be required to investigate the problem. This could be things like: “Does it happen on all Windows versions?”, “Did the last version do it?” and so on. Further, sometimes the cause of a bug is not obvious, and so a tester may be required to collect additional data, perhaps even with a new version of the product, or even take additional requested steps in order to help narrow the problem down.
- Review requirements: All products will have requirements that must be met for the product to be useful and successful. On many projects there is an attempt to collect these in requirements documents, and Test Engineers will often review these. It is often possible to identify potential problems before even a single line of code has been written, such as when two listed requirements contradict each other, or if a written requirement is obviously wrong, or an important requirement is missing.
- Come up with new test cases: Each “Test case” is a test you can think to run. You may come up with new ideas for test cases by reviewing a requirements specification or other sources of information, and using various testing techniques. Most QA roles will involve this to some degree. Even if you’ve only been hired to run pre-planned tests, it’s likely that in the course of executing those you’ll come up with new ideas for tests which could be run.
- Write new test case instructions: Often (but not always!), when you come up with new test cases, it will be necessary to write up useful instructions so that others (or you!) can run them again at a later date, and/or to record exactly what tests have been run.
- Run test cases without writing scripts: This can take many forms. Often collectively referred to as “Exploratory testing”, it can involve running many tests with a shared theme, with the aim of trying lots of things (and hopefully identifying bugs) quickly, without the overhead of writing detailed instructions. It may instead involve writing short summaries of the overall testing completed.
- Collate results: When testing is complete, it may be necessary to collect metrics about how many tests were run, how many passed, failed, whether any had to be skipped for some reason, or were “blocked” by unavailable hardware or bugs in the product etc… It may be necessary to report this to stakeholders (like management) to aid in decisions about product readiness.
- Plan testing: All of this has to be done in a structured and managed manner, which means planning.
All the tasks listed above are those which you typically might end up doing in your first role, or at least quite early in your testing career. Further to this relatively short list of “typical” tasks, there is an extended list of tasks that QA Engineers might easily end up undertaking, depending on the role and your own desires. It’s possible you could end up doing some of these in your first role even, but I’ve included them in a separate list since they’re all less typical of what you might expect in some respect or other. Still, they’re all things which you could easily be looking to to expand your skill set to enable you to do more of later on:
- Write automated tests: As a human, you only have so many eyes, hands, brains, and hours in the day before you need to sleep, and invariably, each human also wants to be paid for those hours. Tremendous efficiencies can be achieved by setting up automated systems to run tests with little or no human involvement. QA Automation Engineers will often be responsible for setting up a way to run tests automatically, and/or writing the individual automated tests. This could be by writing test code, using a tool which records your manual actions (and later repeats them), building a robot to pretend to be you, or any of a number of other things. It is a task which can also often be shared with other development team members.
- Set up test environments: Tests have to be run somewhere. Perhaps you need a particular version of Windows, or Mac, or a new App installed on the iPhone? Perhaps the machine needs a different version of JAVA? Maybe the office temperature needs to change? Do you have to check it works in French? These are just a few examples of different environmental characteristics which may need to be arranged to conduct effective testing. It is often (but certainly not always) the job of QA to create and/or reproduce these environments and prepare to conduct a test in them.
- Create/maintain infrastructure: The above point mentioned that the tests need to be run somewhere, but it doesn’t stop there. Results need to be stored somewhere, the test instructions (written “test cases”, which together may form “test suites”) have to live somewhere. Beyond that, other useful test files or test hardware might have to live somewhere, and tools you need to use might have complex hardware or software requirements themselves. QA Engineers are often responsible for identifying, creating and/or monitoring many of the pieces required to support the testing effort, even beyond the immediate environment for running tests.
In some companies, some or all of these tasks will be handled by other departments or teams, but there will always be some degree of test involvement, if only to communicate requirements for the infrastructure. Sometimes, however, testers will take care of the whole process from research, design, purchasing, setup, and off into maintenance. - Coach others on good QA: Many places have developers or other team members engage in some QA activities themselves – like “unit testing” which is something we’ll meet later on. Some companies will take this much further and have developers responsible for many more QA activities for one reason or another. In either case, QA engineers will often provide advice and/or otherwise assist developers on good QA practices and methods. This might be by coaching on methods of generating test cases, advising which cases are worth running, reviewing any produced test artifacts like results, documentation or scripted tests, and so on.
- Write/edit requirements documents: A task not usually associated with QA, but there are many places where a QA engineer is best placed to create or update documents which list the requirements of the product.
- Project management: Again, managing the project as a whole is not usually associated with QA, but some places might have QA engineers taking part in these activities.
- Directly contribute to the product: Some QA engineers also write code for the product itself, or create graphical assets(for a game, say?), or write documentation for customers. Building the product is not the natural task of QA itself, but is something which QA engineers may end up doing as a part of their role.
I have most definitely not created an exhaustive list here. Most roles will typically not include lots of these tasks, and naturally include a bunch of others I haven’t thought of, or which are specific to the role you’ve been hired for. In some cases, these additional tasks may not even be things which you’d typically associate with “QA”, but which in some way better enable the team.
Generally speaking, any QA role predominantly involves taking responsibility for tasks which are intended to lead to a better quality product. This will be tasks that:
- Increase the chances of developing a good product in the first place.
- Assess whether the developed product works.
- Report on those results.
The list of individual tasks which might qualify for any of those – directly or indirectly – is never-ending.
