European Testing Conference 2016

Cross-functional teams are a popular and on-trend approach to distributing the testing effort across software development. Ebay, Google, Microsoft are some of the more well-known names to have adopted this approach. In these companies, a test lead may oversee and support multiple teams reporting to the head of engineering.

Where does that leave the concept of test management and test manager? Are these ideas irrelevant in todays agile approach to software development?

At Tyro Payments, we’ve built a team from 5 to 23 testers in one year. We’ve experimented with test management and the role of test manager. We’ve constantly evolved our ideas about what it meant to lead testing in a high growth organisation.

This keynote will describe our growth, how we pivoted based on experimentation and learning. It will share some insights and traps to avoid. It will end with ideas about the future of test management and how it might fit into a future, where the only certainty is that testing will look very different to what is is today.

Testers are limited by their role. Testers are only allowed to be testers. We need to break the tester mold and replace it with a new role… the tester. The tester is a much bigger role than it currently is. Its much bigger, it much more valuable, its higher status and its much more fun. So do you want to be a tester? Or would you rather be a tester?

This is a tale of my journey als developer from hostility towards testers to subscribing to a software testing course. This shift happened over the last 7 years and helped me to discover a lot about myself. For a lot of people in the software craftsmanship community the “Tes” in SoCraTes was just added to make the name work. In case you haven’t heard about the software craftsmanship movement, just a little background. We believe in the values and principles described in the agile manifesto and we extend this. Working software, that is well-crafted; responding to change, while steadily adding value; individuals and interactions as part of a community of professionals; customer collaborations that lead to productive partnerships. We are lucky in Belgium since we have at least one “Tes” at our SoCraTes conference and I truly feel grateful that this triggered a new challenge in my head. Why do we need separate communities and conferences? So our goal for SoCraTesBE 2016 is to reinforce the “Tes” in SoCraTes. Within the agile community we have been pretty acceptant of analysts into our development teams. Maybe this is because we can better relate to what analysts really do. Maybe it’s because we feel the pain of not respecting the activity of analysing a problem. Maybe it’s because we truly feel the importance of analysis to help reinforce our development efforts. Why do we have more difficulty in incorporating testing into our development teams. Let’s look at the same 3 Rs to do this: Relate, Respect, Reinforce. If you want to know more about my journey, how SoCraTes became our new community name in Belgium and how we can RRR each other better and bridge the gap, join me and I’ll tell you my story.

I’ve wondered for some time whether much of Agile’s success was the result of the placebo effect, that is, good things happened because we believed they would. The placebo effect is a startling reminder of the power our minds have over our perceived reality. Now cognitive scientists tell us that this is only a small part of what our minds can do. Research has identified what I like to call “an agile mindset,” an attitude that equates failure and problems with opportunities for learning, a belief that we can all improve over time, that our abilities are not fixed but evolve with effort. What’s surprising about this research is the impact of an agile mindset on creativity and innovation, estimation, and collaboration in and out of the workplace. I’ll relate what’s known about this mindset and share some practical suggestions that can help all of us become even more agile.

To facilitate the observation of my testing skills, I’ve worked on a set of guidelines that help me in the reflection process. In this workshop, you’re welcome to try them out, maybe tweak them to your own reflection style, and share how you examine your own testing skills map. In the first part we will go through the guidelines and get a common understanding of the concepts used. In the second part of the workshop, you get to practice on it, while faced with a problem-solving situation: discovering the pattern of a wicked blackbox! We will end the workshop with, of course, a reflection on the whole experience - a debrief and conclusions. We’ll tackle questions like “How can you incorporate reflection in your testing work?”, “What are some ways to become more aware of our testing skills?”, and “How can all this be useful in our work activities?”

Security is a keyword of the day. You’re equally responsible for software security as any of your peers, be they developers, engineers, project and product managers - or testers. You might now something on security, and in this session, you get a feel of trying out some security testing in a mob format.

