IT-ликбез

Тестировщик vs программист




КАК РАБОТАТЬ, ЕСЛИ ОТНОШЕНИЯ НАКАЛЕНЫ?
Фото: baranq / shutterstock
Если коротко, то ответ на вопрос «Как тестировщику и программисту работать вместе?» – «Понять работу и мотивы друг друга – и не накалять». Отношения QA-инженеров и программистов – сложная тема для представителей обеих специальностей. Часто они друг друга недолюбливают и становятся источниками обоюдного стресса. Посмотрим, что провоцирует трения между тестировщиком и разработчиком и как наладить коммуникацию.

Александр Хатилов: «Software Testing – это работа с качеством продукта. Снизить количество проблем до нуля нереально. Но первая задача тестировщика – сделать так, чтобы их оставалось как можно меньше»

ЗДЕСЬ И ДАЛЕЕ ПРИВЕДЕНЫ ЦИТАТЫ ИЗ СЕРИИ ИНТЕРВЬЮ ALMAMAT BLOG, ПОСВЯЩЕННЫХ QUALITY ASSURANCE. Александр хатилов: ИНЖЕНЕР ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ С 30-ЛЕТНИМ ОПЫТОМ РАЗРАБОТКИ ПО И ТЕСТИРОВАНИЯ; 12-ЛЕТНИм ОПЫТом РАБОТЫ В КАЧЕСТВЕ QA/QE-МЕНЕДЖЕРА В COMPAQ, IBM, GAP, EBAY, KOHLS, WILLIAMS SONOMA.
Почему тестировщику трудно с программистом?
Потому что тестировщик находит чужие ошибки. Вы когда-нибудь радовались человеку, который приходит к вам со списком ваших ошибок в работе, на которую потрачено много времени? Это довольно унизительно, даже если вы в целом понимаете, что это просто структура работы, и так заведено. Это само по себе такое негласное «ты некомпетентен». Психологически такой контакт уже располагает к пассивной агрессии и трениям.

Человеку со списком ваших ошибок можно радоваться только в одном случае, и о нем поговорим дальше.

Александр Хатилов: «Уже много лет считается, что программист может сделать ошибку – тестировщику или QA-инженеру запрещается ее не найти. За ошибку ругают не программиста, а тестировщика»

Тестировщику трудно еще и потому, что программист зачастую не признает баг или отказывается его править, считая несущественным. Почему разработчик сопротивляется? Иногда потому что ему нужно NN часов исправлять то, что он не считает существенным. А если ему передают длинный список обнаруженных дефектов, фрустрация естественна.

Это все бодрые разговоры для коуч-сессий, что адекватные люди используют ошибки для роста и развития. Разумеется, используют, но фрустрация и чувство напрасно потраченного времени идут в комплекте. Надо это осознавать, а также коллегиально готовиться к тестированию в начале новой итерации разработки.

Александр Хатилов: «Есть такой критерий оценки в программировании – Lines of Code: считают, сколько «живых» строчек кода человек написал в единицу времени. Второй коэффициент называется Defect Density, то есть плотность дефектов – количество багов на тысячу линий кода. Например, два на тысячу. Квалификация программиста измеряется временем, которое ему нужно на исправление бага. Его замеряют специальными программами. В среднем, программист тратит 6,8 часов на исправление одного бага»

Фото: Bogoljubb / shutterstock
Почему программисту трудно с тестировщиком?
Потому что форма контакта может быть еще неприятнее, чем его содержание. Тестировщик это в принципе архетип фиксера, такого спасителя общего дела, человека в супергеройском плаще. Это сказывается на атмосфере контакта. Для программиста это может выглядеть как несправедливое психологическое распределение значимости: это он создает этот продукт, пишет его код. Иногда речь о статусном шовинизме, неуважении к чужому труду и банальном нежелании просмотреть свой только что написанный код, но не всегда. Фрустрация от ошибок и необходимость переделывать много всего – сами по себе большие факторы негатива.

Есть такое понятие «игры власти». Вот плохо выстроенные процессы и инфантильный психологический подход одной/обеих сторон превращают контакт тестировщика и программиста в игры власти.

Ошибки в работе есть абсолютно у всех специалистов, но далеко не все имеют привилегию самостоятельно обнаруживать и исправлять свои ошибки. Это привилегия, потому что такое положение вещей позволяет «сохранять лицо». Большинству людей в той или иной мере унизительно, когда им показывают их ошибки. Тут есть психологический эффект: тот, кто сообщает о баге, как бы нависает в образе руководителя, более компетентного. А также выступает в роли свидетеля чужого провала, пусть и микропровала, дефекта разработки.
Фото: fizkes / shutterstock

