Ensemble testing - a whole group working at the same time on the same computer - is about learning practical skills in the context of applying the skills to a real problem. In this session, our real problem is testing location based content on websites. Selenium 4 gives us a chance of setting up the basic use case for this: pick up a test target, drive it with code collecting geolocation-based screenshots on multiple browsers on a grid to explore the location based differences. 

We set up an ensemble testing session facilitated in popcorn style. We take volunteers from the audience to be our hands and brains on a shared computer, rotating frequently on who is on the keyboard and in control of decisions, to work together to automate a scenario. While you can pick up new information even if you know the technologies in use, you don’t need to know the feature under test or the features of selenium 4 to participate in this session, it is enough we have some people that do. We expect participants to be ready to take part in testing in a facilitated environment where we work together as a group in learning the application and testing. We will test on an instructor machine with a Java 11 Selenium 4 with webdriverManager and Selenium Server on IntelliJ idea, and the lessons you draw are applicable across languages, and knowledge of Java is not required to learn in this session. 

In ensemble testing, we care about both learning and contributing.  Software development is not about getting the most out of us, but the best out of us - avoiding the ping pong, creating ideas we would not generate alone and sharpening our skills. We don't know what we don't know but can recognize it in the context of doing it. Those who learn the fastest, do best.

Looking back at test automation in a product development team for describing patterns of success for research purposes, we identified themes where the experienced success significantly differed from what the literature at large was describing. With those lessons, I moved to a new organization and took upon myself to facilitate a transformation to whole-team test automation over multiple teams, one at a time, one after the other. In this talk, we will revisit the research from one organization two years ago with lessons from another in the last two years. 

In this talk, I will introduce you to my core patterns to practice-based test automation transformation. I can't promise a recipe I would apply, as my recipe changes and adapts as I work through teams, but I can promise experiences of the same patterns working on multiple occasions as well as examples of how my go-to patterns turned out inapplicable. We'll discuss moving from specialist language to generalist language, visualizing testing debt and coverage, using visualization to showcase progress made of continuous flow of small changes, choosing to release based on automation no matter how little test automation there is, and growing individual competencies by sharing YOUR screen when working together. 

Recent years have moved teams away from having testers to having developers who test. When we accept we can’t automate without exploring and we can’t explore without automating, the split to manual and automation makes little sense. We need to discover new ways of decomposing the testing work to share that in the team. 

In this effort, we’ve discovered that what we used to expect from one tester, is now split to four developers each with a different emphasis for the team to be successful together. In this talk, we look at how our virtual testing team - a whole team responsible for both developing and testing an application, has split the many hats of testing identifying 15 hats for us to distribute the best way the team sees fit. 

Who carries the hats of a product historian, on-caller, parafunctionalist or feature shaper in your team, and which of the hats are hard to keep up in your current team composition?

I know something you don’t know. You know something I don’t know. And I don’t know what you know that I would need to know. This is where individual contributor approach to software development and testing breaks down. Why aren’t we working together, contributing together and learning together? Why do we, often at best, collaborate on the requirements and understanding of what to build, and then step away for implementation, only to come back to test it after?

This talk looks into my experiences in pairing (two people one computer) and mobbing (more than two people one computer), and the wonders of being a non-programming tester whose ideas get translated into code as equal. The journey to get to pairing and mobbing has been a rocky road, with loads of practical tips to offer on how to approach it.

In software development, those who learn the fastest do best. Could pairing and mobbing take us teamwork to the next level by enabling learning between everyone? Lessons specific to skillsets rub in both ways, leaving everyone better off after the experience.

For a decade of software product agile, we had worked in a structure where business responsibility of what to build was allocated to a product owner and the responsibility of how to build it was allocated to a development team. Product owner would maintain a backlog, act as voice of the customers. Until one day we realized that the choice of what to build or fix is hard, and critical to everyone’s success. If we wanted to do it poorly, we delegated it to a single product owner.

We started a no product owner experiment. For three months, we experienced the development team delivering multitudes of value to what we had grown to expect, and innovate customer-oriented solutions in direct collaboration with customers. Team satisfaction and happiness bloomed. The experiment turned into a continuous way of working.

Customer-focused team directly in touch with their customers performs better without a proxy. Join me to learn how the decision power shared for everyone in the team transformed the ability to deliver, and how collaboration is organized with product experts and business representatives.

Delivering continuously - easier said than done. As I joined my team delivering Windows Desktop products two years ago with the aspiration of implementing continuous delivery, I was told it cannot be done. It started from the fact that making a single release was five-day effort, and continued with “no user would allow us to deliver frequently”.

Two years later, making a release takes us two hours and the way we work together looks very different. With the principle of fixing maintenance issues in the latest release has resulted in improved flow forward and savings of effort in supporting small number of releases.

This talk goes through our lessons learned on the journey of shortening release cycles to a continuous daily flow.

We’ve experienced three essentially different sets of practices, with the core difference coming from release frequency. The good place is when we deliver continuously. The soulsucking place is when we deliver on two week cadence. And the insane asylum is when we deliver just once at the end of the project.

Think of it like this: a pool is not just a bigger bathtub. The things you can do in a pool are different to those you can do in a bathtub. While both are containers of water, they serve different purposes. It is the same with release frequency. While it is all still releases, the continuous ones enable different practices.

I’m using exploratory testing to design which tests I leave behind as automated. Creating automation forces me to explore details in a natural way. When an automated test fails, it is an invitation to explore. The two sides of testing, automation, and exploration, complement each other. These intertwine the considerations of the best for today and for the future.

For great testing bringing value now as well as when we are not around, we need to be great at testing - uncovering relevant information - and programming - building maintainable test systems. At the core of all this is learning. With our industry doubling in size every five years, half of us have less than five years of experience. We all start somewhere on our learning journey.

In this talk, we look at the skills-focused path to better testing in the intersection of automation and exploratory testing. We can arrive at the intersection by enhancing our individual skills, or our collaboration skills. What could you do to become one of those testers who companies seek after that work well in the intersection, giving up the false dichotomy?