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.