In this session, we take a vulnerable application and our instructors guide you to work on it together as a team, practicing techniques and working on actionable learning. In the end of the session, you can say that you have the experience of having worked through at least one security flaw with (thinking and software) tools that you could apply at your work. We will explore the clues that your applications can give you about it’s security status, and how we can communicate these issues to our stakeholders effectively.

Daniel Billing is your security expert with the security problem, and can show you what to do in detail. Maaret Pyhäjärvi facilitates the mob testing format: we all work taking turns on one computer, in a manner where all instructions come from people not on the computer.

Good testers can do amazing things with your code. Great testers cheat.

Let’s explore how to change code to make it very easy to test. Let’s show how to cheat and how to realize when we should be cheating.

We are going to look at lot’s of examples of tests to get a design sense of when you should be cheating, then go into 1 or 2 examples of how to make those cheats a reality.

In this workshop we will create executable specifications (aka tests) for a small piece of code. We will work together and experiment with different styles of test case definitions. Although the (FitNesse) specifications are not code, we will focus on their clean structure, e.g. avoiding duplication or hiding irrelevant details. We could create the perfect (technical) specification, which tells nothing about what is being checked. So we will further focus on the readability of our tests, e.g. by choosing names and changing fixture signatures to allow for different representations. In the end our specifications must be human-readable and highly expressive, even for non technical business people.

In this hands-on session we will work with FitNesse. A working knowledge of creating specifications in FitNesse is required. You will also need a laptop with Java installed. A the start of the workshop I will provide you with a fully working instance of FitNesse together with prepared bindings (aka fixtures) to get you started.

One of the most common reasons why software projects fail are due to misunderstood or poorly clarified requirements. Either because the business are not aware of the business goals they are trying to achieve or they fail to communicate them clearly so the development team understands.

Communication problems are not just a source of annoyance, they can damage a project greatly. When the team don’t have a shared understanding of the business domain or the business goals it can easily lead to gaps, inconsistencies or functionality that works completely different than what was intended. To make software projects succeed we need to solve the communication problem.

In this workshop you will experience how communication problems occur and how you can prevent them. You will learn how BDD (done right) will help you bridge the communication gap, flushing out wrong assumptions before development starts.

You will learn how to use real life examples as the building blocks for both specifications, automated tests and living documentation.

But above all, you will learn how having good conversations is the key to deliver software that matters.

Selenium WebDriver is a popular tool for driving the browsers for test automation. Many companies with browser-based applications have taken steps towards including Selenium WebDriver in their repertoire. There’s also a lot of reports on challenges: brittleness of tests with tests passing and failing randomly, trouble with maintenance as the test suites get bigger and difficulties working with Angular or Ajax enriched applications. If you can’t trust your tests, maintaining them takes a lot of time or your application feels to disagree with being easy to test, your tests might not be adding value.

In this workshop, we focus on Selenium WebDriver tests as code, and look into practices to overcome these common problems. We start with existing tests on an open source application, and we change them through refactoring to improve them. Join this session to improve your ability to create more maintainable and valuable tests with Selenium WebDriver.

Creativity is usually characterised by the ability to perceive things in new ways, finding hidden patterns, and making connections between seemingly unrelated phenomena.

It is sometimes thought that only certain people can be creative, and in order to be creative you need a special talent. This is far from the truth; everyone expresses creativity in their own unique way.

I love to express creativity though drawing and illustrations. Drawing has, in fact, enabled me to become a better tester and communicator, and as a result I have used this skill to learn the importance of collaboration and conversations within my development teams.

In this talk I will share with you my story of the how I have used drawing as a crucial element of software testing, particularly where discovery and collaboration are the ultimate outcome for ‘building the right thing’. I will also share how I have succeeded in enabling my own growth as a coach and facilitator and opened the doors to the next step in my career.

Creativity stems creativity - how will you unleash your creative side?

