Jeff Nyman recently wrote a series of blog posts about modern testing, describing what he thinks it could be, while also introducing his idea of a lucid approach in testing. The posts themselves are not easy to read but they contain well-formed thoughts about artifacts, acceptance criteria, testing, software engineering, among other things, which deserve a look through. Thinking about his ideas on manual tests, acceptance criteria, user interfaces, software development constraints, and sources of truth was refreshing and insightful and I wonder how he would implement these ideas in a specific tool.
Quoting some of the words that I liked from the series of posts:
- Tickets – in systems like JIRA or whatever you use – are entirely transient. They are there simply to allow us to track and measure various work (tasks, bugs, etc). They are not there to store acceptance criteria or to frame epics that have numerous tickets associated to them. Acceptance criteria should live as close as possible to the code, be versioned with the code, capable of being elaborated upon by the code pushing out relevant information. The elaboration of that acceptance criteria should be the code.
- Each development project is a journey of discovery. And the real constraint isn’t really time or budget or some metric of man-hours for programmers or testers. The real constraint is the lack of knowledge about what needs to be built and how it should be built.
- The fact is that manual test and an automated test are really just checks. What differs is what is doing the execution: human or machine. The testing part comes in when we have the conversations and collaborations to decide what in fact should ultimately be checked. Test tooling comes in with how that information is encoded as code and what kind of framework will support that encoding. Tests should be reflective of the work that was done by development. This means that the testing framework – whatever that happens to be – must be good enough to quickly encode the business understanding and push the business intent.
- The closer the tests sit to the code, the closer the tests are aligned to the business criteria, the less artifacts you have to use to manage everything. When you have less artifacts, being lucid becomes quite a bit easier because your sight lines of what quality means are not obfuscated by an intermediating set of artifacts stored in a variety of tools, only some of which are directly executable.
- Take testing out of the acceptance criteria writing business. Take out the focus on the right way to generate acceptance criteria. Don’t (necessarily) focus on Given/When/Then for acceptance criteria.
- You want to enable fast and useful feedback which in turn allow you to fail-fast. When you can fail fast, it means you have safe-to-fail changes. When your changes are safe-to-fail, that means you can worry less about failure and more about experimenting with ideas, creating working solutions quickly, and even abandoning work that is going down an unfruitful path.
- Going fast is not possible unless the quality is under control at all times, so we need a testing strategy that says testing is a design activity and automation is a core part of the strategy. Going fast on the long term is not possible unless the quality of the design and of the understanding of the business domain is under control at all times, so we need a executable source of truth strategy so that it’s possible to reason about the system at all times.
- Any application is the end product at any given moment in time. That end product is a reflection of a set of features working together. The value of the application is delivered through its behavior, as perceived through its user interface. Behavior and user interface are critical there. That’s what your users are going to base their view of quality in. And, to be sure, user interface can mean browser, mobile app, desktop app, service (i.e., API), and so on. It’s whatever someone can use to consume some aspect of behavior of the application. So everything comes down to the behavior and the interfaces and the consumers of those interfaces.
- Any act of testing acts as a means to aid communications, to drive a clean, simple design, to understand the domain, to focus on and deliver the business value, and to give everyone involved clarity and confidence that the value is being delivered.