Having wandered reluctantly into IT about 30 years ago, Phil’s first contact with formal testing came unexpectedly in 2002 when he was told that he would become the Test Manager on the project he was working on. Maybe it was fate, but it seems he found his true calling. He eventually became the guy they called when there was a “problem in testing”. But after a few years of fire-fighting on those troubled projects, he began to tire and wonder if there wasn’t a better way. So ten years ago he co-founded a software testing start-up Tesena in Prague with a mission to change the testing world.

Imagine… It’s your first day in your exiting new job as a QA in a fast-growing tech firm. You have spent the morning with HR going through the onboarding process and getting your shiny new top spec laptop and smartphone. HR takes you through the super cool office space to meet your new team. You arrive just as they are halfway through their sprint retrospective. You immediately notice the mood in the room is tense. The are quite a lot of post it notes on the board. The Scrum Master, Jan, greets you and introduces you to the team “Hey everyone, this is Josef our new QA”. “Boy, do we need you,” says someone in the room. Some of the other team members laugh. Jan introduces everyone in the room. There’s a PO, a BA, four Developers, a guy who handles production support, some sort of DevOps guy. There’s also Hana the other QA on the team, who’s face is flushed and angry.

“So, Josef,” says the Scrum Master, “let me get you up to speed. We’ve just had three really bad sprints. Nothing went right. We couldn’t deploy anything in the first two sprints as we couldn’t finish testing before the deployment window. Last Thursday we finally went live with our really important new feature, and….well, it’s been a real s**t show. The quality of the new feature is really bad plus some important existing functionality stopped working. It looks like some of our customers are now uninstalling our app and switching to our competitor. Clearly, our businesspeople and management are going mad. Anyone got anything to add?” The Scrum Master pauses for a moment and looks round the room. No-one answers. “Well,” continues the Scrum Master, “we’ve finished our start, stop, continue exercise” and basically everything revolves around testing. Maybe someone could summarize?”

“Yes” says the guy from support, “we need to test MORE, we can’t accept this sort of quality getting into production.”

“We need to test BETTER” says one of the developers, “most of the defects that get reported are irrelevant or are not important enough to fix.”

“We need to test FASTER” says the PO. “Testing is too slow and expensive. Is adding 30 percent to the cost of each feature and it’s really slowing us down. We were 4 weeks late with this latest feature”.

At this point Hana stands up, says something rude and storms out of the room and heads in the direction of HR. “Maybe that’s the last we’ll see of Hana” someone says. Then all eyes in the room turn towards you.

What are you going to do?

You might be tempted to follow Hana to HR. But you’ve been looking into Quality Engineering, and you can see that this team really needs some quality assistance. You can see the team wants to deliver valuable software on time. Unfortunately, they seem to think that if they “fix testing” then they will “fix the problem”. You know better.

In this workshop with Phil you will try to solve some of Team from Hell’s problems using a quality engineering approach. First, we will take the outputs of the retrospective and identify changes that will help the team improve both the equality and speed of their delivery. Then, we define a quality engineering strategy that the team will apply to their next key feature. Are you ready to work with the Team from Hell?