Unit Testing, UI testing, UX testing, Functional Testing. These are day to day activities for me. And no, I am not a tester, I am a developer. A developer who cannot code without testing. In this presentation I want to share with you how, as a developer I have come to use tests for: understanding the features, choosing the best user experience design, choosing the best technical solution, implementing the features and test them, of course :). You will see practical examples of how tools like Jasmine, Spock, Geb are used for all the above types of tests. You will see a project with tests and we will discuss on how you can use testing effectively to enhance your professional performance.

Join me and you will see a happy developer because testing exists!

Have you ever found yourself downloading a tool bar you didn’t want? How about suddenly receiving emails because you accidentally signed up for a mailing list? Possibly the worst yet, sent out invites to an application at your own expense? Well if you have, then you have been whacked with a Dark Pattern! These patterns are designed to fool you, into applying or buying things you had no intention of getting. In this presentation I will be going through the different types of dark patterns that are out there, how we should approach these as testers (is there a right way or a wrong way to deal with them), as well as covering some pros and cons on these controversial barely legal techniques that are used more frequently than you would think.

TDD (Test Driven Development) has become a widespread practice and CV buzzword in the development community.

When I started getting involved in the European Software Craftsmanship Community, I thought I knew what it was - I was surprised to learn there are many variations of it, and two main schools: the classic approach and the London school. Three years later, and I have been using the outside-in approach successfully in multiple projects and combining it with the classic approach.

This talk will give you an introduction with code examples using Java, Mockito and JUnit, illustrating the basic principles and when to choose it over other styles of TDD.

I will tell from my experiences on how to choose and combine an appropriate TDD approach for typical situations when developing business software.

Have you ever been in a project where in start of your testing you get an epic saying “Make the current design responsive”? Perhaps you don’t even know what it means in practice. How do you get started? How do you know when you are done?

In this talk I share my lessons on going through projects like this. We look at my first time testing a responsive website and a recent experience. You will learn to consider different environments; what things to test in practice; what tools to use; and how to deal with customer / designer to help the projects succeed.

At Pivotal, we strive to organize into balanced teams, with roles that feature overlapping areas of competence and concern. Testing - in many forms - is an essential part of how we support people in extending their attention beyond the traditional boundaries associated with their roles. Exploration helps people to grow into knowing and caring about aspects of the product far afield from the central authority of their role.

Testing is so important, in fact, that it is generally not sequestered into its own role; we trade off having a role with testing authority to make testing a core responsibility of all roles. This talk will discuss the use of exploratory testing practices, and their value and limitations, in the context of Pivotal’s Extreme Programming based approach to balanced product teams.

Testing apps and using mobile analytics can both help improve the overall quality of an app when done well. Neither is sufficient in isolation. This session introduces both topics and how they can be usefully combined to significantly improve the value of both while also reducing the deficiencies in the constituent parts.

Skilled exploratory testing includes a lot of tacit knowledge, often acquired over a long period of time, learning piece by piece. Often the testers themselves have hard time explaining what and why they are doing to identify risks and problems.

This talk is a demonstration talk. Let’s look at an expert tester breaking down a problem, organizing their insights, structuring their thoughts and forming questions while testing. The talk shows you how exploratory testing is learning about an application, an empirical experiment at a time.

Where does performance testing fit in an agile world? What are its challenges and advantages? Does it make sense to unite agile and performance testing? Can performance testing help organisations to develop higher quality software in less time while reducing development costs?

Based on Mieke’s experience as a senior test engineer and an automated tools specialist, she will share with you her insights & challenges running performance testing in Agile projects.

Ever since James Bach and Michael Bolton introduced the Testing and Checking distinctions in to my testing world, I have embraced them. For me, they were the missing piece to my vocabulary regarding testing. I knew there was differences between what my automation was doing and what I was doing, but I couldn’t articulate that. However this isn’t the case for everyone, there are many people who don’t see the benefit in the distinction, and refuse to use them. That’s OK. However for me, I like it, I use it, and I encourage others to use it.

In this talk I want to share with you my experiences of using the terms in several workplaces. How I’ve had great success in educating others about testing using these terms, and how it’s changed their views on my work. How adopting these distinctions has allowed me to think deeper about the role of automation in testing, and allow me to get the most out of tools. How my communication about my testing has improved, but also how others talk about testing with me has improved, allowing us to align and work smarter and faster.