Александр Хатилов: «Вторая задача – помочь программисту сделать продукт в срок. Очень часто программисты все делают медленно. По аналогии: никому не нужен вкусный суп после десерта»

Как выстроить конструктивную коммуникацию?
Первое: тональность контакта, сама форма рабочего общения. Некорректная тональность становится триггером субординационного конфликта.

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

Абсолютное no-no – злорадствовать в случае найденной ошибки, гордиться обилием обнаруженных дефектов разработки. Этикет программиста, в свою очередь, состоит в том, чтобы посмотреть написанный код, прежде чем отдавать его на тестирование. Если в команде есть токсичные люди, которые распространяют злорадную, издевательскую, высокомерную тональность и создают атмосферу конфронтации, то важно не поддерживать этот вайб, а свою коммуникацию строить конструктивно.

Второе: мыслить перспективами. Тестировщику карьерно выгодно быть в конструктивных отношениях с программистами, потому что он, вероятно, будет развиваться в направлении аналитики и автоматизации тестирования, начнет изучать языки программирования. Когда что-то непонятно или не получается, ему будет полезна подсказка коллег. Он также может захотеть стать программистом или QA-лидом. В обоих случаях важно быть в положительных рабочих отношениях или наладить их, если они натянуты.

Что-то вроде волшебного решения в этой теме есть. Но без фундаментальной коммуникации оно не сработает. Базово не нужно допускать в отношениях твиста в стиле «момент, когда Дэйнерис превращается в Безумную королеву». В точках выбора реакции и линии поведения не нужно take it too personal. Это не личное. Но может становиться личным очень быстро, а неприязнь порождает неприязнь.

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

Третье: самоуважение и уважение другого. Качество работы тестировщика прямо связано с воронкой продаж, с популярностью ПО, с его репутацией в соцсетях и комьюнити, с рекомендациями. Если тестировщик честно делает свою работу, то у него есть все основания для профессионального самоуважения. Не нужно подстраиваться из позиции нижестоящего и менее значимого сотрудника, это только повредит: тестировщику, программисту, менеджеру, продукту, рабочей культуре в компании и паттернам в отрасли. Достаточно уважения, доброжелательности, сотрудничающего настроя, разумной рабочей дистанции, соблюдения правил, согласованных в сотрудничестве с менеджером и программистом, а также понимания общей цели.

Парадокс разработки и тестирования состоит в том, что тестировщик со временем видит разрабатываемую систему гораздо более целостно, чем программисты, которые пишут отдельные модули. В какой-то момент, тестировщик, QA-инженер становится экспертом по конкретному программному обеспечению. Для Quality Assurance специалиста важно найти баланс между самоуважением и уважением к другой стороне.

Четвертое:
при тестировании подходить реалистично, ранжировать и документировать обнаружение дефектов разработки. В одном из первых интервью ALMAMAT Blog QA-инженер Setka Сабина Хасанова упомянула о тестировщиках-баголовах, которые рассматривают количество багов как ачивки, достижения, гордятся самим количеством. Надо понимать, что программист потратит много времени на исправление каждого бага. Одни действительно важно поправить ASAP, а другие несущественные.

Пятое:
приоритезировать цель, а не задачи. Тестировщик ищет баги. Программист пишет код. Это их задачи. Цель менеджера – своевременные релизы чистого продукта, которым потребителю удобно использовать. Задачи программиста и тестировщика часто путают с реальной общей целью – для чего это делается. Этих специалистов нанимают для того, чтобы качественный продукт работал на рынке и приносил прибыль. Это их повседневная цель в каждой итерации работы над продуктом. И каждую итерацию работы они достигают этой цели через решение своих задач: написание кода и тестирование кода на предмет дефектов разработки. С точки зрения бизнеса, задачи сотрудников являются средством достижения цели. Общая цель – релизить качественный продукт и корректно работающие обновления.

Шестое: принцип «креативной пары». Креативными парами называют небольшие команды в рекламном бизнесе. Тот же принцип полезен и в разработке – не буквально, речь именно о принципе. Решение о реструктуризации команды и организации ее работы над продуктом находится в полномочиях менеджера.

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

Седьмое: программист по архетипу своей роли и применяемому стилю мышления – «созидатель, строитель». Тестировщик по архетипу своей роли и применяемому стилю мышления – «критик, разрушитель». При тестировании он имитирует задачу изобретательными способами сломать систему, чтобы увидеть, при каких условиях она перестает работать, и показать программисту, где нужно укрепить или перестроить конструкцию. Важно понимать и помнить, что это архетипы ваших ролей, стили мышления, которые применяются именно в этих ролях. Люди не сводятся к ролям, а разные стили мышления мы применяем опционально при решении разных задач. almamat blog