Targeting Quality 2018

Our human brains impact the way we perceive, develop, test and use software - knowing our cognitive limitations we can test more consciously and deliver more suitable software.

Some kind of obvious thing is that both software makers and users are human beings. But working with edge-cutting tech we tend to forget about our cognitive limitations. In each software development project there is the crucial question - how to make the people using that stuff? I would add the one more question: how to make the humans using that correctly, intentionally?

In my talk I want to introduce the cognitive approach which uncovers human perception limitations. By listing the issues like perception gap, schemas reasoning and cultural heuristics, I want to show the delegates what is realising-worthy. Also I want to present in easy-going way the few cognitive science theories (like Marr's vision, Gestalt rules, Gibson’s affordances) to make the delegates aware, how the brain is influencing the testing.

Being a tester it is important to review and test the product against both correctness (validation, verification) and usability. The things I cover are helpful both in analysis and test execution phases.
The delegates will be given the set of questions that help to check if they test considering the cognitive limitations. There will be the checklist for mobile testing and for web testing. The checklists will help them to assure the human-friendly software.

Your worst fears have been realized. An awful bug has reached production, and customers are calling non-stop to complain. Panic ensues. A couple hours later, you get some good news, it's been fixed! Crisis averted! But how do you keep it from happening again? And more, how do you keep from pointing fingers?

Software quality can so easily fall down into the depths of the blame game. Why didn't you catch that bug in testing? Why didn't you see that bug when you wrote the code? Why did you push so hard for that deadline, and make us sacrifice quality for speed?

In almost all cases, these types of questions aren't helpful, and might not even get you the answers you're looking for. How can we get better at navigating the fallout from issues, without playing that problematic blame game? We'd like to share our experiences in dealing with such situations, and the lessons we've learned from them. What language can you avoid, what phrases can you mentally prepare for, in order to avoid anyone going on the defensive? What mindsets can you put yourself in to avoid blaming others, or yourself?

This room is available to continue conversations, start new ones or meet someone new.

A tester is not a machine and Human Beings by preference are lazy. We want an easy way to do things. We need an easy way to understand complex concepts. So we model the real world and in doing so, provide ourselves with simplified comfortable ways of describing things. But this can cause all sorts of trouble. Particularly if we start to think in black and white like the computers we're testing. This presentation will point out to you some of the ways in which you might not be aware that you limit your own thinking.

FYI for those without a television set, the title is a reference to an old television show called "Lost In Space", that's recently been rebooted on Netflix (we're ignoring the cinematic attempt a couple of years ago).

Money is tight all over, it always has been more famine than feast and it always will be. The hunger for quality is constant and insatiable but in software development "quality" is an intangible concept that is not always easy to measure or define. Testers find themselves constantly needing to find ways to justify an investment in testing to drive up quality. Unfortunately, while testers are very good at asking questions and seeing problems, they aren't always good at converting this information into a conversation with a concrete justifiable outcome. Far too often, the conversations will leave people a little raw, or schemes to increase quality come off a little half-baked. This is where the Quality Conversations Recipe or QCR (pronounced Quasar) Model comes into play. In this talk, the conversations that help convert stakeholders into engaged supporters for testing and quality will be reduced to enticing conversational recipes. These recipes will highlight the ingredients (data) that have to be gathered to build your conversation, the setup (environment and tools) that you have to have prepped in order to start, the preparation instructions (building your conversation) and of course the cooking instructions (presentation hints, wait time, follow-up, etc) in order to have a full-baked conversation. Recipes include, Mike's Metrics Marinara - choosing the right metrics, presented properly, to demonstrate real value, Technology and Tools Torte - how to talk about using tools such as automation and CI to up your game, and a Time Saving Tzatsiki Sauce - a real conversation piece about how improved quality saves time across the entire team.

In the past decade the software development paradigm has shifted to "deliver fast" - with concomitant frameworks and methodologies to support that emphasis - but without proper consideration of quality. So most teams end up failing fast and hard when development continues beyond a shaky foundation. To bring about positive change, we must improve both our knowledge base and our processes to achieve quality delivery without disturbing the bookkeeper's project delivery timelines. Lessons learned from a career in research science can be applied to QA, with parallels to industry product quality models. Testing techniques and product delivery processes from research science will aid not just testers but the entire team in delivering quality software. More than just day-to-day team activities and testing tools, the science of testing is about the pursuit of knowledge and understanding for its own sake. Testers should foster their skills in the community with professional development activities. Those in attendance will learn about the successes and failures of applying a scientist's approach to testing software, from the "publish-or-perish" mindset of science to "deliver fast" in IT.