When visuals come under test automation, the outcome rarely justifies the cost. Visual tests tend to be too brittle, to difficult to maintain, and too slow to execute for quick iterative delivery cycles. However, recent improvements in cloud computing and browser capabilities make it possible to change the economics of the test automation pyramid. Gojko will talk propose a new view, looking at how trends such as approval testing, cloud functions and automated image analysis can help us automate acceptance/regression tests for visual look and feel in a visual language, rather than xUnit style code, and make such tests easy to write, understand, execute and maintain.

[Slides]

Since the days before recorded history, dogs have been man’s best friend. Dogs obey the pack rules based on an established hierarchy, providing stability for the greater good. With their positivity and teamwork ability, dogs demonstrate traits that are admirable in a friend, colleague or employee. As an industry, software testers have dog traits well ingrained in our culture. It is time to move beyond, and while keeping the good traits we can learn from dogs, incorporate more tricks from cats.

Cats have a different history, being revered as Gods in ancient Egypt. They have yet to forget it. Cats will be fine with or without our approval or intervention, giving them a distinct survival advantage. Cats are charming with an alluring purr that contributes to healing as well as soothing the stress of their human companions. Feline traits like patience and seeing in the dark are a huge advantage when lacking vital information. Cats come equipped with whiskers (an excellent adaptable tool of self-awareness) that help them determine in advance what routes are possible, and which to rule out. Like cats, modern testers may share separate territory, be a part of a larger testing group, or be a lone feral tester in the wilds of an Agile project. Testers may have abundant requirements and ability to question developers, or they may have absolutely nothing. If they test like a cat they will survive either way.

Saying software testing is dead is dead. The dog days of testing are over. Don’t work like a dog. Test like a cat!

There are still problems beyond the ability of AIs to solve. From mapping craters on rocky worlds, to puzzling out what geographic features are visible in an astronaut images, NASA scientists rely on the volunteers to transform images into machine readable databases. While volunteers are generally well-intentioned, their errors don’t come with friendly flags like 206 or 418 to warn the coder why their responses are out of sorts. Also, some contributors aren’t well intentioned, and may simply write “poop” (or worse) when identifying a volcano.

Developing tests that will sift the swear words from the science words, and will exclude the cat-on-keyboard-clicks from the volunteer clicks is an organic process that requires a special level of creativity and an ability to embrace the absurd. This talk will give you an insider view on how to employ testing when <import humans> is part of your software toolkit.

[Slides]

“I don’t know.”

These might just be the hardest words to say in any language. We avoid saying them, scared of coming across as doubtful and uncertain. Colleagues expect us to be firm and certain, providing clear answers. Over the past years, I grew increasingly uncomfortable with that. I ended up having a hard time being sure of anything.

“You’re rejecting certainty”, someone said. “That’s skepticism. You’re a tester, embrace it!”

That sounded like a good idea, but this left me with a new challenge: how does one embrace skepticism, and how can this help me improve my testing?

I wanted to get to the bottom of this and, for a year, decided to submerge myself in all things skeptic in hope of finding clues to help me with my testing. It was a fascinating journey that led me from philosophy, critical thinking and science to pseudo-science and the paranormal.

This is the story of how I embraced skepticism and how this influenced my testing: by adopting a skeptic manifesto and creating a portfolio of critical thinking heuristics that can be a valuable addition to any tester’s toolbox. You will leave armed with tips not only on how to muster up the courage to admit not knowing things, but also on improving your questioning skills and reflexes to reject certainty, empowered by the biggest skeptical force of all: knowing that we’re easy to fool.

[Slides] [Slides] [Slides]

