We know personas help build a better model for our stake holders. This can help us design and test products that fit customers better. But how do build this persona?

In this workshop, we'll use role-playing to build personas. After introducing a magic product in the field of night-stalkers, attendees will conduct interviews with each other. We'll talk about different aspects of the persona (etc. habits, likes and dislikes) and with the role playing aspect, we'll make it the persona understanding more broad, learn details about it, how it relates to the product, and maybe even give it a score in its relevance.

This should be fun!

The workshop has two parts: Building the persona and interviewing (through role play). The persona is built based on what we "know" about vampires, and the interview is teaching skills on how to extract information in different methods. (Most of them are non-violent).
The workshop teaches the basics of persona building and affirming or disproving assumptions. It is also has the basics of suggesting a possible solution to the market.

The lives of vampires are hard. They have problems finding blood donors, going to Italian restaurants (too much garlic) and even coming to conferences (meetups in the evenings are ok). Let's help them feel comfortable.

In the age of scaling, we’re thinking of how to master agile in big teams, with big tools and big processes.
As if we’ve already mastered the small scale.

You know those files with tens of thousands lines of code you were debugging last week? Or the ever growing time to compile and run tests?

How about testing a complex system, expanding faster than your team is able to cover? Or reviewing an endless list of bugs, each matters differently for different stake holders? And then the big question: Should we release or not?

We haven’t even mentioned how all these pesky humans that create a complex network of interactions impact everything. Complexity, and our understanding of it, is at the root of IT problems today.

The impact of complexity on our projects is hard to calculate, but it definitely takes a toll. We see it and we feel it – in stress, confidence level and the bottom line.

Sure, we can and should, inspect and adapt. But let’s make it practical. Let’s talk about how small things we do every day, can remove the vague of uncertainty, and make life easier for ourselves.

Let’s make it simple.

Topics covered:
• Understanding complexity
• Impact of complexity
• Cynefin framework
• Navigating through complexity
• Small acts of simplification

Once we've started to unit test, we concentrate on the next piece of code we want to tests. While tactically it maybe the right thing to do, we should think as unit testing as part of whole strategy in testing the feature, and approach in a more structured way.

There are a series of questions we need to answer before and during the development, and even after we're finished. The method takes into account both TDD and test-after, and specifically works well for legacy systems. It's a holistic approach to where the tests fit into the development environment and how the code is developed.

The process starts with how we understand the problem and the design, thinking about which tests we need, existing and introduced testability, dealing with design constraints, identifying dependencies and more. Writing tests becomes a small (but still important) part of the process, and it doesn't end there.

Deciding to write tests for our code is a great big step. Let's take it a step further and actually think about how to do it.

How do you go from ideas to an actual product?
Agile development start from a user story. But how do we get there from our product vision?

Writing good stories require great skills. Slicing feature ideas into small increments, planning a rollout plan, and using them as experiments effectively is an art form. But if you want to understand how to implement Lean Startup ideas and how to convert them into actual agile execution, you need to learn these skills.

In this workshop we'll actually try the ideas for a real application. We'll see how to use Story Mapping for planning releases. We'll see how to take our list of magnificent ideas, and break them into small MVPs we can try out. We'll talk how to critique our assumptions, and follow deliberate learning principles.

We'll then take features from our plan and learn techniques of slicing them into stories. We'll talk about how to break big epics into small stories. Stories that are valuable for the purpose of our MVP. We'll also see how these stories fit into a testing plan, and what kind of feedback we can get from them.

Finally, we'll write actual stories. We'll see what makes effective stories, and how to share and present them within an agile team for better collaboration. They are going to be the basis for great BDD style tests.

Little children are told a bone chilling story, that when testers gather, a dark shadow befalls the city.
This is the ghost of the Testicorn. An agile unicorn who died in a freak accident and now terrorizes workshop attendees.

But all is not lost. It was once defeated by the Slicer, a magical sword that can slice big scary stories into smaller, less frightening ones.

In this workshop, we'll prepare for dealing with the horror.

Using elephant carpaccio, mind mapping and other techniques we'll slice and dice stories about our epic killer. During this session, we'll talk about how big the stories are, when to stop slicing and different perspectives we can make stories smaller, less risky, testable, and still valuable.

So fear not! The Testicorn is indeed a menace. But with our Slicer of stories, we can defeat it. Prepare for battle!

