A lot of DevOps talks are about automation and tooling, but let’s talk about the people side of DevOps.

When I first learned that my team was going to transition to the DevOps way of working, some interesting things happened. For one, I was scared of this change, fearing it might make my role obsolete. But when the developers assumed that the testers didn’t want to take part in the Ops side of things, something stirred inside me. Was it….responsibility?! I also wanted to be accountable for whatever happened in Production!

This moment set a bunch of things in motion: I had to confront my own fear and use it as motivation to kick ass and learn new skills to be able to contribute useful things to this new context. I had to let go of the old tester inside me and invent a new one. I will share what, in my opinion, a DevOps tester role is, and how it contrasts with older styles of testing. You can use this as fuel for your own journey to grow.

Slides: Using DevOps to Grow

Before I started my career in software development, I worked for many years as a dog trainer. The experiences I made in this time are the reason why I immediately fell in love with testing. So, let’s talk about TDD! TDD stand for Test-driven development and it’s not only a technique to write tests but also a design process in software development. I want to give you a new perspective on this process and explain how to TDD with the help of comparing it to how to train a dog. TDD has much in common with dogtraining, so at the end of my talk you should be able to write a piece of c test driven code, and also teach a dog a little trick - well, the last thing at least theoretically.

Slides: Treat yourself - a tale about dog training and test driven development

GitHub: programmiri/examples-talk-tdd-dogtraining

How can you squeeze Security into DevOps? Security is often an understaffed function, so how can you leverage what you have in DevOps to improve your security posture?

Often the culture clash between Security and Development is even more prominent than between Development and Operations. Understanding the differences in how these functions work, and leveraging their similarities, will reveal processes already in place that can be used to improve security. This fine tuning of tools and processes can give you DevSecOps on a shoestring.

Slides: DevSecOps for Developers, How To Start

The programmer holds the power in the team. The ux designer, the product owner, the manager, the tester, the agile coach and others can try their best to influence outcomes but it doesn’t matter if the programmer is not on board. Only the programmer decides which if-statements get written and how long it will take. What does this mean for the other team members? How can you impact quality if you’re not the one making the ultimate decision?

Slides: The one with the compiler always wins

So you need to test micro-services, and you’ve been hearing Consumer Driven Contract Testing (CDCT) with Pact is the cool new thing on the block? It seems like it perfectly fits what you need. You might even go ahead and give it ago, run a proof of concept yourself or have a few developers/testers try it. And if this is gonna work, the ideal is that all your teams use it - otherwise you will have blind spots in your testing approach. But how do you go from a proof of concept to several teams adopting it? How do you make sure everyone is doing the right things and has the proper understanding of Pact? How do you avoid mistakes by people who didn’t take the proper time to understand this tool? How do you get through Pact’s learning curve and make sure you are not misunderstanding it yourself?

In this workshop, we are going to try to work as a company with teams looking to adopt CDCT, with a focus on avoiding some pitfalls that might cost you time and money.

What can you look to gain from this workshop?

• A deeper understanding of Contract Testing through the use of Pact;

• Knowledge on important concepts like versioning, tagging and naming conventions;

• Insight on Pact’s learning curve, and some mistakes people tend to make;

• An idea on how the Pact workflow works from a simulated hands-on situation.

You can get more out of this workshop if you already have some beginner/intermediate knowledge of Pact. However, we will briefly go through some basics, and at the very least you can pick up some important notes and tips along the way. So, all are welcome!

Requirements:

If you wish, you can follow the workshop on your laptop. This works best if you have the following:

• a GitHub account
• git (or other source control tool)
• Node + nvm
• Docker (optional)

You will still be able to follow without a laptop.

Slides: Get with the Pact - “Gotchas” of implementing Contract Testing the right way

Do you do these things with your team members?

• Challenge them to solve their own problems

• Motivate them with frequent feedback

• Empower them to make their own mistakes