Many​ ​teams​ ​use​ ​continuous​ ​integration​ ​(CI)​ ​and/or​ ​continuous​ ​delivery​ ​(CD)​ ​principles​ ​to​ ​gain confidence​ ​in​ ​their​ ​product​ ​deployments​ ​by​ ​speeding​ ​up​ ​feedback​ ​loops​ ​and​ ​progressively mitigating​ ​risks.​ ​The​ ​confidence​ ​your​ ​team​ ​has​ ​in​ ​your​ ​pipeline​ ​likely​ ​defines​ ​where​ ​you​ ​fall​ ​on the​ ​spectrum​ ​between​ ​high-risk,​ ​stressful​ ​deployments​ ​and​ ​low-risk,​ ​uneventful​ ​ones.​ ​​ ​Yet,​ ​if you’re​ ​not​ ​a​ ​DevOps​ ​expert,​ ​it’s​ ​easy​ ​to​ ​get​ ​confused​ ​and​ ​overwhelmed​ ​by​ ​all​ ​the​ ​jargon​ ​around CD​ ​principles,​ ​CI​ ​tooling,​ ​and​ ​common​ ​pipeline​ ​patterns.​ ​This​ ​confusion​ ​in​ ​language​ ​can​ ​limit asking​ ​the​ ​important​ ​question:​ ​“how​ ​does​ ​CI​ ​and​ ​CD​ ​really​ ​relate​ ​to​ ​testing​ ​and​ ​quality?”

In​ ​this​ ​hands-on​ ​workshop,​ ​Abby​ ​Bangser​ ​and​ ​Lisa​ ​Crispin​ ​will​ ​help​ ​you​ ​learn​ ​why​ ​your​ ​team needs​ ​pipelines,​ ​what​ ​you​ ​can​ ​expect​ ​from​ ​a​ ​pipeline,​ ​and​ ​their​ ​power​ ​when​ ​used​ ​properly. Whether​ ​your​ ​tests​ ​take​ ​minutes​ ​or​ ​days,​ ​and​ ​whether​ ​your​ ​deploys​ ​happen​ ​hourly​ ​or​ ​quarterly, you’ll​ ​discover​ ​benefits.​ ​You’ll​ ​participate​ ​in​ ​a​ ​simulation​ ​to​ ​visualize​ ​your​ ​team’s​ ​current​ ​path​ ​to production​ ​and​ ​uncover​ ​risks​ ​to​ ​both​ ​your​ ​product​ ​and​ ​your​ ​deployment​ ​process.​ ​No​ ​laptops required,​ ​just​ ​bring​ ​your​ ​curiosity.

Learning​ ​outcomes​ ​include:

● CD​ ​concepts​ ​at​ ​a​ ​high​ ​level,​ ​and​ ​the​ ​differences​ ​between​ ​CI​ ​and​ ​CD

● Common​ ​terminology​ ​and​ ​a​ ​generic​ ​question​ ​list​ ​to​ ​engage​ ​with​ ​pipelines​ ​as​ ​a​ ​practice within​ ​your​ ​team

● Modeling​ ​techniques​ ​to​ ​visualize​ ​your​ ​team’s​ ​current​ ​and​ ​desired​ ​path​ ​to​ ​production, ways​ ​you​ ​and​ ​your​ ​team​ ​can​ ​identify​ ​and​ ​discuss​ ​pain​ ​points,​ ​and​ ​design​ ​experiments​ ​to make​ ​them​ ​less​ ​painful

● Experience​ ​in​ ​analyzing​ ​pipelines​ ​from​ ​different​ ​perspectives​ ​to​ ​created​ ​a​ ​layered diagram​ ​of​ ​feedback​ ​loops,​ ​risks​ ​mitigated,​ ​and​ ​questions​ ​answered.

The goal of this workshop is to familiarize the participants with a series of tools and concepts that are useful in the DevOps world. We will start from zero and in the end we will have a continuous delivery environment set up. Everything is hands-on. As a prerequisite, you need Ubuntu 16.04 running (VM or on your computer). In the beginning we will have a setup phase and we will discuss the tools and concepts that we will be working with. Then, we will go to the practical part, where we will configure everything. We will close with conclusions and Q&A. After this workshop, you will have the environment all set up and you can continue exploring after the conference, if you feel like it.

Tools that we will use: git, docker, go.cd, kubernetes, AWS CLI.

We have a 20 participants limit per day. Please register for the workshop here!

Workshop requirements: Bring a laptop

The workshop is prepared on an Ubuntu 16.04 machine.

If you are using this OS, make sure you have the following prerequisites:

• curl,
• git,
• docker,
• Chrome,
• dockerhub account.

If you don’t have an Ubuntu 16.04 OS, follow all the steps below:

