TestBash Germany 2017

Testbash germany adverts   oktobertest 06
Friday, 6th October 2017

We're bringing TestBash to Germany, and specifically Munich for 2017!

It's going to be a one day single track conference with 9 fantastic talks, followed by an Open Space on the Saturday.

On both days you can expect a wonderful community to come together in a friendly, professional and safe environment.

We think you will feel at home when you arrive!

All the talks will be in English.

The conference venue is located right in the heart of the city of Munich: Münchner Künstlerhaus am Lenbachplatz.
The Open Space will be taking place at the MaibornWolff GmbH Office.

And, of course the meetups!

Pre-TestBash Meetup - Thursday 5th of October.

Post-TestBash Meetup - Friday 6th of October.

Event Sponsors:
Conference
Friday, 6th October 2017

#NoEstimates, An Unconventional Approach to Managing Software Deliveries
Vasco Duarte

#NoEstimates, an unconventional approach to managing Software deliveries by Vasco Duarte, author of the #NoEstimates book.

Do you have problems hitting your deadlines in the projects you work with?
Are you constantly surprised by late changes that mess with the schedule and delay the project?
Does your company care about hitting deadlines, and reaching the market on time?

This presentation is a story, that starts with the most common of all situations: our project was doomed to failure. We had no clue what we were doing (try testing that!), we had a very tight deadline and no one to work on the project. Can this even succeed?

Well, we did. And we did it all without using any estimates whatsoever. How did we do it? Come and hear about it!

In the presentation we talk about:

  • How to get rid of Backlogs, but still deliver what matters
  • How to get rid of estimates, but still deliver on time
  • More than 20 years worth of tips and tricks
  • How to change your planning process to hit deadlines reliably
  • Agile as God meant it to be!
  • How a recovering Certified Project Manager successfully adopted Agile

Vasco Duarte
Vasco

I want to transform product development organizations into product business organizations. I do that by focusing the work of the product development teams on the end-to-end life-cycle of their products. From Concept to Cash and Back! Currently a Managing Partner at Oikosofy. Product Manager, Scrum Master, Project Manager, Director, Agile Coach are only some of the roles that I've taken in software development organizations.

Having worked in the software industry since 1997, and Agile practitioner since 2004. I've worked in small, medium and large software organizations as an Agile Coach or leader in agile adoption at those organizations. I was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia and F-Secure. Lean Startup, Agile, Scrum, Business, Management. Speaker and author at NoEstimatesBook.com.


Tentacular Continuity: The Game of Software Agriculture
Noah Sussman

Software systems are holobionts (colonies of interdependent entities) in which we as humans play a collaborative role. Humans and computers are mutually interdependent symbionts in the Web of epistemology described by Actor-Network Theory.

“Tentacular” means entwined or as we said in the Web 2.0 days, "deeply intertwingled". Re-appropriated by the anthropologist Donna Haraway, "tentacularity" suggests connections that are tight and complex and perhaps self-healing in the way that an individual “sucker” on an octopus’ arm might reflexively re-attach if momentarily disengaged. Tentacular metaphors speak to the goal of resilience, which is central to how at-scale distributed software systems are built today.

For nearly 2 decades I have been part of a small but influential set of Web developers who are pushing the software industry to move beyond the 20th Century's mechanistic allegories of architecture and manufacturing. The software philosophy of the 21st Century is poststructural.

Abandoning the structural metaphors of Agile and Lean manufacturing allows for the embracing of a new, constantly-in-flux nature of software reliability and quality. Stress, attrition and the cost of doing business all become manageable when risk is handled in the flow of normal work rather than with context switches and distracting blame-assignment sessions.

Aware of my holobiont status, I have forged a reputation as a software architect capable of turning legacy systems into working systems. For the first time, I can reveal that this success is due to addressing such systems as fellow collaborators in a vast and complex ontology of digital and social systems. Now you too can learn to apply these utterly novel strategies to your own work.

Takeaways

