Home

Анастасия Коцевич, ЗАО «Технологии качества», бренд A1QA

Не секрет, что взаимоотношения между программистами и тестировщиками нельзя назвать идеальными. Сама структура подхода, когда «одни программируют – другие тестируют» порождает конфликт между этими категориями специалистов. Естественно, в понимании девелопера тестировщик вставляет палки ему в колеса, находя изъяны в идеальном, с его точки зрения, коде. Тестировщик, в свою очередь, как правило недоволен неравномерностью нагрузки, задержками с поставками «билдов» и жесткими дедлайнами.

Благодаря этому (и иным соображениям целесообразности) «кодеры» и «тестеры» обычно работают отдельно друг от друга. Но иногда бывают исключения. Опытом участия в таком «совместном» проекте и извлеченными уроками мне хотелось бы поделиться в этой статье.

Как тестировщику, мне ранее не приходилось работать бок о бок с командой разработки того проекта, на котором я работала. Признаюсь честно, мне не очень хотелось начинать. Более того, я этого боялась. Нет, переезжать в другую страну или город не было нужды. Нужно было всего лишь переместиться на этаж выше, но от этого страх не уменьшался.

Причин для опасений было несколько: во-первых, я была уверена, что все они (программисты) меня ненавидят. И это логично. В размеренную жизнь разработки сейчас ворвется «чужая» и будет бесконечно указывать на ошибки и критиковать их работу. Кому это может понравиться?!

Во-вторых, было сложно представить, чего ожидает от меня команда, к которой я собираюсь присоединиться. С одной стороны, программисты частенько думают, что тестировщики глупее них, но с другой, они же могут переоценивать умения и навыки тестировщика. И не вполне ясно, что хуже.

Со своей стороны я ожидала увидеть «людей X», каждый из которых обладает суперспособностями. Скажем, управлять компьютером силой мысли и щелчком пальцев «фиксить» дефекты. К слову, через полгода я узнала, чего на самом деле ожидали ребята-программисты. Ждали они увидеть хрупкую блондинку и именно поэтому выделили ожидаемой «тестировщице» самый узенький стол. Наши ожидания взаимно не оправдались: я совсем не хрупкая и темноволосая, а ребята, с которыми мне предстояло работать, безусловно, очень талантливы, но все же не «люди Х».

Несмотря на то, что весь процесс «переезда» был очень волнительным, к этому моменту у меня «созрел» осознанный план: идеально разобраться в логике проекта. Было известно, что это проект со сложной бизнес-логикой, но в то же время я была отчего-то уверена, что у меня это легко получится! Как следствие, я не буду раздражать девелоперов расспросами и неактуальными дефектами и быстро вольюсь в команду.

Однако, плану сбыться было не суждено Проект, а вернее, группа проектов, оказалась из крайне сложной и совсем незнакомой сферы финансового анализа. Экономика и финансы… я же гораздо лучше разбираюсь в механике и сопротивлении материалов J Даже с учетом неимоверных усилий ознакомится с этими проектами за денек–другой не удалось. План откровенно рушился…

Но сдаваться – совсем не в моих правилах. «Нужно прогнуть ситуацию под себя!» - решаю я и собираюсь попросить помощи у разработчиков – так проще стать командой и найти с ними общий язык.

К своему ужасу помощи я так и не получила: на тот момент программисты разбирались в бизнес-лигике проекта лишь чуть лучше меня. Спустя месяцы становится понятно, что в тот момент открылось первое правило совместной работы: разбирайтесь вместе! Тем качественнее будет код, тем эффективнее потом будут тесты.

Второй частью моего плана было идеальное, безупречное описание дефектов. Была уверенность, что хорошо описанные дефекты не так раздражают программистов своим существованием. Первый найденный на этом проекте дефект не стыдно показать на курсах начинающим тестировщикам: идеально описанные поля, подробный алгоритм, приложения…

Каково же было мое удивление, когда именно по этому дефекту возникли первые вопросы у моих новых коллег. В тот момент было сделано одно из важных открытий: программисты совсем по-иному воспринимают дефекты, чем мы, тестировщики. Каждый программист читает разные части дефекта, частенько не догадываясь о наличии того или иного поля в описании. Как вы полагаете, на какое поле в первую очередь смотрят программисты? Правда в том, что у каждого оно свое.

Впервые оказавшись в «эпицентре» митинга разработчиков, я почувствовала, что все-таки пребываю в другой стране. Но, так же, как и в жизни, спустя некоторое время я стала понимать их язык. Хоть и оказывалась я на таких встречах случайно (все митинги проходили рядом с моим рабочим местом), но вскоре стало понятно, что мое присутствие на общих митингах весьма полезно для проекта.

Это вводило меня в курс всех деталей и частенько помогало построить стратегию, а ребятам я рассказывала, как та или иная часть кода будет тестироваться (что помогало им предотвратить многие дефекты). Сложно перечислить сколько «чудесных» открытий, общих полезных решений было сделано благодаря такому общению.

Перечисленные правила коммуникации понятны и просты, а многие вещи - просто очевидны. И как же редко они выполняются, когда команда распределена по разным этажам, городам и странам.

Как часто участники одного IT проекта забывают о том, что у разработчиков и тестировщиков одна и та же цель. Как часто аналитики, программисты и QA-специалисты «тянут воз» в разные стороны. В таком случае, каким бы звездным не был состав, и сколь талантливыми не были бы участники проекта – вряд ли сотрудничество станет успешным.

Всегда необходимо помнить, что цель общая. Уважайте и цените труд друг друга!

Несправедливо было бы не упомянуть о рисках, которые могут подстерегать при работе тестировщиков бок о бок с разработчиками.

Для меня самым серьезным риском стало описание дефектов. Так хотелось на нем сэкономить! Все равно ведь дефекты постоянно обсуждаются, зачем описывать их подробно?! Важно помнить, что в команду приходят новички, как девелоперы, так и тестировщики – для них подробное и понятное описание дефектов принципиально! Не экономьте на нем.

Нельзя забывать о принципе «Доверяй – но проверяй!». Изначально, я даже пробовала подстроить стратегию тестирования в зависимости от конкретной функции разработчика , что в корне не верно, так как рано или поздно приведет к упущенным дефектам. При построении стратегии важно учитывать, кто работает над той или другой частью проекта, но не в коем случае не стоит ставить это во главу угла. Хоть иногда и очень хочется.

В заключение хочется отметить, что у типичного конфликта между программистами и тестировщиками есть истинная причина – это разные цели. Стоит поставить перед ними единую, общую цель, наладить коммуникации – и все сразу изменится! Программисты и тестировщики станут лучшими друзьями, всегда будут помогать друг другу, а от этого выиграют все – и программисты, и тестировщики, и менеджеры, и программные продукты и компания в целом!