The nature of communication between quality assurance engineers and software programmers is known to be a source of regular conflicts.

 - “It works on my machine!”

 - “This is not a bug. This is a feature.”

For sure, you can remember your own stories about conflicts in your work. From one side, such conflicts seem unavoidable, but on the other side,  permanent conflicts require a lot of emotions, and long-term conflicting communications lead to burnout and team disruption.

So, what can you do with conflicts?

As a certified conflictologist/mediator, I will share with you basic ideas about conflicts. These ideas could help you to be more effective in conflicting communications.

“The culture eats strategy for breakfast”, as Peter Druсker said once. How to make quality to be a part of corporate culture? Why legal papers, instructions, motivational statements filling office walls mostly not works? 

As a corporate culture coach with more than 15 years experience in development and as a psychologist, I will share with you some principles and practices which can help you to improve better understating of culture growing process. This knowledge allows you at least to improve your conscious work with culture. 

This talk will be useful for test leads, managers and all of you who want to build own empire. 

Have you ever had moments in your work when you thought "who is he to tell me what to do? I'll do it my way!"? Have you ever noticed a "war" between colleagues for someone's attention in your team? Or maybe you have been a witness to a personal conflict between two people escalating into a conflict at the team level? Or perhaps you don't really like to stay late at work unless you need to help your colleague. Well, not to anyone, of course, but to the very colleague. Late-evening deployments or pair-testing sessions - isn’t this romantic? 

As quality assurance engineers, we know how much the interaction of the people who create a product affects its quality. And people's behaviour is determined by a set of social needs.

And I want to talk about some of them, which usually don’t get much attention, becoming “elephants in the room”. Let’s try to see these elephants a little closer?

Non-obvius behavior seems to be an hardest thing in testing. Applied to human beings behavior especially. To developers particularly. Effective working with developers seems to be a too big topic, so my talk should be considered as a very brief quickstart guide. You will learn some "selected by hand" antipatterns in work processes, e.g. why being a "good tester" can lead to "bad" consequences.

Every automated testing system is a solid software project that needs to be deployed and supported. Not every QA engineer has enough skills for that. As lead developer with background in software design, development and deployment, I want to share my practical experience that can help to avoid typical errors.