All of the material I will be presenting is new. This is the first chance ever to

  1. Hear about the philosophy of rapid, iterative Web development has guided successful test architecture projects for prominent software organizations like Barnes & Noble and Etsy.
  2. Explore a view of testing that is based on a synthesis of primary experiences from the global community of Web ops, dev and design.
  3. View software delivery through an entirely new lens, leaving behind the 20th C. metaphors of "Agile principles" and Lean manufacturing.
  4. Get an inside look at how I blend "soft skills" from the social sciences with "hard" development of at-scale Continuous Deployment tooling.
  5. See what it's like to work as a senior software engineer who is a tester — a firsthand peek into what the future of testing looks like!
Noah Sussman
2qbljp n

Noah Sussman is an industrial scientist who studies how people and computers relate to each other. After a decade of developing eCommerce interactive experiences, Noah grew increasingly interested in approaches to scaling Web applications. In particular his approach to scaling CI systems has a history of repeated success.

He is also noted for designing innovative test architectures for The SAT Test, Etsy and Barnes & Noble. He works at Teachers Pay Teachers: the world's largest educational marketplace, where he continues to push the envelope on continuous deployment praxis and tools.


Next Stop: FlixBus! A Tester Exploring Developer Land
Lisi Hocke

Welcome to our journey with FlixBus!

My name is Lisi and I’m your guide today. Our tour will start way back in history where we will discover dusty testing monuments of ancient times. From this starting point we will move on, and observe how testing at FlixBus evolved over time to a whole-team approach of building quality in. Let’s have a rest at the behavior-driven park of exploration, and finish our tour at the fair of alternative futures. Snackable pieces of knowledge are included throughout our trip and you're welcome to take notes and photos to keep your memories fresh! Looking forward to some fun time together!

Takeaways

  • From a zero-quality to a zero-defect policy
  • How testing throughout the workflow by the whole team helps to build quality in
  • Tips to shorten feedback cycles: learn and adapt fast!
  • How to release increments frequently within sprints
  • How to foster cross-team collaboration and grow a company-wide testing community

Lisi Hocke
Lisihocke

Having graduated in sinology, I fell into agile and testing in 2009 and have been infected with the agile bug ever since. I'm especially passionate about the whole-team approach to testing and quality as well as the agile culture mindset behind it. Building great products which deliver value together with great people is what motivates me and keeps me going.

I received a lot from the agile testing community; now I’m sharing my stories to give something of my experience back to the community. I tweet as @lisihocke and blog at www.lisihocke.com. In my free time you can either find me in the gym running after a volleyball, having a good time with my friends or delving into games and stories of any kind.


How Industrial Anthropology Influenced My Testing
Christian Kram

In this session I will shortly introduce industrial anthropology with the main focus being on four things that help me as a software tester. Industrial anthropology deals with the question "how can things that are industrially manufactured be used by humans?"

While being an industrial anthropologist my job had two core areas: Testing tangible things and collecting biometric data. I learned a lot while on that job, but four aspects stand out:

  1. Testing is ultimately about the people using something, not the customer.
  2. Know your audience!
  3. Results are nothing without interpretation.
  4. Functionality is just one aspect that lets people enjoy things. Users will use a product as a whole, so it's okay to test isolated things, but only judge these parts as a whole.

These four aspects can easily be translated to software testing.
It's easy to get trapped in the "the requirement is tested"-trap, but it's us testers that need to bring the user's perspective to the table if no one else does.

Know your audience: I changed domains from automotive to bookkeeping recently, where users have a somewhat lower computer-literacy. My approach to testing has shifted accordingly.

Explain your results: As tester we often see ourselves as information brokers. So we need to convey these information to the people making the decisions, not just a green/red light in your reporting.

Look beyond functionality: Don't just look at functional requirements. Users don't care if there has been a requirement or not on performance.

These aspects get lost easily in a tester's daily grind, so they are worth looking at from time to time.

Christian Kram
Christian

