If you want to get a group of new-to-each-other people to merge toward collaboration, I recommend lean coffee. If you want collective problem solving with no pre-planned agenda, based on the problems people bring and share, lean coffee is your jam. It can be done better or worse. Worse is fine, but better is fantastic.
It has been a pleasure of mine to present Lean Coffee at a few dozen events on a couple of continents.
Here’s how I do it. Continued »
No, not do they know a library, like selenium, or POI in Java to import Excel, or Cucumber, or Junit. I mean, can they actually take a problem and implement some code to solve that problem?
To do that, I used Katas.
It turns out that has problems. Continued »
FizzBuzz is a classic programming challenge, or “Kata“, popularized by Jeff Atwood, that requires the test-taker to demonstrate simple concepts like looping and selection. If you are active in the software world, you may know that it was popular at one time and has faced increasing criticism. One explanation for the decline of FizzBuzz is simple evolution. People just learned better interview techniques. Where Fizzbuzz was once the best we knew, today we know better.
I don’t buy it.
The typical programming interview is repeating a list of technologies and yes or no answers. Some teams use a contrived google style tech interview where navigate a binary tree.
A few companies do better, asking technical staff to pair, do TDD, or demonstrate expertise in other ways.
Here’s a way to do it with FizzBuzz.
If you’ve been in software more than a few years, you have probably heard the announcement “from now on, all programming will be in (new_language)”, yet never heard any plans for the conversion. The idea is so naive (do we rewrite all our existing applications?) yet too common.
Process changes are worse. I once had a manager declare that we would start doing ambiguity reviews for documents. From what I can tell, no one actually did the review. Ever. Not even the manager championing in the change as an example.
When I heard that GeePaw Hill was going to do a keynote on change for Agile&Beyond this week, I was encouraged.
GeePaw writes code. As a programmer’s programmer, he has managed to stay relevant in a 40+ year career. He blew me away.
Here are a few of his ideas. Continued »
Twenty years ago, when a change program came in, it came in a three-ring binger. Today it is more likely to be a confluence page or a division-wide email. No matter the delivery format, they all seem to have about the same actual chance of making a lasting impact, somewhere between slim and nothing. I’m not trying to be down here. The effort to create the new program is usually noble. Most of these programs address real problems and organizational pain. We just can’t figure out how to make them stick.
Today I’ll talk about how to get there. Continued »
Today I’m going to tell you a secret about testing tooling, a sort of truth. It’s a kind of truth like the knowledge a partner is cheating. You need to know it, but you’d rather not, and sometimes you’ll wish you could go back to ignorance.
It’s about those automated tests which that one tester is making, over in the corner. You know, the ones you make for every story, the ones that may or may not run under CI.
Your testers are skipping a ton of tests.
That is, of the list of flows to automate, there are a bunch they are … Just. Not. Doing.
And they are getting away with it. Continued »
Yesterday, on the twitters, I had this conversation about communication with Michael Bolton:
It’s a simple answer. It is an easy answer.
And yet, when the tester asks “What exactly do you mean by soak testing?” they are likely to get non-answers. The manager may at first act like the answer is obvious, that everyone knows what it is. Another common response is for them to say “You know, soak testing”, with a slight laugh, making it socially awkward for you to say “Oh course I don’t know, that is why I asked.” If you persist the manager may shift, to say that you, the tester, are the expert. If they are willing to admit they don’t know either, you get to go to the next level. At some point, someone becomes afraid of you talking to “their” customer, and the communication stops.
After twenty years of doing this and helping others do it, I have developed a handful of tricks.
Read on, dear reader. Read on.
If you want to get better at software testing, you might start out looking for a test maturity model, maybe the one from the Illinois Institute of Technology that became the TMMi.
Wait! Before you click that link, stick around. I’ve got a better today.
Today I’m going to propose a way to think about tester maturity. One you can use to evaluate candidates, yourself, and yes, the overall culture of the organization. It is a model, which means it a general. All generalizations have exceptions. All generalizations are wrong. Still, if it can help you test better, interview better, hire better, then I would suggest that less wrong is better.
Here’s my proposal: A test maturity model that is less wrong. Continued »
This week I was at SauceCon, the annual conference for Sauce Labs. Sauce provides the grid (and cloud of mobile devices if you want them) to run selenium scripts on. Listening to a speaker talk about “testing” without drawing a distinction between regression testing and story-testing, I put out this tweet:
I know, I know, there are all kinds of testing, not just those two, how dare I forget about performance and security and so on. Here I am, being terrible, “just” talking about “functional” testing. Okay, fine, but not my point.
Today I just want to make two tiny distinctions, and explain why they are important.
It seems like every time we do large-scale test tooling, we also end up writing a data comparator program. That is, program to compare two different things to determine if they are the same in the ways that matter. No, that’s not a typo. The middle step, where we “zero out” the differences that do not matter, is something I call data swizzling. Sadly, when I talk about data swizzling, most people think I am talking about data on how to cook a steak.
This problem of how to compare the “different” to determine if the differences “matter” turns out to be an incredibly common problem in software testing. Without the terms and concepts, teams generally end up inventing their own way of doing it, writing code that eventually becomes a gnarly mess. They reinvent the wheel.
Here’s the basic use case for a comparator, and how to do it.