Leaders often base their daily interactions with team members on similar premises. But do they always work? Good leaders know that no leadership practice is universally applicable. We don’t apply “standard” practices blindly. Instead, we prefer to evaluate any practice for fit with a given team member in a particular circumstance. Perhaps we also develop and selectively apply our own practices. This is using practices heuristically—as imperfect models or rules of thumb that we can call on when they seem appropriate and useful. By consciously adopting heuristic methods, we can help grow our practice of leadership from black art to something more closely resembling science. We can expand our capabilities.

In this interactive workshop, participants will work in teams to share or develop heuristics for leadership, and then apply their own experiences to evaluate them critically. We’ll have fun exploring the practices of test leadership and developing a set of positive heuristics that can help us all become more effective leaders in our daily work.

This workshop is for testers, test managers, test leads — anyone who is or wants to become a test leader.

Slides: There are no slides for this workshop.

A typical software delivery process is full of accidental domain discovery – even if the project follows agile practices. No matter how good specification are that you receive or how good your Product Owner is in explaining the User Story requirements; whenever you as a developer or a tester start working on the solution for real, new questions will arise. You need to go back to the Product Owner or try to answer them yourself based on assumptions. Accidental discovery.

Regardless of which agile software methodology you use, there is a time when you show the created solution to the business representatives to get feedback (like in Sprint Review meeting in Scrum). And the feedback is very rarely “Ship it!”, but more often asking for changes or clarifying misunderstandings. Accidental discovery again!

Accidental discovery causes longer story implementation cycles (Have you heard about “done done”?) and unnecessary rework. Waste.

Behavior Driven Development (BDD) is an approach that encourages deliberate discovery: trying to answer those questions that would otherwise pop up during the implementation and getting feedback about the solution even before putting down a single line of code. How is this possible? BDD uses a combination of example-based specification and requirement workshop facilitation to achieve deliberate discovery.

In this workshop, you will not only hear about deliberate discovery, specification by example, BDD and example mapping, but you will also have a chance to practice it.

Slides: Breaking down problems with example mapping

Do you ever have this experience: Your team discusses a story in the planning meeting, codes and tests using good practices, delivers it to the product owner or customer - who then rejects it because it wasn’t what they wanted. We see this all too frequently, even on experienced agile teams. It leads to long cycle times, high rejection rates, wasted time and general frustration. We don’t want to get stuck in “analysis paralysis”, but we do need to make sure that everyone on the cross-functional product team shares the same understanding of each story they need to deliver before they begin testing and coding. Teams also need to remember there are many different quality attributes that may be critical to a product’s success.

In this hands-on workshop, you’ll learn techniques such as the 7 dimensions of quality to help you apply your testing mindset to elicit examples and business rules from stakeholders. You’ll practice turning those into test scenarios that guide development of the right things, so that your team can deliver value to the business frequently and predictably.

Learning takeaways:

• Ways to explore requirements and do deliberate discovery, in a timely manner, to uncover missing, conflicting, erroneous and unnecessary requirements.

• Techniques from agile business analysis and agile testing models that help teams scope each feature and deliver acceptable value to the business, considering all relevant quality attributes.

• How to use your testing mindset and conversation frameworks to help your whole team build shared understanding for each feature and story, shortening cycle time and reducing rejections.

Slides: Exploring Features and Stories - Help Your Team Build Shared Understanding

Failure can be catastrophic and speed to market is a critical business advantage, putting development teams under more pressure than ever to get software from concept to customer in as short a time frame as possible.Speed is a key factor, and to have speed you need an understanding of the impact of any change. You need to know how high performing teams achieve the seemingly impossible task of delivering valuable software while increasing speed and frequency - without compromising quality.

Teams need to adopt a relentless focus on Testability, eliminating anything that makes testing difficult, slow, wasteful or less trustworthy. A whole team focus on Testability shortens feedback loops and accelerates learning while enabling more robust automation, as well as deep, meaningful testing.

In this workshop, you’ll work with core concepts and models used to explain and advocate for Testability. Participants will work through a series of exercises that I have used through my career from Tester to Test Coach. The exercises will help to identify and address testing debt as well as establish a whole team focus on Testability.