I am Christian Kram and I am a tester manager at MACH AG.

After graduating in linguistics, I quickly got into testing as an industrial anthropologist. As part of a research group at Kiel University I tested things like mattresses, medical products or instruction manuals. After a few years I switched into software development as a tester and requirements guy. I started out as a tester in the automotive sector in an enterprise environment and am now a test manager/coach for ERP software, with my main interests being testing and communication as well as agile development.


Dear Future Me... a letter to myself about testing, the universe and everything
Alexandra Schladebeck

This talk is a letter to myself - and hopefully to other testers at various stages in their careers.

Our craft is exciting, changeable, important and often underestimated. We ourselves can be alight with passion sometimes and can so easily lose some of that passion when faced with the realities of cost/benefit questions, an acceptance or expectation of inferior work and sheer drudgery in seemingly never changing systems.

At the same time, the tester role is constantly changing. We have to change or be changed - what can that look like, and how can we choose to react to it?

I may not be able to answer all these questions but I want to share with you some experiences of my almost 10 years in IT and testing in the form of letter excerpts to myself I wish I could have read when I started.

Some of the topics:

  • you are not "not technical"
  • follow your instinct
  • keeping your passion
  • the power of biscuits
  • your community will save you
  • the future hasn't killed you yet

Participants will hear about ways of keeping their passion and motivation alive and I’ll share experiences that will hopefully help to plan your next steps in your career or on your testing path. I’ll talk about how I deal with being in a technical world when my background is in linguistics, and I’ll reinforce us all in believing that what we do is worthwhile and important.

Alexandra Schladebeck
Alex

Alex fell into IT and testing in 2005 and has never looked back. She is now Head of Software Quality and Test Consulting at BREDEX GmbH and spends her time working with test consultants, developers and customers to help them towards great quality.

You’ll usually find Alex talking about quality and how it affects the whole development process. She’s also a frequent speaker at conferences where she likes to share her project experiences and learn from other practitioners.


A Tester Guide To Win Developers Respect!
Carmen Sighiartau

I have a confession to make. I was one of the people who thought testing is a crappy job that anyone can do.

I realized the value of a good tester when I had the opportunity to work with one. My AHA moment was when I read a bug report posted by a tester in my team and the first reaction was "How the hack did you thought about that scenario?".

As a developer, I always consider the code that I write my baby. When I'm thinking about test scenarios the two sources of inspiration are the specifications and the technical implementation. Is this enough? I thought it was, until I've met testers that proved me wrong.

After having the opportunity to work with testers that gained my respect, I changed jobs and I realized what Dr. Seuss wanted to say with "Sometimes you will never know the value of something, until it becomes a memory”. I was missing passionate, thoughtful testers that understand software both technical and business aspects, who look at the software that we write from a different perspective.

I am not a tester, so I don't evaluate a tester by the criteria you can find in a job description. My criteria are empirical and come from 10 years of working in IT and participating in both development and testing conferences.

The most important criterion is the value that a tester brings to the software that I write.

Carmen Sighiartau
Carmen Carmen Sighiartau - Java Developer with over 10 years of experience in the industry she recently found out how awesome testing conferences can be. Besides her daily development and managerial activities, she's involved in helping both testers and developers to bring more value to their work by providing training and coaching sessions. Currently she is a software consultant constantly looking for new challenges.

Testing Accessibility - Automated, Continuously and Reported
Patrik Karisch

Accessibility (or on short a11y, read ally) and inclusive design is a tough job to design and develop for. So please, don't annoy your developers with accessibility testing by hand! Or worse, have a dedicated quality engineer doing so. Stop! Now!

It's time to automate the hell out of accessibility testing. Focus back on developing for accessibility and inclusive design. Tests can be automated, get a dashboard of the improvements, report regressions as deployment blocking bugs and fix even more accessibility problems with your saved time from testing. And at all, have your quality engineers back on focusing what they really should do: Creating test plans for your software and not do the tests!

