- PVSM.RU - https://www.pvsm.ru -
Привет! Меня зовут Илья Кудинов, и я работаю QA-инженером в компании Badoo. Три года назад я начал посещать различные IT-конференции и рассказывать о процессах и технологиях, применяемых нами при контроле качества. И конечно же, после каждого доклада я общался со слушателями, интересовался, как работают они. В этом деле меня всегда мотивировали отзывы вида «Раньше мы работали вот так, но, послушав твой доклад, мы увидели, как можно сделать лучше», а еще лучше — когда люди не копируют наши приемы, а придумывают что-то сами, иногда даже более интересные варианты. Таких историй у меня накопилось много, и я хочу поделиться с вами некоторыми из них (все имена и названия вымышлены, любые совпадения с реальными лицами являются случайностью). Может быть, что-то из этого поможет вам увидеть направление развития вашего собственного проекта — и это будет самой большой наградой для меня! Разумеется, буду рад после этого выслушать и ваши истории — в комментариях или личных сообщениях.
Прежде всего давайте оговорим два момента.
Первое: не для всех видов и масштабов разработки советы из этой статьи окажутся подходящими (для некоторых, я уверен, они будут даже очень вредными), поэтому для представителей разработчиков софта самолётов (а так же для тех гуру тестирования, кому мои советы кажутся очевидными) этот рассказ будет просто занимательным чтивом. Я в первую очередь ориентируюсь на быстроразвивающиеся продукты с плотным графиком релизов. Интереснее всего будет представителям тех компаний, где QA-отдел существует только в зародыше или пока не существует вообще.
Второе: нет, «грустные» истории не выдуманы. И нет, они, возможно, не так ужасны в действии, как я их описываю, но свое мнение я буду стараться всегда максимально аргументировать.
Визуализации мыслей и идей будут помогать вот эти три товарища, знакомьтесь:
Итак, давайте начнем с того, что определимся, кто же мы, собственно такие. QA-инженеры? Тестировщики? Тестеры?
Тестер — это такой прибор, использующийся для замера электрических характеристик цепи. Не надо нас так называть, мы обижаемся.
Тестировщик — специалист, занимающийся тестированием. Тестирование — важный и незаменимый процесс при разработке чего бы то ни было, но в него входит исключительно процесс помещения системы в различные ситуации с целью изучения ее поведения и верификации поставленных на тестирование задач.
QA-инженер — специалист, занимающийся контролем качества. В это понятие входят как тестирование, так и, например, последующий мониторинг, разработка и поддержка различных автотестов и прочих средств автоматизации и оптимизации процесса, релиз-инжиниринг.
Впрочем, с целью упрощения речи, «тестировщик» тоже сойдет, но только если вы говорите это с должным уважением.
Я гордо говорю, что я QA-инженер. Моя работа (и работа моих коллег как по компании, так и по сфере вообще) направлена на обеспечение максимально достижимого качества продукта — на то, в чем в любом случае заинтересованы все остальные участвующие в проекте стороны. Именно поэтому мне очень жаль, что во многих компаниях мои собратья зачастую рассматриваются как сугубо вспомогательный персонал, роль которого в проекте самая незначительная (уборщики хотя бы грязные кружки из-под кофе убирают за разработчиками).
На самом деле роль тестировщика в проекте в конечном счете является ничуть не менее важной, чем роль разработчика. Бьёрн Страуструп (дат. Bjarne Stroustrup) в своей книге «Язык программирования C++» писал: «Программа, которая не прошла тестирование, не работает». Зачем вам нужны программисты, продукты которых никогда не будут работать? Тестировщик — не раб разработчика, великодушно выдающего задачи типа «проверь, пока я раскладываю на прод». Наоборот, разработчик и тестировщик совместными усилиями достигают поставленной цели — выпустить продукт к назначенному сроку в максимально высоком качестве. Именно для этого и создается отдел контроля качества. Но… как его организовать?
Итак, компания «ФОЛИАНТ ЛИЦ» решила заниматься разработкой программного обеспечения. Она подошла к этому делу основательно, даже отважилась на создание QA-отдела! Сколько нужно набрать туда людей, если у нас уже есть 12 разработчиков? Классический подход подсказывает, что приблизительное соотношение рабочей силы должно быть таким: 1 QA-инженер на 3-4 разработчиков. Сказано — сделано! Нанимаем трех инженеров и считаем себя большими молодцами.
Проект начинает развиваться, к QA-отделу предъявляются все новые и новые требования. Вот мы уже достаточно повзрослели, чтобы производить релизы не просто выкладкой gzip-архива на продакшен, а путем хорошо построенного и налаженного деплой-процесса. Кто будет этим заниматься? Отдадим это нашему специалисту в отдел контроля качества!
Функционала становится все больше — тестировать регрессию все сложнее. Один из наших тестировщиков имеет опыт разработки? Отлично! Пусть он теперь занимается разработкой автотестов! Хорошо мы придумали, да?
Что мы получили в итоге такого замечательного плана? Тестированием задач наших двенадцати разработчиков постоянно теперь занимается только один из QA-инженеров. Интересно, почему очередь на тестирование начала расти и наши отлично организованные релизы регулярно задерживаются?
Урок: рассчитывая количество специалистов для QA-отдела, нужно принимать во внимание все сферы деятельности, которыми они будут заниматься помимо непосредственного тестирования, и нанимать при необходимости новые кадры, а не распределять новые обязанности между имеющимися. Разве не это подсказывает здравый смысл? Практика показывает, что не всегда.
Урок: отдел контроля качества стоит развивать параллельно отделу разработки. Возможно, даже с опережением. Сложно бороться с конкурентами и доставлять пользователям новаторский функционал, если вы не можете обеспечить проекту должное качество.
Урок: отделы тестирования и разработки — не враги друг другу. Они не должны сидеть по разные стороны укрепрайонов, стараясь при первой же возможности свалить работу друг на друга. Как я уже говорил, их совместная цель — релиз задачи в поставленный срок, и их обязанностью является объединение усилий для достижения этой цели. Это вовсе не значит, что нужно закрывать глаза на ошибки: просто после обнаружения незначительного дефекта не обязательно сразу же отправлять задачу на доработку, вполне можно записать ее в сторонку, проверить, насколько это возможно, и отправить уже с полным списком ошибок, чтобы сэкономить горы времени на постоянно повторяющихся этапах разработки и тестирования.
Здесь стоит заметить, что в некоторых случаях подобный подход все же уместен. В «промышленной» разработке (например, при поддержке софта использующегося на самолетах) качество и соответствие процессам может ставиться выше скорости, и это правильно. Наверное, я бы не хотел летать на самолетах, тестируемых и разрабатываемых работниками небольших «ультрасовременных и быстроразвивающихся» стартапов.
И вот QA-отдел организован. Чем он будет заниматься? Правильно, контролем качества. Но как это процесс будет устроен?
Любые QA-процессы всегда строятся вокруг балансирования между качеством и скоростью. Абсолютное качество недостижимо (если вы со мной будете спорить — надеюсь, вы разрабатываете самолеты), тестировать задачи мгновенно тоже невозможно. Где же найти это равновесие? Здесь каждая команда может придумать свое решение. Для кого-то это Continious Integration, кто-то отдает предпочтение строго регламентированным и спланированным релизам — и нельзя просто подсмотреть процессы, поставленные вашими соседями по гаражу.
Как QA-процессы встраиваются в процессы развития проекта? Давайте поделим их на три этапа: продакт-дизайн, разработка и тестирование. Два молодых стартапа подошли к этому вопросу совершенно по-разному: компания «БОДУНЫ» плотно связала QA-инженеров с каждым из них, а «ПОЧТИ.РУ» оставила им только тестирование. Кто из них прав? Как говорится, истина может быть где-то посередине.
Что мы получаем с каждым новым этапом QA-процесса? Качество. Что мы при этом теряем? Скорость. Какими же этапами контроля качества можно жертвовать?
Тестированием? НЕТ.
Контролем качества при разработке? Звучит важно. Нет, конечно не нужно чтобы тестировщик сидел за плечом у разработчика и больно щипал его каждый раз, когда тот забывает поставить точку с запятой. Есть много других способов помочь разработчикам соблюдать определенный уровень качества. Удачно настроенная система контроля версий, различные хуки и скрипты для проверки корректности кода, написание юнит-тестов (здесь, правда, QA может выступать только в роли надзирателя с кнутом и пряником), удобная система code review — все это в области ответственности отдела контроля качества.
Контролем продакт-дизайна? Ну… В «промышленной» разработке существует целое направление контроля качества — тестирование и анализ ТЗ. Это помогает избежать логических и архитектурных ошибок на начальных этапах развития каждого проекта — и катастрофически отдаляет возможность начала разработки.
Наверное, в молодом стартапе это излишние предосторожности. Высокая интеграция различных отделов друг с другом позволит всем участникам проекта (и разработчикам, и тестировщикам) увидеть подробности проекта, определить шероховатости и донести до менеджмента полезные (и не очень) идеи. К тому же, в нашем мире динамичных проектов и Agile-методологий ТЗ зачастую изменяется уже во время разработки (и даже после релиза, в конце концов), так что имеет смысл позволить продакт-менеджерам выражать себя бесконтрольно и уже потом вносить свои предложения и поправки.
Урок: контроль качества на каждом этапе развития проекта положительно влияет на качество и катастрофически понижает скорость. Нужно строить процессы так, чтобы они соответствовали требованиям к вашему проекту, и не копировать бездумно чужие практики и статьи из книжек (и из Хабра, да-да).
Урок: не стоит возвращать задачку при первом же непонятном моменте. Совместный с разработчиком дебаг — не только полезный и эффективный процесс, но и зачастую поучительное (оба участника могут глубже вникнуть в происходящее) и веселое занятие.
Урок: нужно стараться максимально интегрировать процессы и инструментарий отделов разработки и тестирования. Это поможет обоим отделам и проекту в целом. Иногда это требует небольших жертв от всех участвующих, но в конечном счете позволяет добиться куда больших успехов.
Урок: общая документация, позволяющая определить, что стоит тестировать в той или иной задаче — хорошо. Подробные инструкции и кейсы… наверное, не очень. (разработчики самолетов — забудьте, что сейчас прочитали. ПОЖАЛУЙСТА!)
Урок: имеет смысл иметь практику обмена знаниями внутри QA-отдела. Можно периодически обмениваться задачами, чтобы не привыкать к одному компоненту (одно из плохих последствий такой «специализации» — «замыливающийся» глаз), можно проводить внутренние семинары и лекции, на которых специалисты расскажут о новшествах в своей сфере ответственности, интересных кейсах и технологиях: это приведет не только к взаимозаменяемости специалистов, но профессиональному росту каждого из них.
Урок: QA-процесс не прекращается сразу же после релиза задачи на продакшен. Всегда имеет смысл последить за поведением нового функционала, и крайне важно иметь инструменты, которые это позволяют.
Урок: в возникновении дефектов виноваты все участвующие в проекте стороны, не стоит обвинять в его возникновении только тестировщика.
В компании «СЦОННИ» приняли решение начать разработку автоматизированных тестов. Один из тестировщиков имеет навыки программирования, и эту задачу отдали ему. Он писал тесты, был доволен своей работой и в какой-то момент покрыл тестами почти весь продукт. Все были рады, пока не заметили, что ушедшему в другой проект тестировщику не стали искать замену.
Событие превратилось в тенденцию, и QA-отдел начал таять. Когда перепуганные инженеры прибежали к руководству, то с улыбкой ответило: «У нас теперь такие замечательные автотесты, зачем нам скучные несовременные ручные тестировщики?» Объяснить им ничего не получилось, и все осталось на своих местах. Дела шли хорошо до тех пор, пока на продакшене не стало появляться все больше и больше ошибок, и все они — в самом новом, еще не покрытом тестами функционалом. Руководство осознало свою ошибку, но было уже слишком поздно… *громкая драматическая музыка*
Урок: автотесты являются исключительно вспомогательным средством контроля качества и никоим образом не заменяют собой ручное тестирование.
Урок: гораздо лучше, когда с автотестами работают все представители QA-отдела. Пусть не все из них будут в состоянии написать тест с нуля, но сделать так, чтобы каждый инженер мог оценить состояние тестов в данный момент, понять причину их провалов, поправить простенькую ошибку или покрыть тестом новый несложный кейс, стоит.
Надеюсь, что-то из того, о чем я многословно писал, окажется для вас полезным. Кому-то поможет найти шероховатости в процессах, другим подскажет выход из уже изучаемой проблемы. Даже если и не так, может, вы хотя бы посмеялись над тем, что я вам рассказал. Или хотя бы над моей наивностью. Главное — сделать мир лучше хоть в чем-то, хоть немножко. Правда?
Автор: Badoo
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/testirovanie/142442
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/301764/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.