Device fragmentation is one of the biggest challenges in mobile testing in general. When it comes to mobile games specifically, not supporting a few device models that are very popular in certain markets can lead to significant revenue losses. Thus, the typical approach of choosing a sample of devices to test your games on no longer seems like a valuable strategy.

In this presentation, I discuss my own experience as a test consultant at Altom, working with Bitbar, a Finnish startup, to build a test framework that enables mobile game companies to run efficient automated checks on hundreds of devices simultaneously, through the use of Testdroid Cloud - Bitbar’s mobile device cloud solution.

Using Appium and image recognition algorithms, we built a solution that enables game companies to test their games on real iOS and Android devices in the cloud, even when the games are developed with game engines like Unity or Unreal Engine, where the UI objects are not exposed. This talk will show examples of this framework in use and will give you a great starting point for dealing with device fragmentation when it comes to testing mobile games.

Pair testing is a way of testing where two people work together on a test assignment. As a pair, you can be more valuable than as a single person. You are each others backup, progress will not stop if one person can’t participate. Working as a pair will also increase the speed of your test work. One person is executing the tests while, at the same time, the other person is making notes. At any time you can switch roles.

To work successfully as a pair, some arrangements need to be agreed upon. In my talk, I will share my own experiences about what is needed to set up pair testing, how to produce value as a pair, and how to explain the benefits of pair testing to your stakeholders. I will demonstrate how testing as a pair can (and will) improve the quality of your work.

With this talk I give the audience information how to convince their team lead that pair testing can and will improve the quality of the test work. This information contains

• How to set up pair testing
• Producing value as a pair
• Explaining the benefits of pairing to your team and management

For all the things that the human mind can do, filling in gaps of information is one of the most interesting.

We have seen studies on this in many different areas of work. Statisticians, lawyers and scientists have identified that confirmation bias and the principles of inference are two ways we already know that our brain takes short cuts. As a team member, and even more as a tester, it is important to accept and deal with these short comings.

In this talk, Abby will look at the many places in our day to day team interactions where our biases paired with our desire to be proven correct impact the quality of our testing. Something as innocent as assuming the level of quality in work done before testing or verifying “happy path” first can wildly impact the end result. While there is no way to completely remove bias and inference from our lives, we can make them more deliberate in an effort to be even more impactful testers. You will leave this session with ideas for how you can begin on the road to awareness.

(PS…try counting the number of times the letter f is used in the first sentence. It may reveal your own brain’s inferences!)

Manual testing is most often done end-to-end. Tests are performed through the user interface. When testing gets automated, this is where most organizations start. They start with automating the way they do things now. The new way is faster, but it isn’t fast enough. And not robust enough.

It is unnecessarily complicated to understand why an end-to-end test fails. There are usually many different possibilities when something doesn’t work.

The number of possible paths through a reasonably large application will very fast make it impossible to cover them all. Combinatorics is your enemy.

The solution is to minimize the tests that passes through many layers in your application. Minimizing doesn’t mean removing the end-to-end tests. They are still needed. But much fewer than most organizations seem to think.

I will show you why the testing pyramid need to be very wide. You will understand why this is an absolute necessity if all possible paths through the application should be tested.

In other words, let me show you why your tests must be very shallow.

Hey, do you remember what everyone was asking what the role of the tester would be in an agile team? It’s happening again!

And things are changing again. A team that takes on the challenge to release their every commit certainly will take testing seriously. It will need to evolve new ways of testing. It will have new dynamics of testers working with developers. It will find new ways of of interacting with customers, stakeholders and product owners.

In this talk we’ll look at how continuous deployment changes the dynamics of an agile team. How quality moves even more to the center of the stage. How that changes the role of the tester once again. How it changes the role of developers, too. How this practice allows you to put the customer center stage again. And how that, too, has testing competencies at its core. And we’ll not forget DevOps, and how monitoring can be a continuous testing strategy.