Craft Conference is an annual conference in Budapest, Hungary. Their goal is not just to improve engineering but also to change the way companies reason about creating value for the customers. Great speakers shared their ideas, knowledge and practices in the heart of Budapest.
Unfortuntely talks which interested me were scheduled for the same time. Although all was recorded, making the decision on which one to see in irl was not easy.
And now it turned out that not all talks are available online.
My subjective list of this year’s Top 5 talks:
Irio Musskopf: Using Machine Learning and Open Data to Report 216 Brazilian Congresspeople for Corruption
AI is used for monitoring the expenditures of Brazilian public administration. They have found more than 8.000 suspicious reimbursements from Brazilian congresspeople. The project name is Serenata de Amor, and it is open-source.
I was so glad to hear from this initiative. I like the idea very much. This talk is my absolute favourite.
Gojko Adzic: Five key challenges for software quality tomorrow
After the talk I added his latest book into my To Read list, and learnt that we – testers – need to move to monitoring from predicative testing.
Maaret Pyhäjärvi: How would you test a text field?
Unfortunately this talk is not available on Craft’s page.
Summary: testers have to ask questions!
Big list of naughty Strings on Github.
Joseph Pelrine & Jasmine Zahno: Seven (plus/minus two) ways your brain screws you up – Going beyond some psychology memes floating around the Agile community
- Focus on one goal at the time.
- Physical exercise.
- Express emotions.
- Eat reguarly.
An estimate is not a number, an esimate is a range. Better estimation technique: Reference class forecasting.
The way how the product owner phrases something influences how the team estimates.
Seb Rose and Gáspár Nagy: Writing better BDD scenario
This one was a workhop.
Good BDD scenarios are concrete, essential, focused, interesting, declarative, ubiquitous.
- One rule per scenario.
- What, not how (don’t specify UI in steps, where to click, what to fill in etc).
- Max 5 steps per scenario.
- Omit the obvious.
- Be deterministic (do not use OR).
- No intentions, actions (avoid “want”).
- One When per Scenario.
- Use “should” in Then steps. The word “should” might be used to keep the discussion opened.
In order to improve your scenarios, you can use orientation questions:
- Is it clear what each scenario is describing?
- Are there too many/too few details?
- Does it use a language that everyone understand?
- How likely is it that this scenario will change when the application changes?
And the book I added to the To Read list after the workshop: Discovery: Explore behaviour using examples.