At our EuroSTAR Conference back in 2016, I mentioned in my talk that one of the steps we have taken for training our test consultants is to introduce them to Java in a special “Java for Testers” course (here’s the webinar if you’ve not seen the talk). Since the focus of the talk wasn’t just on that aspect, I couldn’t spend enough time on talking about what that means for us. There are other areas to explore. In particular I want to talk about functional testing techniques and using the whole team to create quality.
Whole team testing: Who should be automating functional checks?
Some recent changes and experiences have made me (and us in our test consulting team) think a great deal about responsibilities and roles when it comes to test automation. We come from a company that contributes to an open source test automation tool – a tool whose target group is testers who do not program. The reasoning for creating and maintaining a tool like this is quite simply because we believe firmly that programming skills don’t have to be a prerequisite for automating functional tests (or checks, to be precise). Structured thinking, the ability to abstract, and the ability to learn some sort of domain specific representation are a better description of the prerequisites. Team members who have experience in testing and who identify as testers can be better suited to automating checks than team members without such experience and who identify as developers. For us, it follows that writing automated checks is something that someone in a tester role is also suited for.
The Brave New World
So far so good. But we’re not idle in our team, and new contexts call for new skills and new discoveries. In the past few months, we’ve encountered some exciting new situations:
- In our projects, we don’t exclusively use our own tool. As a company and as a test team we understand the importance of selecting the right tool for the context. We’ve been coming more into contact with other tools – ones that use programming languages to write tests for example.
- Due to a customer query, we have made it possible for the open source tool we develop to also be controlled by a programmatic API, thus allowing anyone with programming knowledge to write tests in Java with the tool.
- We have been putting a lot of thought into patterns for test automation that are tool-independent
Where does that leave us? It means that our test team (even those who don’t program) are coming gradually more and more into contact with languages such as Java. It also means that the developers in the teams we work with are more likely to contribute to the functional tests. Does this mean that we’re going to leave all the technically flavoured testing to developers and concentrate on manual testing? Nope, it doesn’t.
Functional Testing Techniques
From one enlightening conversation between one of our testers (who does program) and a developer, I realised something incredibly important. It is not necessarily the case that the same patterns apply for development code as for test code. On a general level, yes: cohesion and good naming for example are important for both. But a developer writing code for functional tests might not structure them in a suitable way. She might introduce a great deal of conditionality through if statements, for example, leading to one test running very differently depending on various situations. Just because Java allows it doesn’t mean that it’s always good for a functional test designed to check a specific test case in an application. With great power comes great responsibility. One of our roles as testers in situations like this is to work with developers to ensure that any functional tests they are writing adhere to patterns for test automation.
Layers and Responsibilities
Are we then just the guardians of test patterns in this scenario? We don’t see that either. We’ve been working on ensuring that our functional automated checks follow well-defined levels of abstraction.
For a tester without programming knowledge, calling methods that perform functional workflows (such as e.g. createNewCustomer(customer); as opposed to low-level tool API calls and synchronization) is already fairly understandable. We also support these testers by holding the “Java for Testers” course to cover the basics of syntax and procedural programming. Within a team, these testers can collaborate with testers who do program (or with developers) to automate functional workflows and test cases.
Whole Team Quality
With that, we’ve come full circle. Yes, the whole team should be involved in quality. We still believe that it is important to have people with “tester goggles” to write functional tests and to check other people’s tests – which is why we’ll be equipping them with the capability to do that when it’s necessary. It does mean learning some new stuff, but it doesn’t mean becoming a master software engineer. Developers can definitely help with test automation, especially in terms of infrastructure, framework extensions, testability and also by contributing to the building blocks (the “bottom-up” perspective) needed for functional workflows. Responsibilities in the team don’t have to be set in stone – each team will work slightly differently due to its composition and experience. The important thing, as always, is that we’re communicating frequently and transparently about quality and the information our tests give us.
As I said at the Agile Alliance Technical Conference earlier this year: it doesn’t mean that only developers should automate, or that all testers should learn to code. It does mean that the team needs to work together using good automation practices, and that everyone might have something to learn.
Want More on Java? Check out the Java for Testers eBook