Install VirtualBox.

Import base image (that you can download from here).

[Slides]

Exploratory testing isn’t just for websites and mobile applications - the same techniques can help you test at the API level as well! Tools like Postman make it easier than ever to learn about the services that power your application. This session will cover multiple ways in which Postman can aid your API testing, including proxies, mocking, authentication, header management, and much more. Don’t limit yourself to the surface of your application - by exploring your APIs, you can increase your overall understanding of your application, find critical issues earlier in the development cycle, and provide a solid base for UI testing. Plus it’s fun!

In this talk, I will share our take on Continuous Delivery and practical experiences from delivery pipeline implementation projects.In this talk, I will share our take on how Continuous Delivery principles when combined with comprehensive test automation approach and DevOps practices effectively reduces the Work in Progress (WiP). We have seen firsthand the importance of limiting WiP and its effect on software teams’ development throughput and overall quality improvement.

To keep things practical I will also discuss our experiences from delivery pipeline implementation projects.

Behaviour Driven Development is an agile development technique that improves collaboration between technical and non-­technical members of the team, by exploring the problem using examples. These examples then get turned into executable specifications, often called ‘scenarios’. The scenarios should be easy to read by all team members, but writing them expressively is harder than it looks!

In this workshop you will learn how to write expressive BDD scenarios. We’ll start by giving you a very brief introduction to BDD/ATDD. You’ll then be introduced to different writing styles by reviewing pre­prepared scenarios. Finally, you’ll get a chance to write your own scenarios based on examples that we’ll bring along.

We’ll be using Gherkin, the syntax used by Cucumber and SpecFlow ­ but you won’t need a computer. And, you’ll leave with a checklist of tips that you can use the next time you sit down to write a scenario.

Recently I’ve been asked to use test cases to do my work, the argument being that this is the ONLY way to conduct and capture the work of a tester, regardless of whether the software is developed in a

This came as bit of a shock to me(!) because for years I’ve been working on agile teams performing and documenting work using tools and approaches like: task breakdowns, session-based testing and session notes, debriefs, mind-maps and checklists.

What to do?!

Truth be told I didn’t handle the situation very well, which got me thinking – what could I have done better? That’s what this workshop is all about. During the workshop you will gain a better understanding of what scripted vs exploratory testing really means, when it’s a good idea to use one over the other and learn a few short sharp exercises to run with your colleagues when an approach is being imposed on you.

Here are some learning outcomes we’ll be aiming for:

What is the difference between scripted and exploratory work?

What are the opportunity costs of each approach?

Do they have strengths and weaknesses or should we always use one approach over the other?

[Slides]

“Copy… paste… modify one line… done!”

Writing system-level automation can be quite complex - and for some odd reason, many testers have their first work-related coding in this area. Luckily, the internet is here to help. There are many good advice on everything we might need -There are (open source) tools that cover the upper layers: Frameworks that support BDD or KDT, enable easy maintenance of multiple test suites and re-running failed tests. There are awesome tools that cover the lower layers that enable driving browsers or mobile devices, send REST or SOAP requests and generally do whatever we might want to do. So how come our test-code is so difficult to maintain? Why doesn’t it look as pretty as the examples we find online?

The reason for that is that the advice we find are missing one part - the part where no generic tool can really help you: Organizing the business actions in a way that is easy to both maintain and use.

In this talk we’ll go over three ways of organizing your automation middle layer - from a quick gain for the short term that you probably already use, to something a bit more elaborate that your future selves may not hate.

[Slides]

I’ll be presenting lightning demo’s of some of the most useful tools that I have picked during my years in software development. Will cover 10 tools, from a wide area of categories such as collaboration, planning, test automation, and general productivity hacks.

We did two iteration of automated testing. In the first iteration we created our own tool which enabled testing without programming. In the second iteration we move to ready tools and taught our testers to program. This is that story and why we ended up at this decision.

[Slides]

Microservices is a way to organize your system that provides both opportunities and difficulties for testing. I recently worked with a company transitioning away from a monolithic architecture, and helped them to re-design their automated testing strategy for the new architecture. In this talk I’d like to share some concrete automated testing techniques that I found useful, including selective deployment, approval testing, and event monitoring. I’ll also relate some challenges we encountered enabling the teams developing the various services be able to test and deploy independently of one another.

