The difference between a test case and a requirement is the moment of discovery

There are several straightforward ways to distinguish a test case from a requirement. A test case tells you how to check some kind of thing about the application, a requirement tells you that the application should do some kind of thing. A test case is written by a tester, a requirement by a business analyst. A test case takes the shape of an action and an evaluation of the result, a requirement takes the form of a sentence like “product ABC shall do XYZ.”1

A less straightforward, but more interesting way to distinguish a test case and a requirement, is this:

The difference between a test case and a requirement is the moment of discovery.2

In this post I want to explore the meaning of that statement. In the next post I’ll explore how looking at requirements and test cases in this way, can help us to do better testing. So this post will be a bit more philosophical, the next one more practical.

Read more…

Two short checklists for Scrum

checklist no.1

  • Do you add acceptance criteria and story points to each ticket before planning?
  • Do you have daily team meetings where people provide updates on their progress?
  • After each iteration, do you report to stakeholders what work was done and what will be planned next?

checklist no.2

  • Is the team protected during the sprint from stakeholders trying to interfere?
  • Is a sprint focused on achieving a goal and is how that goal is achieved, left sufficiently open?
  • Does the team address impediments as soon as they are discovered?

The difference between a dead and an alive Agile Manifesto

One of my favorite books on leadership is “Extreme Ownership” by Jocko Willink and Leif Babin. I can imagine some people bouncing off of the book because of the Navy SEAL angle, but to be honest I’m a bit of a sucker for the whole military leadership genre.

The second part of “Extreme Ownership” covers four critical leadership concepts, the “Laws of Combat”. Curiously enough, you can map these to the four values in the Agile Manifesto. These four concepts do come in a specific order, so you have to shuffle the Agile values around a little bit:

  • Cover and Move maps to customer collaboration over contract negotiation.
  • Simple maps to working software over comprehensive documentation.
  • Prioritize and Execute maps to responding to change over following a plan.
  • Decentralized Command maps to individuals and interactions over processes and tools.

To me this mapping is interesting in two ways. It sheds a different light on the four Agile values. And it’s an example of how I think we should be engaging with the Agile Manifesto, in a way that keeps it alive.

Read more…

Notes from the March ‘24 FroGS conf open space

Yesterday Elizabeth Zagroba, Huib Schoots, Sanne Visser and I ran another FroGS conf online open space. There were plenty of great sessions, below are some notes from the five sessions I participated in. Thank you to everyone who was there, I had a great time!

If you want to join one of our next FroGS conf events, head over to our site and subscribe to our newsletter.

From notes to shared documentation culture

  • Co-creation works for code. In what ways is co-creation for documentation different?
  • Why do we talk about “an audience” for documentation, instead of about “the contributors”?
  • The purpose of documentation flips from “what we build” to “what we built”.
  • Old research paper on documentation: only documentation with lasting usefulness is architecture and test cases. Everything else is just notes.
  • Documentation heuristic: Is it easier/faster to reverse engineer it instead?

    Read more…

So you want to become a test engineer?

Becoming a test engineer these days is probably harder than it was for me back in 2006. Back then, there was no test automation, we worked in the slow rhythm of waterfall, and for years I was in a team with other testers or at least had a test manager to bounce ideas off. These days, there’s a good chance none of these are true as you start as a test engineer.

While most of these changes are good ones (please don’t take test automation or agile away), it does make me empathize with anyone who starts their career as a test engineer today. The pace is higher and the skill set is broader. More importantly, you need to navigate your career while no one is really sure where to position testers in their organization. That’s not a straightforward environment to start a career in.

So here are four pieces of advice I’d give myself if I’d start my career in testing today:

  • testing can be many different things
  • you’re a software engineer that specializes in testing
  • the end-game is leadership skills
  • shape your career in a way that suits you

Read more…

Tackling test automation in a new language

While there’s value in learning all the ins-and-outs of one particular language, its ecosystem and its testing libraries, I think there’s also a lot of value in having experience in several. Or at least, in two. If you only know one, you don’t really know what’s essential and what’s incidental to the one set of tools you know. You don’t know from experience in what ways things could be different.

Picking up a new language is not trivial though, especially if it’s your second one. There will be a lot to learn. You will notice similarities between the new language and the one(s) you already know. Sometimes those similarities will help you, sometimes they will mislead you.

Also, it’s more than picking up a new language. There are also the testing libraries you will use and the language’s ecosystem (e.g. how to install those libraries1 or how to set up a pre-commit hook with a linter). That’s quite a package.

Read more…

Never estimate in something that’s not negotiable

Estimates in software development are hard. There are good reasons not to estimate at all. Work in thin slices, keep cycle time low, and deliver at steady pace. And yet, it’s still fair of others to ask: when will this big chunk of work be done? And not “maybe done”, but “definitely-I-can-promise-this-to-people done”.

Ideally you can calculate an expected delivery date based on your current pace and the number of slices in the new big chunk of work. But maybe you don’t have the slices yet. Or it’s a new kind of work and your current pace won’t really apply. Or there are upcoming changes in your team or organization that make any calculation tenuous.

So you have to provide an estimate. And you do. You say “six months”. And the other person - from sales or marketing or some engineering director - says: “We need it in three.” What just happened is that you estimated in something that’s not negotiable. In time, in this case. And the end result is that everyone is unhappy. You have other options, though. You can negotiate in something else than time.

Read more…

A lesson from every language I’ve used

Throughout the years I’ve used quite a few different languages - if you allow me to be somewhat generous with the word “use”. One language I actually feel proficient in. Some languages I’ve only done coding exercises in. And one language I’ve only used for a total of maybe 10 minutes, but that did really help out a whole team.

I do believe we should be that generous, both towards ourselves and to others. For an industry that likes to talk about imposter syndrome, we seem to enjoy saying “You’re not a real … unless…” a bit too much.

Listing these languages for myself made me wonder what I had learned from them. Did I just learn how to write some code in each of them? Or did I also pick up some more general lessons? Turns out I did.

Read more…

Old-school Scrum was rad!

In 2001, nine years before the first version of the Scrum Guide, Ken Schwaber and Mike Beedle published “Agile Software Development with Scrum”. This version of Scrum has some remarkable differences from even the first version of the Scrum Guide.

The three things that struck me most about this version of Scrum, were

  • Scrum Master is a management role, preferably by an engineer
  • there is no retrospective, impediments are addressed in the Daily Scrum
  • Sprints are 30 days and have a goal, tasks can be added and removed throughout

While I don’t want to claim we should return to this old-school version of Scrum, I do appreciate how radical it is compared to how software development is done - even today.

Read more…

A good tester is all over the place

Over the past year, I’ve been thinking about how testing-related roles are still an unsolved problem in software development. We keep trying different permutations: shifting left and shifting right, being closer to the programmers while not too far from other testers, doing less testing ourselves so we can support others more, etc.

And still, to be effective in any of these permutations, you can’t let yourself be limited by them. You need to work both inside and outside the existing structures. You have to “be all over the place”, in a good way.

Testers do testing

Let’s start with a straightforward statement: a tester tests. Then what is testing? I still like the definition “Testing is investigating in order to evaluate a product.” The most obvious thing to investigate, to test, is the code that is being written. The best way to do this, in my opinion, is through the combination of exploratory testing and test automation, i.e. what Maaret Pyhäjärvi has named “contemporary exploratory testing“. And to be clear, while the execution part tends to be the most visible, effective testing also needs good test strategy, design, and reporting.

Read more…