In this talk you learn the basic guidelines of a11y, learn to know the tools with whom you can test against these a11y guidelines, how to use the tools and profit from them the results and reposts. In the second part you learn, how to build an automated a11y testing toolchain with those tools and you get an example a11y CI/CD pipeline which you can take home, work with it and introduce into your company/agency, which of course cares about accessibility and inclusive design!

Patrik Karisch
Patrik

Patrik is a PHP, Linux, and DevOps engineer specialized in ecommerce and CMS, APIs, and connecting all the different systems to work together.

Loving open source he is an enthusiast and an advocate of modern development principles & standards. He notoriously automates everything with Ansible, Terraform and many other tools fitting the job. With all his collected knowledge a deep dive to debug complex systems and architectures is no longer a challenge for him.


“Worst” Practices of Software Testing.
Viktor Slavchev

The testing troll is a mythical creature, you probably heard about it in the last years edition of QA challenge accepted, he’s like the unicorn of software testing, besides the fact he has nothing to do with a unicorn.

What is important about him is - he’s not really nice, he hates clichés and he doesn’t follow best practices in testing. He offers alternatives in these “best practices“ and because they are the totally opposite of what everyone is talking about, he calls them worst practices. In fact, he was so committed to his idea of worst practices in software testing that he wrote a book about them. Here how it looks like:

Worst Practices in Software Testing

My job will be to present to you the gathered knowledge of the testing troll in the following topics:
How not to:

  • Use requirements to direct testing
  • Do regression testing
  • Automate testing to reduce costs
  • Assure quality
  • Believe in best practices

Viktor Slavchev
Viktoslavchev photo

My profession is software testing and by that I don’t mean mindless clicking on UI elements, nor comparing result to predefined expected states. When I talk about testing or perform testing or teach testing I always think of it as a scientific activity, process of evaluation of quality, exploration, of questioning, modeling, experimentation, risk assessment and gathering of information in general. In other words, I take software testing very, very seriously!

I come from a non-technical background - linguistics and I am very happy about it, since it provides me with a unique perspective and a lot of diverse experience which is always something that is beneficial in software testing.

In my previous experience as a software tester I was involved in many different projects related to mobile testing, testing of software products in the telco area, integration testing, test automation (even though I prefer the term “tool assisted testing”). In general I am interested not only in the technical, but also in the scientific part of testing and its relation to other sciences like epistemology, system thinking, logic, problem solving, psychology and sociology. I am currently also a part-time lecturer in software testing academy called Pragmatic, on topics related to exploratory testing, mobile testing and non-functional testing.

In my free time I like reading books, playing MMORPG games and practicing Japanese martial arts.


Regression Mitigation Strategy Model
Pekka Marjamäki

We should approach regression testing as a problem that needs solving. The system might regress as part of a change or due to an action or operation. In software and hardware testing, all actions cause changes in some part of the product. In order to tackle regression, we need to understand the problem, study the problem and try to find solutions to it.

This model helps identify and communicate the problem, take various aspects into account, heuristics that help focus on things, and guidelines and hints how to solve regression problems.

The model has six rough areas: Goal of regression testing, Identification techniques and focus heuristics, Dependency heuristics, Unpredictable elements, building Confidence in our testing, and Communication tips and techniques. These elements help build a strategy with which one can tackle regression problems and to mitigate the risks of regression.

Pekka Marjamäki
Pekka

The guy who does a lightning talk and uses 20% time to make people shout "TESTING" as loud as possible. The guy who does extempore workshops on test strategy in the hallway. That guy is Pekka Marjamäki. When cut, he bleeds f***ing software testing!

Context-driven software tester who has a knack for coaching, problem-solving, out-of-the-box thinking. Currently a software testing specialist at Solita Oy, Finland. Years of experience from different projects ranging from virus protection to logistics acting as a test manager, devops-dude, coach and code-breaker. “Always be braver than the next guy!"


Micro Sponsors: