CopenhagenContext 2016

Navigating power relations and introducing change in organizations can be really difficult. It’s because power relations can be hard to detect, and because “people hate change”. But power and change are related to each other. So sometimes we say we feel “powerful” if we’ve managed to change something, and, occasionally, we say we are “powerless” when we’ve failed to achieve our goals. What do we really mean? Making an effort to understand what power is like and how it operates can be essential for someone interested in how systems work, and who wants to be great at driving change. Thinking deeply about power, looking at how it’s manifested and building on Foucault’s ideas about power has helped me build a toolbox. The ideas in the toolbox help me understand, ask questions about, analyze and address the complexity of power and make it tangible instead of abstract. It seems to me that having thought about the inner workings of power has made me more powerful and insightful. On top of that, I’ve learned lessons about trying to make changes in how testing is perceived or change how it’s done. I’ve learned about change patterns that help me develop tactics for implementing change. But after all, I’ve found that understanding power is a strong foundation to leading change in the organizations. In this talk I want to: • invite you to reflect on power and change: let’s make “power” tangible and personal, and analyze the context around change you want to drive • help you ask useful questions when analyzing power relations in your organization so they wouldn’t trip you up • share change patterns that have worked for me and explain why they have worked through concepts of power

It seems that when you present the seven principles of context-driven testing to anyone with some experience in IT, they agree with all seven of them. And yet not all of these people are context-driven. And even if you are context-driven, bridging the gap from principles to practice is hard. For instance, what are the practical implications of "Projects unfold over time in ways that are often not predictable."? After struggling with this myself, I managed to bridge this gap by creating my own model, my own way to express what context-driven testing is. This model consists of Tools, Process, Information, Value and People. While it does capture the philosophical underpinnings of context-driven testing, it connects these to what we see and do in our daily life as testers. A simple example is how the model distinguishes the tool 'document' from the information it may communicate during the process of reading. And while I wouldn't claim that my model magically solves the problem with the principles I described above, I do think it can be a valuable tool in moving from context-driven principle(s) to practice. Although the best way would probably be people creating their own models, like I have. Encouraging people to do so, is most definitely a secondary purpose of my talk.

In this talk I will introduce the basic human values and demonstrate how dialogue revolving around these can play a powerful role in context driven testing leadership. Context is not a static 'thing'. To be context driven therefore implies responding to change. To me, helping people dealing with change in fruitful ways is fundamental in leadership. Values shape our actions and thereby shape us, and through dialogue we can explore our own and company values. As a context driven testing leader it is my ambiton to help people not only cope with change, but also to explore contexts in ways so they carry out valuable and efficient testing, and have fun while learning. I will introduce and explain the concept of protreptic dialogue, a value centered form of dialogue developed in ancient Greece and recently revived and reinvented by professor dr. phil. Ole Fogh Kirkeby at Copenhagen Business School. Leaders who practice protreptic dialogue use it to assist people accepting and dealing with change. I will demonstrate how protreptic dialogue can take place, discuss the actual outcomes of it and will share my own experiences using it in the workplace. I expect participants to be inspired to talking about human values with colleagues, bosses, teams and team members while exploriong contexts. I also expect some to want to learn more about protreptic dialogue.

What do you think of when you hear the phrase “context-driven testing community”? Our perception of the community is shaped by our experiences - the people that we choose to interact with and the ways that we choose to engage with them. Perhaps we see a close-knit support network or a friendly debate team, but others might hold a different perspective. There are testers who are fearful of joining our community. There are others who think that context-driven testing is simply about being against ISTQB or ISO29119. Some testers were once part of the community but have withdrawn due to their own poor experiences, or their interpretation of the experiences of others. Is this okay? But what would we lose by presenting a friendlier face? The community has been shaped by the idea that “no one is entitled to an unchallenged opinion”. Perhaps a culture of challenge and exclusivity is essential for deep conversation that leads to the development of excellence. Let’s talk about our community, what we value and how we can improve. Let’s consider how we interact with one another and communicate our key messages. Let’s leave this session with practical ideas about how we can each contribute to improving, explaining and marketing the context-driven testing community.

We have all seen gamers who want to test games, and we have met testers that dream of working in a game project. So what to do if you're a professional tester, old-school gamer and doomed to work at “enterprise monsters” projects? My answer: Create your own game and test it however you want! Then questions came that I found myself wondering about. How to perform unit and integration testing in the context of a game project? How to use Test Driven Development? Could it become an efficient tool for your goals? Do you really need all of these "right things" in your project? In a small team with only 2 engineers, a 100 euros budget, and without professional graphic/sound artists? So how will this context affect trust in processes and test techniques that we are all happy to use when we work professionally and are being payed a good salary? That's only a brief list of questions that buzzed me each day and I'd like to tell the story of my struggle on the way to finding some answers for those questions. I will present answers for those questions through examples from my own project. This will be a personal experience report that I believe will be interesting for all testers that thought about working in a game project. My story also describes how I evaluated my tester's experience to use it in my own project. Lastly for me - this is a good motivation to structure the experience gained, get feedback, and to find new test challenges that I can tackle in my new project. And the final chord - we’ll have fun during a short bug hunt session of my game. Where everyone can evaluate the game we talked about so much. You shouldn’t miss that!

When I first heard of automation(in the context of continuous delivery) I though it is the holy grail of testing that will save me time and make testing better. Although the previous two statements are true, what I have learned over the last three and a half years is that it can be both good and bad, and sometimes ugly. I will show you what I have learned through doing it everyday(and sometimes in my sleep), what mistakes I’ve made and also what success looks like. Key points - automation will challenge you like no other but it will be fun and rewarding to overcome those challenges - automation done badly can do more harm then good - how to start automation on a project and where does that lead you

