TestBash Germany 2018
Culture is Often Framed by What You DON’T Say, Not Necessarily by What You Do Say.
Your company brags of it’s geek gaming culture.
Part of your company recruiting highlights pub and party nights.
Strong anecdotal use of sports throughout the training material.
These are common examples of well intentioned, but potentially limiting statements about culture that many organizations apply in an attempt to “attract the right fit”. By choosing language that supports an ecosystem that already exists, we may unintentionally deter many complementary candidates who feel they might not be accepted. In addition, we are imposing discrete limits on the organization's ability to adapt and grow based on past success instead of future opportunities.
This is a microcosm of what is occurring around culture within the Agile workspace. While we claim to support the evolution of resilient autonomous teams, a desire to define the culture in explicit marketable terms can create a barrier to entry. Are you really creating culture and fostering an environment for agility, or are you creating exclusive spaces? A lot can be derived from the specific words you use to describe your team, culture and collaboration schemes.
I will explore the use of resilient and inclusive language, that can:
- Support building stronger, diverse teams,
- Support an ever evolving Agile culture,
- Avoid assigned meaning that may alienate individuals through our choice of words… both spoken and unspoken.
- Why language around culture can impose unintended limits on opportunities.
- How the language we choose is connected to our unconscious biases.
- Inclusion is an intentional act, often initiated to recognize the need for change.
- Identifying how diversity in teams can provide stronger outcomes through concatenated knowledge.
- Challenging the notion of an existing, consistent and explicit culture as a desirable (or even possible) thing.
Ash, a former chef, put recipes aside when she began her career in software development, falling back on her skills in engineering she acquired as a kid building computers with her brother. A progressive type, Ash has focused her efforts within technology on bringing awareness to the inclusion of women and people of colour, especially in the Context-Driven Testing and Agile communities. An avid fan of matching business needs with technological solutions, you can find her doing her best work on whichever coast is the sunniest. Having helped teams build out testing practices, formulate Agile processes and redefine culture, she now works as an Engineering Manager in Quality for Credit Karma and continues consulting based out of San Francisco.
How to Scale Mobile Testing Across Several Teams
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.
Hi, my name is Daniel Knott and I am a passionate software tester since 2008. In my career I worked for companies from different industries such as IBM, Accenture, XING and AOE. In different agile projects I gained strong knowledge in different areas of software testing e.g. mobile, search and recommendation technologies, web and desktop applications.
Since 2011, I am the blogger of this blog and publish posts about software testing, mobile testing and any other kind of interesting topics around software development. If I find the time, I am also a speaker at testing conferences and quality assurance articles. An overview of my publications can be found here.
In 2014, I published my first book about mobile testing. The title of the book is “Hands-On Mobile App Testing” and can be purchased on http://www.handsonmobileapptesting.com/. In the beginning of 2016, Daniel released a new eBook called “Smartwatch App Testing” and is published at https://leanpub.com/smartwatchapptesting.
Testing for Purpose
Nothing will help a team deliver better outcomes than making sure they’re building something the user values.
This helps to improve the team’s focus by testing ideas more definitively before we invest in developing software.
In this talk, I'll talk about how to make concept testing an integral part of your culture of experimentation. We’ll apply the Lean Startup methods to answer following questions for our new ideas.
- Should we build it?
- Does it matter?
- Is it usable?
- Does it break?
We’ll look at how high-functioning teams design and run situation-appropriate experiments to test ideas, and how that works before the fact (when you’re testing an idea) and after the fact (when you’re testing the value of software you’ve released).
More specifically, we will explore how to:
- Identify where and how to invest the team’s scarce time and energy into better testing for maximum impact on outcomes
- Coach the team on the relationship between idea, usability, and software testing to get the buy-in you need for strong interdisciplinary collaboration
- Test ideas before you build them to avoid waste and help your team focus on what will really drive outcomes
- Test alternative interface patterns before you build them to maximize both product usability and purposeful implementation
- Understand your delivery pipeline and how to prioritize process and infrastructure improvements so you can deliver faster and more often.
Takeaways: To deliver agile outcomes, you have to do more than implement an agile process; you have to create a culture of experimentation. It's this commitment to experimenting that's at the heart of a high-functioning practice of agile.
After the talk you will be able to integrate the practice of experimentation across concept/feature testing, usability testing, and testing the software itself.
Dynamic and Innovative Thought Leader with expertise in managing Programs in Product Development, Strategic Planning, Infrastructure Transformation & Team Management. Led multi-functional, multi-cultural, multi-geographic teams towards execution of top-level objectives & maximize bottom-line results. A proven self-starter with the ability to thrive in fast paced, priority driven situations. Adept at driving the adoption and enforcement of Agile Project Management, removing impediments and fostering self-management.
A passionate digital disrupter who designs strategic plans, leveraging new technology and processes.
I have developed methodologies to help organizations and teams transition into Agile with relative ease. I also develop hybrid methodologies that are specifically aligned to organizations operating model and strategic needs.
An engaging trainer favoring hands-on and experiential learning approaches and workshops. I’ve groomed new Agile Coaches and Portfolio, Program and Team levels in the organization.
Testing in Production: Antipattern or Future?
Is testing in production always a bad practice? Although we work hard to deliver the best quality products to end users, we tend to avoid quality verification in production phase and limit our testing efforts to test/dev environments. During this talk we’ll explore various techniques of safe and efficient production testing with involvement of end users. We we’ll walk through real-live examples of solutions and test architecture used by industry leaders. We’ll learn how to take advantage of distributed architecture, provide test isolation, gather end-users feedback and assure high-availability of the software.
- Why is testing in production an essential part of testing in distributed system architecture
- How and why industry leaders test in production
- Real-live examples of assuring safe isolation while testing in production environments
- What is continuous testing in the context of testing in production
- How to gather valuable feedback from production users with minimum risk
- How to measure conversion and test usability in production
- Why top-tech companies intentionally inject failures to production systems
- How to assure high-availability when system failure’s already happened
Łukasz is a dedicated Test Engineer who advices teams in implementing continuous delivery practices with use of test automation and TestOps toolset. He specializes in connecting agile mindset with top notch technology. Big enthusiast of open-source software and continuous testing approach. Author of the testdetective.com blog and frequent speaker at various IT events. After hours, a guitar nerd and a books fan.
Delivering Good Quality with Trainees in Your Team
Working with trainees with no prior testing experience is always an exciting up and down rollercoaster of high expectations, set goals, hard work, emotional reviews and retrospectives and floating quality results. But is it possible to achieve everlasting and good quality of your software products while onboarding new trainees in only few weeks and enabling them to be productive, successful and happy?
Told from the experiences of a test manager and QA lead, working for a company who supports vocational training of the future IT professionals, here comes the story of delivering good quality while coaching new trainees in testing every 6 months. It is namely a must that the trainees change their project every 6 months to gain different needed IT skills during their 4 years' training (programming and application development, networking, databases, system engineering, testing, technical support, etc.).
Maja will present techniques and checks she introduced to solve the problem of doing good testing work while training people on the job. What kind of activities are going on at the same time, what activities she was using to teach people, what risks are there with the approach, what kind of results and problems she had.
You will leave the session knowing how to build trust, do proper time management and accept different personalities and work attitudes. Applying different techniques presented in this session, you will be able to significantly improve your leadership skills, inspire and inject your young team members with a passion for testing and create the base for future QA leads.
- How to implement test strategy with trainees and juniors:
- Balance between operational and strategic tasks
- Time management
- What problems, hurdles and risks you might encounter with this approach
- How to build a sustainable and successful team
- How much self-confidence and responsibility is needed
- Develop an effective feedback process
Maja was a speaker at several international conferences:
- Romanian Testing Days 2015
- Online test conference (Spring edition) 2017
- DevOps Days London 2017
- Quest for Quality Dublin 2017
- Lean Agile Scrum Conference Zurich 2017
- Swiss Testing Day Zurich 2018
Maja’s interests also include empowering and connecting women who work in technical and lead roles and for that reason in 2016 she founded the internal Swisscom women community. Being a good role model for her 2 daughters fills her heart with tremendous pride and joy.
You can contact her on Twitter (@majaschreiner) or via her blog (testmotion.wordpress.com).
Doubt Builds Trust
In an uncertain world, your team wants answers. Project managers want to know when you can ship. Project owners want testing to be done. Developers want to know that you’ve caught all the bugs. Testers can find jobs getting paid to assure people of a product’s quality. But I don’t trust testers who always say yes, because eventually a bug gets through, a deadline is missed, or a commitment is broken. Testing is not quality assurance. I trust the tester who expresses doubt. Doubt builds trust.
In my talk, I’ll explore how safety language, specificity, and nuance should color everything about the way we work. Testing software means engaging with uncertainty, and our communication should reflect that. Saying “I don’t know” can spark the beginning of a dialogue. Being able to admit the possibility of an unexplored path, a unknown interaction, or a fallible memory makes the difference between a team that moves forward and a team that stagnates by digging up evidence of mistaken certainty. We’ll get thinking about why it’s most important to say “I don’t know” in an interview and how admitting doubt can help a tester find an environment where they can thrive.
Takeaways: I want to give testers the power to be vulnerable at work. Rather than staying silent, testers can start admitting what they don’t know to get better explanations for themselves. If they’re already a pro at this themselves, they can encourage their teammates to voice their questions and foster an environment where this is encouraged. Testers will be able to:
- Approach situations with humility and a desire to learn.
- Refrain from mocking or judging those who know less than you.
- Consider the privileges that allow you to gain knowledge others haven’t.
Elizabeth tests software at Mendix in Rotterdam. In the course of her career, she’s tested web apps, mobile apps, APIs, and content management systems. Her article about mind maps became one of the most viewed on the Ministry of Testing Dojo in 2017. She spoke about moonwalking at TestBash New York in 2015, succeeding as an introvert at TestBash Philadelphia in 2016, and how less can be more with Diana Wendruff at TestBash Brighton earlier this year.
Immanuel Kant and the Hallucinating Tester
Immanuel Kant, the great German philosopher has a reputation for being pedantic and difficult. But most of us intuitively get the transcendental: That interacting with things always involves the complexity of experiencing and learning. Kants philosophy supports me, the thinking, imagining, sometimes hallucinating tester collaboratively engaging my team to learn things that matter to people who matter. It is testing for collaborative experiencing, learning, and knowledge. After the talk, we'll be able to say "transcendental" and understand what it means; we'll understand the basics of Kant's philosophy; and we'll know why intuitions sometimes matter more than facts when people collaborate about experiencing and learning.
- Be able to say "transcendental" and understand what it means.
- Get on terms with testing experiences.
- Understand the basics of Kant's philosophy.
- Avoid the trap of being skeptical about everything and anything.
- Avoid the trap of thinking everything we believe is real and true.
- Collaborate about learning.
- Reframe testing in your context.
Anders Dinsen is a free lance professional software test manager, coach, and test specialist in Copenhagen, Denmark. He is passionate about testing and leading testing of complex systems where values are at stake. He is seeking values in philosophy and old wisdom, and thinks that it's only through philosophy that we can truly embrace a complex and unpredictable reality.
Storytelling in Software Testing
Human beings are natural storytellers. As a survival strategy, evolution enabled us to learn and grow from stories (Don’t hunt in the swamp, Niknak never came back from there!). The world is full of stories and they affect our behaviour significantly all day – for good or bad.
As in all areas of life, also in software development decisions are often made based on intuition rather than careful evaluation, even though this evaluation is done beforehand. In addition, wrong interpretation of statements due to missing communication is usual. Storytelling can be used as a tool to communicate findings in software testing and improve decision making.
In this talk, I present how stories affect the human brain, what Campbell’s hero’s journey means for the day-to-day job of a software tester, and how storytelling can improve testing, reporting, application- and user-understanding.
- An understanding of the fundamental concept of storytelling (hook, hold and reward) and how he or she can use it as a software tester.
- How to build empathy for the user?
- How good is the software and how good can I test it?
After my PhD in Physics and a brief Post-Doc period, I started with the company Schlumberger as a software tester four years ago. My focus was (and still is) automated testing using Ranorex.
Together with my wife, I write novels, playbooks and short stories since 2012. Genres are fantasy, historical, steampunk, and science fiction. In the years 2013 and 2014, we achieved the Deutscher Phantastik Preis (German Fantasy Award) for Die zerbrochene Puppe (the broken doll) and Eis und Dampf (ice and steam), respectively. Actual projects involve rebellious craftsman and swordfighters, Romans in space, as well as mysteries beneath ice sheets.
Testing in tabletop Roleplaying Games
Roleplaying games have always been an rather obscure hobby activity, but were and have been popular by hundreds, if not thousands of creative people in the media and IT industries. But how are those highly creative, cooperative games created by publishers and if they are being tested, how do they do it? As a RPG publisher for nearly six years at Ulisses Spiele, Germany's biggest tabletop RPG publisher, I want to present the process, of how those games are written, developed and tested, before published to the audience.
- What will players take away from a game session;
- How should you interact with a passionate fanbase;
- Why aiming for a good game can be different from creating a successful game.
I have a master degree in political science, but work since 2012 for a pen and paper rpg publisher and can live from it. I have developed, tested, translated and played a wide variety of games and my love to do so kept me in the publishing business besides hellish working hours and shitshorts from the public.