This workshop is aimed at anyone involved in software delivery but would be most beneficial for developers and testers.

Takeaways

After the workshop you will:

• Understand and explain Testability, the factors that influence Testability and the impact testing debt has on a teams productivity.

• Identify and address architectural Testability problems using a combination of models and practical exercises.

• Identify and address holistic, whole team Testability problems using a combination of models and practical exercises.

Slides: Exploring Testability (.key)

Worksheet: Exploring Testability - worksheet

It happens. You’ve seen it in the news. You’ve seen it on social media. You’ve most certainly seen it on at least one of the project teams you’ve worked on over the course of your career, no matter how long you’ve been working in software development….

A bug escapes to Production.

Maybe it’s small and the damage can be mitigated or reversed quickly. Maybe it’s not so small, and it sends your team, and maybe even your whole organization, into a frenzy.

This is our nightmare scenario. We feel inadequate. We feel it is our fault for missing something so “obvious”…but was it really? And who really was to blame anyway? Whose head belongs on the proverbial chopping block?

In this talk, I will answer all of these questions and provide a framework for preventing these incidents from happening again.

Slides: There are no slides for this talk.

First, you need to access a web page. You then need to read some information from the web page. And then you need that information in tests, in order to compare the actual information from the page to the expected one.

Data read from the pages can be a real puzzle and a mess, if it is not properly organized. For example, what if you need to read the ingredients for a list of cakes? Or the price of coffee based beverages? How do you organize data read from ordered lists or tables, just to name a few? How do you extract the relevant information from the page and where do you store it? I will demonstrate the answer to all these questions on real examples with real code, using awesome Java concepts like Lists, HashMaps or Strings.

GitHub: iamalittletester/little-project

It is so easy to bring people down with feedback. However most of the time, this is not our intention. Instead, we want to deliver all feedback in a way that gives the best possible impact. Let’s learn how to give uplifting feedback.

Slides: Exploring different ways of Giving and Receiving feedback

If developers are always striving to do their best work, then why is software so full of bugs?

This talk is a light-hearted look at the all-too common missteps that we all make when building software.

Developers often have strongly-held beliefs about what makes “good” software. These beliefs come from dogma passed down through generations rather than from empirical evidence. I’ll show how we can help developers challenge the status quo and start experimenting with new approaches.

Slides: Falsehoods developers believe about testing

We have heard a lot about mob programming and mob testing, but what if you actually start doing it? And stick with it, even if the first sessions aren’t that great? Well, that’s what we did! We’ll tell stories of our weekly mob testing sessions, what issues we uncovered (spoiler: not many), what we learned (spoiler: lots) and how we got better at it over time.

We started mob testing once a week this past February: four testers from four different teams and one facilitator. The biggest hurdle we faced was learning how to collaborate as a mob. We knew we were getting somewhere when a few people went “Ooh!” simultaneously. We were surprised by how many different things we learned: about each other’s products, operating systems, tools, languages, and keyboard shortcuts. To be honest, we haven’t gotten to a point where we find a lot of bugs yet. And we don’t know that we ever will.

However, we have been learning so many useful things that we have no plans to stop mob testing anytime soon. The lessons we learned are worth more than any bugs we could find. By sticking with mob testing, we have built good habits that have made us better collaborators.

Slides: Mob testing; building good habits

How do you figure out where and how to add value once you stop doing hands on testing day to day? In 2018 I was promoted to Senior tester when I moved to a new department. This meant I was on two teams, both with full time testers, so there wasn’t a lot of work for me to test. Suddenly I had to balance two teams, but not day to day testing, and no team lead responsibilities.

I wanted to make sure I was adding value to these teams and the testers on them without taking work away from them or getting in the way. I also wanted to make sure I knew the value I was adding - without knowing the value I bring, I had no idea what I needed to strengthen in or what skills to add to my toolbox. But I’d never had a job that was focused solely on the non-technical skills of testing before! Suddenly my priorities were being visible, driving communication and strategy: all things that have few ‘solid’ goals!