Have you heard about BDD but was too scared to try it out?
Have you heard about TDD and BDD and ATDD and you're overwhelmed with DD related acronyms?
When you hear "cucumber" and "gherkin" do you think about making salad?

Well, this workshop is for you.

In this crash course, we'll learn the basics of BDD, the why and what. We'll talk and write some stories in Gherkin, automate some tests (and some code) to learn the basics of behavior driven development. Of course, it's going to be about Star Wars, why do you ask?

Since this is a crash course, it's going to be a bit of talking, and mostly experimenting. You'll need
a laptop and an IDE (eclipse) with Cucumber (but Visual Studio with SpecFlow also works.) That's enough to start getting our hands dirty.

By the end of the workshop, you'll have a grasp on how BDD fits into the development process, how testers can benefit and even guide development using test-first, and how to build a Death Star using BDD language and tests.

If it’s good enough for Darth Vader, it’s good enough for you.

We know that testing depends on context. We need to apply context also in our testing strategy, depending on where we are in the process – Are we in the beginning of the project, or towards the end? Are we testing for user experience, or functionality? Do we need automation at all, or maybe we’ve got so much automation, we’re already thinking on how to test our app on production servers?

The way we’re thinking strategically about testing is at the heart of this workshop. We’ll talk how to plan testing in different scales – Phases of product development (using Kent Beck's 3X model), from a “release” to a feature, from stories to a micro-drop. We’ll discuss testing MVPs, the risks in the specific level, and testing in production. When our context changes, so does testing.

In the workshop, we’ll do planning exercises at the appropriate scale for the different stages, and discuss the differences and nuances we’re interested in. The discussion is collaborative and everyone brings their own experience – the best way to learn.

In the end, you’ll learn how to choose the right resolution for testing, and pick the right strategy, level of reporting and focus to make the most of our already limited testing time. Hearing others’ experience makes it real and actionable.

Do you know how long your tests are expected to live? Today we’re talking about a few years at least. That means that the code that you write may even outlast you in your current position. Isn’t it time we give the tests the respect we give “real” code?

This workshop is intended for the coding tester. We’ll talk about proper name and organization, refactoring, standards and even TDD and pairing aspects. We’ll write, review and dissect tests in order to understand how tests should be written for the long haul.

This is a coding session. It is not about the basics of test automation. You’ll need a laptop with your favorite IDE and test framework. You need some experience in writing tests, because we’re not going to cover that. We will talk about how to write better code as testers.

We already have developers who write crappy code. Let’s help them (nay, show them!) how to write better code.

Howdy partner! Back in the ol' west, we used to have a saying: "First you test it, then you build it". Man, the good ol' days.
But now, we have TDD, BDD, ATDD and even DDD, a cowboy can't tell a gherkin from a cucumber. And that can be tricky
when you're making a salad.

So how do you avoid handling those dangerous vegetables?

Welcome to the fastest, bestest BDD crash course in the west. We'll talk the basics of BDD, why it's there and why it's important. We'll then jump into writing stories using Gherkin, and implement them, making them come alive like zombies!
You know these new things called laptops? You'll need one of those, with a programming language, and one of those BDD tools (Cucumber, JBehave, SpecFlow, etc.). Just load'em up, and we'll take it from there.

Let me tell you, ain’t no feeling like running those specs, and look at everything come out green. Even riding a pig doesn't come close. If you haven't tried it before, you should come to the workshop and try it.

(Pig not included).

Legacy code. No matter who wrote it and when, it drops in your lap, and now you're own it.
If you're the responsible kind, you want to leave it a little better, and a lot more testable. Responsibility means writing tests for it.

Yet the code resists.

If you're handling or writing any type of code, this workshop is for you.

We'll talk about the different things that make code "untestable". Those things that we missed when it was written, and that now, when we want to write tests, from unit to selenium, computer says no. From architecture and design decisions, to using singletons and over encapsulation. The opportunities are endless.
But talking isn't enough. We want to do something about it.

In this workshop, we'll review and refactor code that's full of small "legacies". We'll remove them and make sure those pesky little things won't return. All you need is a laptop, an IDE with a test framework, and we're good to go.
Spotting those little things is like having a super power. We can prevent accidents way before they happen. We can save hundreds of hours of rework, by spending minutes thinking ahead.
Would you like to be a super hero?