[Slides]

In a lean cross-functional team, testers are not just testing, developers are not just developing. They often have to work outside of their core expertise in which they could be less effective. In this talk, I will share my experience on how I helped upskill the developers to broaden their testing skills by introducing test heuristics. And how by doing so they could take on testing more effectively.

[Slides] [InfoQ QA article]

Main statement: Multiply your knowledge by finding your ‘testing buddy’ anywhere in the world.

The product development and testing world has never experienced such a boom as it has in recent years. Tons of concepts are thrown at you in the digital world via tweets, blog posts, podcasts, and more. Inspiration can be found everywhere you look. But would these insights work in your professional environment as well? Pair up and learn by sharing actual experiences!

Accomplishing something major in your industry or company has always been at the top of your list, but you struggle to find the motivation and drive to do so? Collaborate and inspire each other to achieve your ultimate goals!

Come with us on our journey on how we found each other and what we have learned so far. Pairing up was one of the best experiences we had, so we want to spread the word and encourage you to give it a try. The conference doesn’t have to end on the day you leave - it’s where the fun begins and relationships grow!

Discover how people from different continents, countries, companies, and cultures can work together to achieve one common goal. The answer to gaining the desired knowledge might be sitting with a peer in another part of the world - so break down the barriers of distance, share your ideas and experiences, and find your personal testing buddy!

[Slides]

Test Driven Development, TDD, is often talked about, and increasingly adopted. So, what is TDD and if the programmers are doing that, how come there are still bugs? This talk explores what TDD often is, how it could be, and the benefits it might bring. Join Lynoure to hear about her real life experiences of things going well and not so well in her pursuit of the minimal yet relevant test case in TDD.

[Slides]

This session digs into a popular interview question, illuminating the importance of asking questions before jumping in to test something. We look at how you would test a text field with real text fields leading us to different approaches to testing them. This session is about insightful testing fun and going deeper than the question itself on surface level leads you. Given all the tools we have these days, how would you really test a text field?

It’s not only developers job to monitor system performance, testers can learn and help also… Performance and functional testing are things, we, as testers, talk about often. We write some tests, execute them, get metrics, tune or fix system… and so on. But what happens when the product goes “live”? Are we observing what is happening with it? Users have funny and unpredictable ways of using a product. Are we aware how is our system behaving on production?

My daily job consists of monitoring our system in production and learning for it. In this talk I’ll explain what added value a tester brings up in monitoring system, and what they can learn by doing this. Some benefits include:

– oracles for our performance tests

– learning about system behavior

– observing (potential) errors in the systems

– preventing bugs getting to users before we fix them

I’ll show you which tools we use at our projects, how we use them and what can we see by observing them all together, because one tool is never enough.

Key-Learnings:

1. Why do testers need to monitor performance of the system?
2. What can a tester find out from those metrics and behaviours?
3. Which tools can be helpful and how to combine them?

[Slides]

Empower teams to be on the same page and help ourselves in return to better focus on QA

In this talk, we will discuss an idea of creating a code monitoring and talking bot which has potential to prevent or resolve communication problems throughout the sprint (QA-release) cycle. Will also be sharing exactly how I leveraged the power of existing systems to create it and know how you can also use and create your own personal 24*7 guard/assistant for your team.

Why should you attend this:

Imagine, it is one of your Release Day and the code started breaking all of a sudden, tested features not working anymore, and it is going to take time to figure out whom to reach & people start passing the buck? Experienced such stormy sail on your release day? Amidst all this, losing time for release deployment as the traffic on your product is peaking up or exceeding the deadline promised to the clients. Manual monitoring doesn’t look a viable/scalable solution ? Yes, in fast paced organisations like us, it is a burning problem. Do you also feel the same?

• Already nodding your head in agreement? Many times somewhere deep down, did you feel like escaping from the heated discussion or wished there were snapshots of all the important events which could give you the clues/traceback to hunt & chuck the wrong commits out of the system and move ahead. Or even better some software which you could just hook to your system which would never let us reach such a chaotic state itself by blocking/notifying any wrong doings.
• Or are you someone just starting off your company and do not want to go through the same challenges we went through & help your developers focus only on building the awesome stuff which you wanted to
• Or are you among those telling yourself “we have already solved it”. As a tech geek, are you excited to explore a different way as to how we are solving it?