"Antifragile" is a philosophy developed by world-renowned risk analyst and scholar Nassim Nicholas Taleb. According to it antifragile systems not only withstand volatility, randomness, disorder and stressors, but rather improve from them. One example used is the ancient Greek monster Hydra, who after losing a head grew two back. Many think that modern equivalents can be found from Agile, DevOps and Lean Startup approaches. In this presentation we dig into how antifragile models have been deployed into one of Finland's biggest companies. Everything revolves around "tribes" who make progress in their respective fields of interest. Mechanical front embraces e.g. automation, cloud solutions and process development while organic front focuses on e.g. people, building competence, exploration, continual learning and tribe dynamics. Ultimately the tribes form a cell structure that improves from change and for its part realizes the antifragile ideal. Come to see what has been achieved after one year of work, and discuss about the results.

Testing like daredevil: compensating for a lack of visual feedback When it comes to consuming music, entire experience sums up to which emotions get triggered in hearts and souls of the listeners. When we speak about professional testing of electronic music systems, how important are emotions awaken inside tester in this process? Can human senses (ears, eyes and touch) trick us or should we fully trust them? How to justify heuristics of desired software behaviour when inputs do not necessarily come from sight sensors most of humans depend in daily work? In this talk, focus will be streamed in following directions: 1. What makes testing (of even basic) electronic music production software and it’s related hardware ecosystems challenging 2. How to explore and learn about the system when visual decision heuristics are not always the most important (audible and tactile experience do matter even more) 3. Very often one hears testers in music industry speaking about “it feels right” or “it feels wrong”. How can we quantize and qualify “feeling” of certain flows and document our observations? 4. Mimicking various genres personas flow (hip-hop, minimal techno, dubstep, IDM/studio producers ...) as way of implementing charter based sessions. Audience will have chance to see short live performance on the very beginning of a talk, in order to feel what the system, talk is based on, “is all about”. Glorious take-aways of this thought provoking talk will be: Context and content do matter, critical thinking is the king! (Statement will be supported with real life examples from testing electronic music production software). How to deal with making decisions based on/in the lack of various human sensors streams of inputs How testing and creativity are happily married in domain of music software. What makes sense to automate in ecosystem of music production software

Quite a lot of testers miss out on the required mindset for testing. Sometimes it seems that quality consciousness is missing. Little wonder why some testers only find obvious bugs and why quality is far-fetched from the device under test (DUT) despite the presence of testers on the project. In this presentation I hope to present to you a set of tools that has helped me during my personal journey as a tester. These tools have helped me grow in my reasoning about the challenges I’m faced with on my daily task. My way of reasoning evolved into a set of tools that I refer to as “Mindset Tools”. While I reflected on my daily task and how to keep growing, I discovered that different task, required different lenses viewed at different angles with different mindsets hence to effectively test I need to tweak my mindset for different task. To achieve this, I need to keep my mindset flexible when I test. To keep my mindset flexible and help me look at things from different angles, I try to put a label on the mindset approaches that I find useful and I call it ”Mindset Toolkit” I will talk about how my "Mindset Toolkit" has helped me grow from a tester that finds obvious bugs to a tester that finds important bugs. I will give examples of different mindset tools and how I have used them to become a better tester. A few of these Mindset Tools are: User Mindset Tool, “Already Tested” Mindset Tool, Confidence Mindset Tool, Trust Mindset Tool, Courage Mindset Tool, Communicator Mindset Tool, Lazy Tester's Mindset Tool, Analytical Mindset Tool, Bug Finder Mindset Tool, Curiosity Mindset Tool, “Bug Conviction “Mindset Tool, “Business” Mindset Tool, “Dog Style” Mindset Tool, “Cat Style Mindset Tool.

The last couple of years as a trainer I have been moving around in different contexts and what I have noticed is that test activities and testers are moving into two directions. This becomes especially visible between agile and non agile testers. The first are focussing a lot on automated testing, checks and tools. The second focuss more on validating requirements, content and manual testing. In this talk I want to address the abyss that apears to be forming between these two groups of testers, the differences, the commonalities and a way of bridging this abyss.

In this talk, I will tell the story of the red button. This is a humorous, emotional and investigative story detailing a true experience that I had of a red button that was next to a mains socket on the wall behind the TV in a flat in Shanghai. It tore me to pieces trying to figure out what the button was for. But yet, my fiancee was not curious in the slightest about it. How could we both have such different curiosity levels? Is it because I am a tester? Or is it in my genes? I plan to share the emotions that I experienced and the lessons I learned from this experience. I'll also discuss the traits of a tester and I'll raise the question on whether curiosity and inquisitiveness is actually a gene that we possess. And I'll bring some compelling evidence to suggest why I believe that this may be the case through the DRD4 gene - a gene which apparently dictates our curiosity levels...

“After, you could check, I don’t know, localization, performance and usability. You know, the stuff you testers do…” This is an actual statement that was delivered to me by my very experienced software developer colleague. And it is a developer who gets that testing is something that is necessary for a successful project and he is doing his best to learn more about it so he can be better at understanding it. But what actually is a problem here is that we, as testers, are too often buried in functional testing. And besides that, functionality is not and should not be the only quality attribute of the software we should pay our attention to. So, is there a way to know how we can contribute to a project in order to deliver it in time with required level of quality? Are we aware of things that we might ask or do in order to make our (and everyone else’s) lives easier? If these questions are laid before most of the software testers they will most probably reference to an ISO/IEC 25010:2011 or another methodology or a standard in order to look for the software quality attributes. Problem with those is that they are too elaborate, detailed to remember it easily and questionable in many ways. This presentation is the result of a search for a model that will enable a software tester to properly define context of the software under test and compose such questions, which will result in a list of tasks that should be performed in order to deliver a successful product.