Come and have fun on our afterparty! Besides different fun activities there will be food and drinks as well!
You are here
Starship Technologies is building a fleet of autonomous robots designed to deliver goods locally in 15-30 minutes within a 2-3 mile radius. Currently, our robots are on the streets of 7 cities across 4 countries delivering packages, groceries and food. Starship wants to revolutionise the way goods are shipped and received, making it more efficient, cost effective and convenient for businesses and consumers.
There are many challenges in our operation that I'm not sure where to start! The robots must be really smart and solve problems in a vast number of situations, but they must also be reliable. The robot hardware must be well tested but we're also wanting to change, improve and replace parts as often as possible. We constantly test the entire robot ecosystem but something is always changing and the robot has so many programs communicating with each other in an asynchronous way, it becomes very difficult to construct the tests. I will discuss the complexities, benefits and challenges of this very exciting R&D operation bringing new hardware and software into public spaces for the first time in the world.
We are tech people. We understand apps, we understand gadgets. Some of us even understand what the cloud is and why it works or does not work. We get it.
But have you seen any actual users? The ones we, the industry, make this stuff for? Think about them for a second. These people had just about got used to the computers, Microsoft Office and printers that didn’t eat their sheets of paper anymore when everything changed again.
Now it’s about the cloud, collaboration, mobile devices, apps and so on. On the one hand, life can now be so much easier for an average user. On the other hand, however, they now have 10 different chat apps on their phones. And this is just one example.
In my keynote, I will talk about what I think is broken for users in tech and how these things should be fixed. A million small things. I will then move on to highlight bigger things and upcoming changes that will shape the lives of both tech people and users in the coming years: the continuing shift to mobility and new devices, the explosion in the number of internet users and the question, what is a computer and what it is supposed to do.
Everything is going to change, again. You’ve probably heard it from guys in suits for a million times but it’s actually true. I will explain. And I will not be wearing a suit.
We are not born testers. We become testers. Some of us become testers by circumstance, we "just stumble into it". Some of us choose the path of a tester. In both instances we then make choices to determine if, and when, we improve as testers. Everything we do in the name of 'testing' shapes us as a tester. By our every day actions we create ourselves as testers. And its important that we recognize this because we have to take responsibility for our own test approaches. Similarly we have to take responsibility for making ourselves better testers.
In this talk Alan will describe the dark times before he recognized his own responsibility, when he allowed circumstance to control his testing path, and the steps he has taken to improve his testing skills and make his own testing path, in the hope that you will be able to add some of those techniques to your own self improvement regime.
Where does a software tester’s ethical responsibility begin and end in a world of all-powerful software?
A recent Business Insider article described a “huge” online discussion between programmers about “the unethical and illegal things they’ve been asked to do”. Chances are high that you as a tester will someday be asked to do something in your work that conflicts with your values.
Software runs the world.
Software exerts great power over our lives: in our cars, homes, banks, medical labs and hospitals, governments, civic and emergency infrastructure… Algorithms and “learning systems” are increasingly taking over critical decision making. The sheer pervasiveness of software means that we frequently ignore its impacts. Yet when decision-making systems fail—or even when they work “correctly”—they can do irreparable and invisible harm.
Even seemingly insignificant software can present ethical issues for the people who build and test it. Apps that track locations or collect apparently trivial personal data can be used by corporations or governments to invade privacy, influence elections and shatter human rights.
Testers need to talk about potential ethical issues and how we can manage them positively and with integrity.
Until two years ago I had a fairly typical career in testing; perhaps you recognise it as similar to your own. I’ve been a Tester, a Test Manager, a Testing Coach and various other testing roles in between. I’ve lived my life in the software development industry within the friendly, inclusive world of software testing and the software testing community.
For most of the time I was happy in my bubble. But at times I was frustrated; frustrated with the way that testing is often perceived, frustrated that testers are frequently seen as second class citizens on development teams, and that the value that comes from good testing is not effectively recognised.
As the famous saying goes - “If you can’t beat em, join em”. So I did.
This talk is about different perspectives and how we, as testers are viewed. It’s about change and transition, and about the opportunities that we can all exploit to make us better testers, if only we are aware that they exist. And it’s a personal story of why the view of testing from outside our community may pleasantly surprise us all.
- A personal story of how moving from a traditional testing career to taking ownership for the whole software development process has influenced my views on testing.
- How a testing career is invaluable when building and running teams who operate with quality at their heart.
- Why we need to look outside of our own community in order to drive testing forward.
- Why Agile and Lean are driving fundamental changes to our roles within the testing industry and advice on how to positively manage this change.
- Experience based advice on how testers can work effectively with their managers and senior stakeholders for mutual benefit.
- Different perspectives on testing, based on my experience of both testing and whole team management.
- Advice on how to make the most of their place in their team, and how they can maximise the value of their testing.
- A better understanding of how to form their ‘testing message’ in a way that is relevant for their stakeholders.
- An alternative view of testing careers which may inspire them to consider alternative approaches.
- The confidence to influence quality from more angles than merely the traditional tester role.
What is that strange animal called design thinking? Is it the new savior of IT or just a hype? You decide after listening to this introduction to how to successfully build things.
Design thinking is based on a few key principles:
1. In order to be able to create really good stuff we need to understand users and business deeply. There is a big difference between collecting requirements and building empathy!
2. We need to model and define our problems in a way that everybody understands. Our models need to be simple enough but still useful.
3. The first draft of anything is shit - Ernest Hemingway is supposed to have said. In order to find really good solutions to problems we need to experiment a lot. One draft is just simply not good enough!
4. We will make mistakes and we need to learn fast so we can quickly get of the bad route to failure. User testing - early, often and rapid is an incredibly effective way of getting on track.
We fail to often. In order to succeed we need to:
1. Truly understand business and users by building empathy.
2. Modelling the user journey in a way that everyone is literally on the same page.
3. Understanding the need of lots of experimentation in order to find the best solution.
4. How to plan and execute really cheap, yet valuable, user testing.
When our ways of working make us feel distressed, we're inclined to hope for a quick, even radical, remedy. Missing relevant skills, we hire an expert over gradually teaching people who might be unwilling and unable. Having trouble with release quality and frequency, we turn to Agile and hope that magically improves the state of things.
For most of my career, I've personally lived by the principle of Every day is a learning opportunity, incrementally making me better. As years in the industry accrue, my principle has extended from individual development to helping organizations evolve. I don't believe in radical change, but in radical impact with small, incremental changes continuously. Getting a little better continuously helps you get a lot better over time, and the investment of being better grows interest.
In this talk, I will introduce change into a medium-sized organization one senior tester can bring in less than a year. The story to be told does not exist yet, as I've joined a new organization about a month ago. But instead of talking about past experiences, I will share an honest view into a recent experience. Experience from someone who has significant past experiences as a tester and believes that empirical evidence and collaboration are keys to successful software development. And empirical evidence sounds like a job for a tester. Recent matters, and future is where we're heading through continuous experimentation and learning.
- What Incremental Test Improvement looks like in timeframe of 9 months
- What Experiments and approaches to introducing them I could try?
- How to make good enough still better
In this presentation I will share some of the many tips I’ve learned while training, coaching and mentoring testers from around the world. I call the presentation “10 not obvious tips” as I’ve tried to identify things most testers I’ve met do wrong, don’t know about or the things they can improve the most. The goal is to extract the key lessons from big topics and present them in a compact, straight forward way.
- Risk catalogs
- Quick tests
- Creating a test strategy is actually quite simple
- Practice test techniques
- Visualize, visualize and visualize
- Any relevant oracles exist outside your company
- Learning is part of the work
- Good testability in the product is half the work
- Focus on value
- Coaching developers doesn’t have to be complicated
- Dare to break rules (but don’t go behind the backs of people)
- Dare to speak up
- Explain your testing
- Semi-automation is great
- Having fun as a measurement of good testing
Each of the tips above is a prepackaged takeaways and which ones are "key" will differ from participant to participant but the ones I will focus a little extra on will be
- Do check out test catalogs.
- Start to create test strategies, it's actually quite simple.
- There are so many oracles out there, using them will save you from so many "that's just your opinion" accusations
As an profession we are constantly striving to move away from the stereotypes that QA means no bugs in productions, that testing should be considered throughout the development process rather than just at the end. When a bug is found in released software we aim to look at how that bug escaped detection and improve the team's testing and coding processed going forward. However, the statement that "there's a bug in production" still drives a lightning bolt of self-doubt and blame through me. I start questioning internally whether I'm being blamed and kicking myself for missing the bug as I feel the adrenaline flow and my heart beat faster. Even in the best agile project team where blame is never mentioned - I still blame myself for letting the bug through (even though logically I know that I did no such thing). I'm sure I'm not alone.
The truth is that the adrenaline and self-doubt can be great drivers of understanding problems, finding or confirming fixes and staying alert until the situation is resolved. However, when these situations occur on a frequent basis, or in batches without sufficient recovery time then the blame and self-doubt can take hold.
It is hard to maintain a healthy and happy sense of self whilst also being the 'bad guy' pointing out the problems. Advice to deal with the situation by describing oneself as merely an "information provider" can exacerbate difficulties by separating the tester's personality and self from their role and the team that they work within. At the end of the day the information we provide is often bad news for one (or more) of our colleagues - let's acknowledge that fact.
I don't have a perfect solution but I have a few ideas to share from my own personal experience. Hopefully this talk will inspire others to share their stories and experiences about how we are all human and about how embracing our humanity can help us work better together.
- We can change or reinforce stereotypes of testers through our own actions
- Get involved and be part of your teams - regardless of job title we are human beings that need to work together
- Healthy, happy and empowered teams build awesome products
All started in 2010 when XING, the largest business network in German speaking countries, decided to go mobile and to staff a team with 2 iOS and Android developers, 2 software testers, 1 product manager and a freelance mobile designer. Back then the mobile team developed against a non-public API and tried to catch up with features from the web platform that had been developed over the past 7 years. In the initial 2 years everything was working more or less fine, but mobile traffic increased and exceeded half of the overall traffic of XING.com including iOS, Android and Windows Phone. Alongside the increased traffic, customers requested more mobile features, but feature development speed of the singular mobile team was too slow.
The development approach with only one mobile team did not scale compared to over 200 web developers in more than 15 teams. Therefore, the company decided to adapt the scale of the mobile development to the whole company and unleash mobile development onto the web teams.
As of early 2015, XING has 7 mobile teams with iOS and Android developers as well as software testers. The so-called domain teams are now responsible for feature development on web and mobile. However, the scaling onto multiple mobile development teams exceeding a total of 50 people bore new challenges that had to be solved.
In this talk Daniel will show you how XING is scaling mobile development and testing efforts to 7 mobile teams with more than 20 mobile developers and 12 (mobile) software testers. He will explain how the bi-weekly releases are coordinated and organized and how real users play an important role in the release process. The second part of this talk will concentrate on the mobile test automation solutions that are in use within the XING mobile teams and how an internal device cloud was established to provide several devices to all the mobile teams across different locations.
- How to scale mobile testing across several teams.
- How to organize bi-weekly native app releases for iOS and Android.
- How to setup a mobile test automation environment including a private device cloud.
Since the fall of 2014, I have been leading the first team of testers dedicated to building and promoting the use of automation at our company of over 2000 people. Sure, there have been developers writing unit tests for years, but no one has been trying to use software to test our software much beyond that. Not before my team that is.
In this talk, I will give a condensed view of the high(and low)lights of our journey. I will cover the lessons we learned, many of them the hard way, during our push to expand the intelligent use of automation across Test and Development roles.
This talk is targeted at anyone in an environment that currently does not make use of automation, but could benefit from it, especially if you have a divided Test and Development departments.
I will share the key learnings I have distilled from my team’s experiences so that you can hopefully avoid, or at least be prepared for, some of the hurdles we faced.
- You are adding work, which takes time from somewhere
- Top level promotion is a must for teams that aren’t self-motivating
- Befriend your IS team, or find ways to avoid them
- Start small, but think big
- Find your friends
Hang out a bit around those security guys, and very soon you’ll encounter the term “Threat modeling”.
It sounds cool and quite heavy, so you nod your head and let them go on rambling in their special lingo. What you don’t know is that a large part of the terms going over your head only because of a translation problem - They are using different words to describe something you are already familiar with.
In this talk we’ll see how threat modeling works and how it is similar to activities we do on a daily basis such as design reviews or risk analysis.
- Learn what is threat modeling and how to do it.
- Get a glimpse into security people language.
- Understand that security testing (a.k.a. penetration testing) is more about testing than it is about security, and that testers can and should contribute to this effort and even lead it.