Targeting Quality 2018

Legacy Code often elicits an intense hatred from programmers. But it doesn't need to be this way! The issue with Legacy Code is not the age of the code base, but the actions that we take. I will discuss three things that our team excels in and go into detail on how they directly benefited our team in a recent refactoring effort.

"I tested it how you told me to", "Acceptance Criteria said this is expected", "I assumed it is fine" - these are frequent thoughts of teams which more likely to end up with customer cases in Production. Having an opinion about the product and ability to put themselves in its customers' shoes is what makes a good tester, great. These great testers become the last line of defense before releasing functional but unusable product.
It is easy to tell what kind of company you are working for if when you started there, you were sat in front a laptop and were given some code to study. Teams like that simply want another coder.
If your team got you to explore the product first, then it is a team that wants you to know exactly what you are working on; they want you to know your domain.
In this talk, we will discuss on how to apply Domain Driven Development practices and principles in a testing field, creating Domain Driven Testing. We will learn why it is important to understand exactly what you are working on, and why "Programming by Coincidence" is the main danger to User Experience.
The speaker will share his experience in starting in a new domain of Website Building Software, and how learning about other products in the industry allowed him and his team to avoid reinventing the wheel, and as a result to prevent problems which were previously solved by other organizations.
At the end of talk, the audience should be empowered to make product decisions and direct all its efforts towards satisfying the most important stakeholder, Customer.

IoT world grows by 30% every year (up to 25 billion(!) devices till 2025) and that's just a matter of time when some of us will have to...get back to the past. Many of current testers very soon will start their adventure with real hardware devices. It also means more and more complicated integration with modern services and technologies (Amazon DRS, Alexa, Behavioral Recognition, vision processing, AI, ML and many more).

What are the limitations encountered in such conditions? What are the main challenges and what a modern tester should know before she or he starts their testing game? And finally, how to find yourself in a testing environment when Time to Market statement has paramount importance in terms of building business models?

During my presentation, I'll show how current challenges and risks will change in the near future and how to deal with them. I'll also present the way to easier identify and mitigate them. All of that in the context of pet cameras, snack launchers* and lasers...in other words - IoP (Internet of Pets) world. All dogs and cats are warmly welcomed!

*Presentation consists of a live demo with flying sweets

The release decision is often made somewhere between "Flawless" and "Good Enough", leaving behind a rotting pile of bugs in the "To Do" state as a result. Can we really speed up development by eliminating bugs from the development process? How can we as Testers help slow or stop the new bug count and clean up the 'Bug Dump'? Jerry Penner will discuss his experiences in speeding development by eliminating the waste of logging, counting and graphing bugs and send you back to your team with 3 solid tactics you can use right away.

You can’t teach an old dog new tricks. Or can you? With the rise of techniques like Continuous Integration, Continuous Delivery, Testing in Production and the like, the demand for traditional blackbox testers is going the way of Old Yeller. More and more employers want testers who are able to work in and with code - and this can be uncomfortable for testers whose backgrounds don’t stem from CS or programming of any sorts. I’m here to tell you that you don’t need to be afraid.

You won't be expected to contribute to production code, suggest an O(1) solution on a code review or pair with developers during implementation. But it’s time you start peeking into that black box and being able to talk about what you see. This talk will cover various techniques proven to help you embrace code, expand your comfort zone and get you speaking a common language with developers.