This talk will cover what I’ve learned in the past year and a half of this role, some successes, some failures, and some tools I discovered to help me.

Slides: Value and Visibility; How to figure out both when you don’t do any hands on testing

Static analysis tools are often used as an enterprise standard because management wants to track metrics, so the team gets their code in there then forgets about it - out of sight, out of mind. But for someone looking for areas of risk in a codebase, static analysis tools are a treasure trove of information that is usually difficult to track down manually or even with test automation. In this session we’ll use the map provided to us by static analysis to find areas of risk from bugs, duplications, code coverage (or lack thereof), and complexity. We can further analyze these hazards to get a clearer picture of the actual risks, or take immediate action to reduce that risk by killing them off. And if you’re not using static analysis tools just yet, you’ll learn about just how invaluable they are to the entire team, not just management!

Slides: The Hidden Treasure of Static Analysis - Finding Risks In Forgotten Places

Recheck-web is a free Open Source test automation tool on basis of Selenium. It implements Golden Master testing, which makes for – easy to create and maintain tests – that are more complete – and less fragile. And on top of that it can make your test almost unbreakable and elements easy to address with a constant virtual id.

Learn how recheck-web works and train hands-on with some examples.

Slides: Test Automation without Assertions

Have you ever looked at a failing automated test and asked yourself… should we just delete it? I’ve asked myself this question numerous times; I’ve trained myself to do so, because I understand its importance. However, I’m often left baffled by colleagues and other testers who reject the idea of deleting a test. Why do they find it such a scary concept? So the result is that we continuously look and review the same tests, not knowing if they’re mitigating any risks, or worse, not knowing what they are testing anymore. But if you’re like me, you’ve probably looked at some failing tests before that left you thinking “why does this even exist?!”. That trigger is one you shouldn’t ignore.

In this talk, I’m going to share my experiences of listening to this trigger, but more importantly, I’ll explain the actions I take. You’ll learn how to analyze the full lifecycle of an automated test to truly understand its value. We’ll talk about the total cost of ownership of a test, and how it is a key analysis factor when attempting to reduce feedback loops. I’ll bring some stories from the company I work for to support this. After all, we’ve gone from automated regression environments running thousands of tests overnight to a CI/CD reality. I love my delete key, I hope to share the love!

Slides: Should we just… delete it?!

Being a tester is a lifetime journey, but working as a software tester is just temporary. I transitioned to a new Product Owner role, and found some of the skills I had as a tester to be far more useful than I expected. I also found out about a bunch of skills that I now wanted to learn. My talk is around these skills, the ones I had, and the ones I’m still missing.

Slides: From Tester to Product Owner

Did you ever struggle consuming an API that kept on changing? Did you provide an API that you were unsure how people will use it? In such a scenario, an iterative and cooperative way of working that focuses on consumer driven contract testing can reduce your pain. In other words, an experience with “Consumer collaboration over contract negotiation”.

This talk aims to practically illustrate consumer driven testing using Pact. We will cover when this technique is appropriate and how to organise, define and evolve APIs while keeping in mind. The session will involve a mixture of presentation and live coding to illustrate on how this works in practice.

Slides: Consumer Driven Contract Testing with Pact

Containers. Every manager thinks they want them, but few teams have experience in knowing what to DO with them. Used thoughtfully, containerization of your services can transform the way your organization thinks about testing. Gone can be the days of maintaining X different compute environments with Y different configurations. Imagine instead spinning up just the code you need, on the machine type it needs, and only for as long as you need it.

In this technical talk, Melissa will walk through what containerization means for a legacy code base attempting to practice continuous integration and deployment, and provide key insight in to the sea change this provides for a testing organization. Learn from practical, real-world examples about how testing practices and pipelines can be streamlined to take advantage of the ad-hoc world of containerization. Come away with a real integration test plan that can reduce your cycle times by an order of magnitude while increasing overall product quality. Unlock the power of testing… with containers!

Slides: Continuous Testing with Containers