Keywords have become a popular way of writing tests. Hans Buwalda used keywords to devise the Action Based Testing method in which tests are written as sequences of “actions” represented with keywords. However, keywords are just a physical representation of actions, and there are other ways to do this.

Artificial intelligence (AI) is propelling to the forefront once more. With the growing importance of AI comes the question: How do I test it? AI systems do not necessarily behave predictably. This means that traditional test cases of the form "do this, expect that" are not always sufficient.

Unit testing is a great way to verify software at an early stage and to ensure that modified functions are still working as specified. However, unit tests are not a magic wand. Rather than making such a big testing effort, consider taking "rain checks" for certain tests.

The key success factor for DevOps is the commitment from teams, managers, and other stakeholders. There should be agreement that tests and their automation can be important re-usable products, which need attention and cooperation to be able to support approaches like DevOps effectively.

With DevOps becoming the norm, we're entering a world of pipelines. With frequent or continuous deployments, streamlining and automating the process of building, configuring, testing, and releasing developed software components becomes a high priority—with testing posing its own unique set of challenges.

The cloud is metered—you pay by the hour, by the gigabyte, or by some other metric. The numbers might not necessarily be high, but they draw attention from managers. As testers we should look at these numbers as well. Hans Buwalda looks at how cloud-induced metering can impact testing.

When looking at what the software market is currently talking about, the top item is DevOps and Continuous Integration/Deployment, which seems to be taking over some of the spotlight from agile and is now a widely accepted new normal. Hans Buwalda looks at where the future of software testing is going.

Testers have an important responsibility to protect and further their craft. Many people who want to be considered testers should engage in career development more than they might have in the past. Hans Buwalda highlights four areas that testers need to understand to stay relevant.

Software tests have to meet quality and robustness criteria that are similar to the application under test, but tests seldom get the attention and investments that the applications get. Hans Buwalda outlines why you should consider tests as products.

For testers, virtual machines can be a game changer. To what degree the game really changes depends largely on how an organization decides to work with virtual machines and how active the testers themselves are in recognizing and leveraging virtual machines’ possibilities.

Testing and automation have various paradoxes that are interesting to look at for insight into the challenges and limitations of our profession. Hans Buwalda describes these paradoxes and offers methods to bring about cooperation in teams, helping them achieve great automation results together.

When executing test modules, an interesting question to ask is “What needs to happen with issues that are found?” Hans Buwalda suggests making a distinction between issues found during a sprint and after the team has declared the functionality under test "done"—and describes how to proceed from there.

A major contributor to success in test automation is test design. If tests have many unnecessary detailed steps and checks, even a skilled automation engineer will not be able to make the automation efficient and maintainable. Hans Buwalda shares an example of a test design that is automation friendly.

Hans Buwalda shares a model used for multi-station testing with actions—the lead deputy model—and shows how actions can be used to make a relatively complex task like multi-station available at a business level where even non-technical users can easily understand the thought process.

Hans Buwalda describes five of what he refers to as misconceptions about test automation.

Automating functional testing is almost never easy. As testers, how we organize and design tests has a big impact on outcomes, but developers can—and should—have a role in making automation easier. This ease or lack of ease is part of what is known as "testability."

A good test design is important because it improves the quality of the tests, helping to add breadth and depth, and it facilitates efficiency, in particular for automation. These points are obvious when starting a project from scratch, but what do you do when tackling a project with existing tests?

When automated tests are well-organized and written with the necessary detail, they can be very efficient and maintainable. But designing automated tests that deal with data can be particularly challenging. Tests need certain base data to be available and in a predictable state when they run.

Just like with design patterns, anti-patterns can benefit from a short and catchy name to make them easy to remember and talk about. Hans Buwalda shares a list of typical situations seen in tests that can harm automation and names for them.

Interactive exploratory testing and organized automated testing seem to be on opposing ends of a spectrum, but much of that depends on how you apply them. Automated tests don't have to be shallow and boring. You can still explore, learn, and create good tests. Read on for more from Hans Buwalda.