Я бэкенд-разработчик в серверной команде Badoo. На прошлогодней конференции HighLoad я выступал с докладом, текстовым вариантом которого и хочу поделиться с вами. Этот пост будет наиболее полезен тем, кто самостоятельно пишет тесты для бэкенда и испытывает проблемы с тестированием legacy-кода, а также тем, кто хочет тестировать сложную бизнес-логику.
О чём пойдёт речь? Сначала я коротко расскажу о нашем процессе разработки и о том, как он влияет на нашу потребность в тестах и желание эти тесты писать. Затем мы пройдёмся снизу вверх по пирамиде автоматизации тестирования, обсудим используемые нами виды тестов, поговорим об инструментах внутри каждого из них и о том, какие проблемы мы решаем с их помощью. В конце рассмотрим, как поддерживать и запускать всё это добро.
Недавно одна моя знакомая QA Engineer, которая долгое время работала в вялотекущем проекте, где круг ее обязанностей был строго очерчен, сменила работу и устроилась в свежезапущенный проект. Просидев пару дней без обозначенных сверху заданий, и откровенно заскучав, она пошла к руководству с вопросом «Что мне делать?» на что получила многозначительный ответ «Организуй свою работу». И тут она впала в ступор «А это как?». И правда, как?
Несколько месяцев назад я сама сменила работу и попала в английский проект, в котором никогда раньше не было QA. Сам проект существует давно. Как часто бывает, компания, в которой много денег, купила компанию, в которой денег поменьше, но есть клиенты. В итоге, крупная компания получила новых клиентов и минус одного конкурента на рынке. Мой проект получил смену менеджмента и принципов управления.
В первые же дни знакомства с новой командой, я услышала честный недоумевающий вопрос одного из разработчиков Лондонского офиса «А что ты будешь здесь делать?»
Большинство руководителей в IT-сфере выросли из технарей. Нам комфортнее работать с программами, чем с людьми, а слово “сервер” нам ближе и понятнее, чем слово “мотивация”. Чтобы решить эту проблему, биг-боссы компаний приглашают сторонних коучей и экспертов по мотивации, а IT-менеджеры пытаются ломать себя и следовать правилам с тренингов: хвалить, давать обратную связь, мотивировать и стимулировать. Такие натянутые действия тоже не приводят ни к чему хорошему!
Оказывается, люди мотивированы всегда, и их не надо пинать! Вопрос не в том, мотивированы они или нет, а в том, что мешает раскрытию их максимального потенциала.
В своём докладе Виктория расскажет о том, как решили эту задачу в Лаборатории качества, внедрив новую парадигму Менеджеров Счастья. В числе тех инструментов, которые помогли им, и которыми автор поделится с вами:
* анализ проблем, хотелок и пожелалок наших любимых сотрудников; * обучение линейных руководителей менеджменту счастья; * совместная проработка общих целей; * решение не поверхностных, а корневых проблем.
Не нужно создавать созданное, нужно научиться применять имеющееся. Все проще, чем кажется.
Вы когда-нибудь задумывались о том, что команде, которая что-то разрабатывает, тестировщик или разработчик автотестов на самом деле не нужен? Этой команде необходим человек, который будет совмещать свою роль с ролью тестировщика.
Давайте рассмотрим традиционное положение вещей.
Если у вас не agile, то у вас скорее всего есть:
-отдел разработки;
-отдел аналитиков;
-отдел тестирования
И все они могут одновременно работают над разными продуктами.
А если вы еще решили делать автоматизацию тестирования, то появляется еще отдел автоматизации тестирования. И для управления всем этим добром, как правило, нужен руководитель проектов (РП). А теперь внимание, что делать РП, у которой тестировщика нет? Или он ушел в отпуск, или заболел?
-Забивать на качество продукта?
-Ждать когда он вернется?
-И нести финансовые потери от несвоевременного запуска продукта или же наоборот, от того что продукт выпустили в «забагованном» состоянии.
Если же у вас agile, то проблемы остаются те же. Только тут, как правило 1 тестировщик и 1 разработчик автотестов на команду, как минимум.
И тут помимо озвученных вопросов, возникает еще вопрос:
-Что делать, если этих двух людей на один проект? Проект не генерирует такую нагрузку для двоих?
-Что делать, если разработчик автотестов отказывается заниматься функциональным тестрованием, если вы оставляете его одного в команде?
-Или же, если тестировщик не настолько компетентен, чтобы писать автотесты самостоятельно?
В своем докладе автор расскажет о том, что такое кроссфункциональная команда. Расскажет, как на своем примере «затащили» роль тестировщика в каждого члена команды, а также от безвыходности и необходимости автоматизации тестирования научили разработчиков писать и помогать поддерживать автотесты тестировщикам.
Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щуриться от боли и слёз, когда тебе прилетает очередной набор тест-кейсов для регрессионного тестирования.
Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:
Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).
Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно здесь и здесь).
Вопрос от тестировщиков: "Зачастую мне дают продукт на тестирование, но не выделяют достаточно времени. Как мне одобрить релиз, если я недостаточно протестировал?"
Вот мой ответ.
Если вы тестировщик, то мне странно слышать, что вы отвечаете за одобрение релиза. Решение, выходить ли в релиз – это бизнес-решение, а совсем не техническое. Оно, безусловно, базируется на технических соображениях, и вполне естественно предоставить отчет об этих соображениях. С точки зрения бизнеса было бы глупо игнорировать этот отчет. Однако не менее глупая ситуация возникнет, если бизнес спихнет бизнес-решение на технический персонал. Мы служим бизнесу, а не управляем им, и технари зачастую не имеют доступа к бизнес-информации.
Идея, что тестировщики могут разрешить или запретить релиз, легко проверяется. Попробуйте отказаться от релиза, пока не будете достаточно довольны тем, что вы знаете о продукте и тем, сколько именно вы знаете. Вы быстро получите результат.
Пожалуй, ни в одной компании не найдется двух идентичных и взаимозаменяемых сотрудников. Одни превосходно разбираются в техниках тест-дизайна и ювелирно пишут тестовую документацию, другие — мастера различных видов и типов тестирования. В процессе работы над проектами сотрудники, как правило, дополняют друг друга, что благотворно сказывается на конечном продукте.
Вся наша работа по обеспечению качества выстроена на основе глубокой экспертизы прикладной области. Для одних команд — это страхование, для других — финансовые инструменты, интернет-банкинг или биржевая торговля, для третьих — широкий сектор государственных проектов.
Секрет в том, что тестировщики должны не просто разбираться в прикладной области, а должны знать ее специфику и наиболее типичные ошибки, более того – должны понимать своих пользователей.
Именно поэтому мы так много времени и сил уделяем обучению и погружению наших сотрудников.
Негласно считается, что хороший менеджер – это родитель одного, а лучше двух и более детей. Никогда не задумывались, почему? Возможно, менеджер-родитель обладает преимуществом в планировании? Может быть, он умеет грамотно распределять задачи? Или тут что-то связано с декомпозицией и оценкой времени?
Секрет же менеджера-родителя кроется в отношениях. Хороший менеджер-родитель переносит паттерны общения со своими детьми в команду. Растит новичков, защищает их от внешних угроз (к примеру, от негатива смежных команд), проявляет участие в жизни каждого, радуется успехам и с родительским терпением принимает нас такими, какие мы есть. Мне приходилось работать под руководством разных людей в разных командах, и самое приятное – находиться под опекой менеджера-родителя. В теплой семейной атмосфере и работать, знаете ли, приятнее, и расти в профессии легче.
В этой статье мы поговорим о неминуемом – о появлении новичка в команде. Можно ли при этом обеспечить ему безопасное погружение, не создавая также угрозы команде и всему проекту?
