A software tester’s accessibility testing toolkit should contain various tools, both to help testers “walk in the shoes” of their users and to quickly flag obvious problems and expose accessibility features (or a lack of them). High performance is only achievable with human skill, but these tools will help you uncover potential issues and make your product a better user experience for a wider audience.

Many people equate 100 percent unit test coverage with high code quality, but that is not enough. Code coverage tools only measure whether the tests execute the code; they make no judgment on the effectiveness of the tests. Testers should review unit tests, even if they have high coverage levels, and either help improve the tests or supplement them with extra tests where necessary.

Pulling data from a source system and putting it into a data warehouse is a process commonly known as extract, transform, and load, or ETL. Testing the process can be a chore—you need to be sure all appropriate data is extracted, that it is transformed correctly to match the data warehouse schema, and that it's all imported. Instead of testing the ETL process as a black box, you can pull it apart, testing each piece in isolation.

Discussions on what constitutes a “proper implementation” of test automation often focus on what tool you should use, but that is only one part of the equation. Bas Djikstra details four other things you should consider, how they contribute to the success of your test automation, and what risks are associated with failing to pay proper attention to each of them.