Eager to know how? Come let’s talk and take a sneak peek at how we are dealing with these at MoEngage Inc. And yes, get to start using the solution open-sourced in almost no time. Wait! Did I tell you it is open sourced too :)

~ A little attempt towards making healthier work culture and keeping the smart brains happier :-)

Outline of Talk:

The talk is about a bot which can help your team “preventing last moment panic moments” and so helps all the teams be on same page:

1. Problem analysis & origin of the bot - 10 min
2. The bot at your service - 13 min
   • with a live demo, we will discover, how we got our first bot live and then what more handy features it brought @ work, that it is like a team member now.
   • The exponential future possibilities - 2 min
3. Questions & Answers - 5 min

Key takeaways:

• An idea, which can empower each member across the teams especially the QA team by bringing transparency of entire system with least efforts.
• An idea, how a little automation effort can prevent last minute panic moments at the time of release.
• You love robots and that too open sourced? Join and know more insights.

[Slides]

Having worked together with many of the industry leading crowd testing providers, Ron will tell the story of his journey as a Test Lead striving to make the last mile to the customer a success. He crowd tested mobile & web products for an international construction software company, and his experience report aims at helping attendees avoid mistakes he made, showing common pitfalls and sharing what worked well. This talk will shed light on what can help you to find the right long-term strategy and provider for your needs. You will find advice on how to adjust your test strategy, what to pursue in a pilot, how to target relevant device groups and equip you with what’s important in your journey to making your mobile releases a success, with happy customers and happy testers.

[Slides]

Come to this session to learn more about what we’re doing when we’re exploratory testing! If you know the theory of exploratory testing but sometimes have trouble articulating what you’re doing – or if you’d like to become more aware of the what and how of your testing, then this is the session for you. By doing live exploratory testing sessions with debriefs, we’ll examine how we approach exploratory testing, how we create and test our models, and how we can communicate what we’re doing to improve our testing itself, our communication about testing, and our sharing of testing knowledge.

The session is aimed at testers, developers, product owners, … – anyone who ever finds themselves challenging software to a testing duel 😊

Interacting with UI components in tests is hard. See a way to quickly reference them and keep your code clean. Glance is a language that helps guide the reader of our tests to the component in a natural/understandable/readable/simple way. Come take a Glance ;)

Many times we test a single scenario, but how do you test thousands or millions of scenarios? If you can identify some common properties, computers will automate the testing of hundreds of thousands for you. In this talk we will look at the three most common properties.

• Equality - f(x)=g(x)
• Inverse - f-1(f(x))=x
• Sanity - f(x)!=disaster

We will look into how to identify these properties and the basics on how to write these tests.

[Slides]

Let me take you out of your comfort zone to start finding ways to test the hard stuff.

We often rely on a small set of testing techniques that serve us well in familiar situations. But what do we do when we encounter technologies or requirements that don’t fit these techniques? And how do we cope when there are no established testing patterns for these situations?

In this session I want to focus on idiom: I’ll use some case studies to draw out some lessons in how to work idiomatically with new systems, and I’ll talk about how a broad knowledge of testing idioms can help us find the right technique for testing them.

These will be small 8 person discussions, facilitated by a speaker. Their purpose is to get you talking about the topics that you care about with your fellow conference attendants. For those of you familiar with kanban or scrum board, the structure of this activity will feel familiar. For the rest of you, you can learn about it here.

Marianne will be joining us as a visual historian aka. sketch noter.

At the end of the conference we do an Open Space. This is your chance to get exactly what you need from European Testing Conference. Open Space sessions can be on anything and some of the best ones have titles like: “I am having trouble with ___ Please Help!”

This is a session to get everyone introduced to at least 10 new people. You will draw a personal mind-map (with nodes: personal, work, accomplishments). Every 5 minutes you will exchange mind-maps with a new person, and each of you will ask the others about the items you are interested in. Afterwards, the conference will be an even friendlier place.