Автор — Александр Селяев
За последнее время мне удалось «поосваивать» — в хорошем смысле слова — несколько разных по сложности командных проектов. Каждый проект — уникальный. А задачи с созданием группы тестирования — вроде бы одни и те же…
Новый проект. Новые люди. Новые традиции и новые горизонты в тестировании. Я бы хотел сегодня покопаться в этой нелегкой куче.
Знакомиться с новыми людьми.
Изучить новый продукт.
Построить свою работу с нуля.
Как не утонуть в новом хаосе?
Как бы вы начали входить в новый проект? Или вопрос опытным — как вы входили в новый проект? С чего бы начинали? Были бы это технологии или проблемная область? На какой стратегический вопрос хотели бы сперва найти ответ? Столько направлений, столько мыслей, столько желаний…Со временем у меня сформировался свой набор эвристик вхождения в проект — своего рода записная книжка товарища Селяева маленьких шагов (побед?) к достижению стратегических целей в тестировании нового проекта. Со временем я выделил несколько стратегических направлений, которые и пытаюсь «пробежать» за как можно быстрое время (ASAP):
- Взаимоотношения с командой и пользователями
- Тестовая лаборатория
- Учет работ и планирование
- Документация и База знаний
- Визибилити и Отчетность
В этой статье поговорим про взаимоотношения и тестовую лабораторию. Мой опыт. Мои евристики.
Взаимоотношения с командой и пользователями
Как живете? Первый вопрос команде
Знаете, какой мой первый вопрос к новой команде? Ни о технологиях, ни о практиках, ни о хотелках менеджеров этот вопрос. И, кстати, я его никогда не произношу, никому не задаю, но «подразумеваю» постоянно. Главное, что я хочу понять с самого первого шага в проекте:
Что это вы за команда такая, что это вы за группка людей, которая вот так просто, легко и беззаботно жила все это время без тестировщика и, может быть, жила бы и дальше, если бы я не пришел?
Действительно. Команда до моего появления как-то жила, как-то разрабатывала и как-то выпускала релизы. Но вот пришел я, и в их умных глазах читаются два вопроса — уже их вопроса: как Этот может знать лучше Меня, что тестировать и как тестировать?
Нужно ли Мне теперь тестировать самому? И вот на эти вопросы приходится отвечать уже мне и отвечать, отвечать, отвечать… Не ждать нежданчиков — узнать, чего хотят.
Вы удивитесь, но очень может быть, что разработчики и менеджер проекта хотят от вас совсем не того, что вы пришли им дать.
Честно! Ожидания с обеих сторон могут быть различными. Вы хотите зрелых процессов, а им, может быть, нужно только пройти аудит. Вы хотите продукт с небольшим количеством критичных багов, а они, может быть, только быстрой победы, промоушена и уйти на более зеленое пастбище. Вы хотите знать нужды пользователей, а они понимают это как посягательство на их полномочия (это больше про менеджеров).
Спроси, чего ждут от тебя начальники и команда — договорись что будешь делать в первую очередь, пусть это не будет нежданчиком для тебя и для них.
У меня в календаре стоят даты, когда я набираюсь смелости и задаю в лоб менеджерам вопросы:
- Вам хорошо от того, что делают тестировщики?
- Вы довольны достигнутыми результатами?
- Что еще могут сделать тестировщики?
- Когда вы хотите это иметь?
А потом смотрю на список и произношу: м-да… А теперь, когда мы все поняли, что хотим очень многого, давайте расставим приоритеты. Понять, чего хочет «начальника», поможет не наступить на мозоль или грабли. В первом случае можно сделать неприятно кому-то, а во втором случае — заработать шишку себе. Шишка — не орден — гордиться нечем.
Делиться опасениями, рисками и проблемами
Может показаться, что о проблемах, с которыми вы сталкиваетесь, знают только вы и ваша семья. На совещании промолчал, дома — наорал на жену.
На работе, в отличие от семьи, есть две крайности:
- Ну ты же ничего не говорил.
и
- Ну тебя же взяли, чтобы ты проблемы решал, а не рассказывал о них.
Когда-то меня подобные ответы заставляли выпучивать глаза и глотать ртом воздух: они что, ничего не видели?
Прошло время, я поседел, поумнел и набрался наглости и опыта. Теперь каждый в команде знает о моих проблемах и о том, как я их решаю. Ибо:
Если человек говорит, что он решает проблему и планирует решить ее к определенному сроку, определенным способом, можно либо посоветовать, как сделать быстрее, либо не мешаться под ногами.
Хотя всегда могут найтись излишне инициативные сослуживцы и начальники. И ведь лесом их не пошлешь.
Команда — мой круг. Мой первый круг. Второй, третий…
Знакомиться активно
Быть новичком — это и выгодно, и невыгодно одновременно. Выгодно, поскольку нет еще груза ошибок, невыгодно — также нет и авторитета полезных решений. Но ни в одной команде не бывает так, что все против — всегда найдется человек, который может стать первым кругом.
Построить первый, второй и прочие круги общения — одна из первых главных задач новичка.
Позже вы будете складировать людей в свои круги, но сперва попытайтесь найти среди этих сильных личностей тех… кто любит печеньки. Нет, честно — ни одна команда разработчиков так и не устояла перед анекдотами, историями из жизни и печеньками. Программисты как дети, ей Богу!
Запоминать новых людей
Как опытный новичок, советую вам с первого дня создать страницу в вашей локальной вики и описывать в ней людей, с которыми вы общаетесь. Конечно, когда ваша команда локальна и не превышает 10 человек, можно обойтись без крайностей.
В текущем новом проекте за три месяца мне уже пришлось общаться кроме своей команды (15 человек в 6 странах) еще с 7-ю специалистами из 5 параллельных проектов. Из 23-х специалистов три месяца назад я знал только двоих. С 6-ю я общался всего один раз. Без записи — как вспомнить имя Rohit Gnapnadesh и что именно он отвечает за Emma сервисы на UAT?
Не бояться быть дураком и задавать вопросы
Я не знаю лучшего способа узнать о чем-то, чем спросить самому. Редко в командах есть хорошие учителя. Приходится самообучаться, записывать и применять все самому (если вы ничему не научились из этой книги — это ваша собственная вина). Если не знаешь, где что-то найти, то подход только один — спрашивать, спрашивать, спрашивать.
Быть дураком — не стыдно. Стыдно продолбать баг на 300 килоевро из за своей скромности.
Кто такой конечный пользователь?
Познакомиться с пользователями
Еще жив в моей памяти проект, в котором мы не знали своих пользователей. Вернее, не знали всех пользователей. А их были десятки… К тому времени, как сменилось две команды разработки, 3 ITPM-а, несколько вендоров, и, наконец, пришел я — остался список из 7 проектов, которым мы и предоставляем услуги передачи и обработки данных. Про проблемы остальных мы узнавали, только когда релизили новую версию продукта. Узнавали весьма с печальными последствиями. Это, конечно, редкий случай, но каждый раз, когда я появляюсь в проекте, я хочу знать, кто использует нашу программу и как он ее использует.
Только зная, как конечный пользователь использует программу, я понимаю, как действительно работает программа и как ее нужно тестировать, а также как она не используется и как ее тестировать не нужно — определяются риски и уменьшается объем тестирования.
Найти способ собирать жалобы пользователей
Я сразу пытаюсь присосаться к любому каналу связи, где пользователи жалуются. Нет ничего полезнее, чем крик души от пользователя. Желательно, чтобы этот канал был единственным и широким — там должны быть все. В этом похожи все сервисы — и продажа товаров, и туристические туры, и разработка ПО.
Жалобы пользователей формируют стратегию улучшения качества продукта, потому что о качестве продукта правду могут сказать только те, кто его используют, кто зарабатывает или теряет деньги, используя продукт.
Жалобы пользователей — это не тот случай, когда молчание — золото.
Тестовая лаборатория
Где тестировать?
Разработчик может сказать: «У меня баг не воспроизводится… Будем закрывать?»
Тест-менеджер может спросить: «Нашел проблему?… А как работало раньше — в предыдущей версии?»
Проект-менеджер может поинтересоваться: «А насколько данные в тестовой лаборатории близки к тем, что на проде?»
Вопросы не редкие, единого рецепта нет, и задуматься нужно уже с самого начала.
Отказаться от «не воспроизводится»
Разные данные, разные способы установки/запуска приложений, разные наборы компонент — все это очень сильно влияет на конечный результат. Если в системе может быть разным вообще все — утверждать, что тестировщик в описании бага не упомянул главные детали конфигурации не совсем честно. Кстати, сохранять целиком конфигурацию тоже не всегда возможно (объем данных, архитектура компонент и т.п и т.д)
Не каждый разработчик, к сожалению (и не каждый тестировщик тоже), понимает, что нужно одна точка входа для тестировщиков, разработчиков, пользователей и других заинтересованных в проверке лиц.
Слова «у меня не воспроизводятся» стоят дорого. От их причин нужно избавляться. Моя первая задача в этом случае — выбить себе тестовую лабораторию. Вторая задача — выбить тестовую лабораторию для программистов. Третья задача — сделать их похожими. Понимать, как работало раньше, в предыдущих версиях.
Бывает, что баги живут несколько релизов. Поэтому приоритеты у таких багов, как правило, но не обязательно — ниже, чем у регрессионных.
Понять — как работало в предыдущем релизе — еще одна задача, связанная с настройкой тестовой лаборатории. И не всегда эта задача простая. Ох, не всегда.
Игра «давайте сделаем одну тестовую лабораторию» нередко проходит с крайностями: Раньше и без этого обходились — т.е., и сейчас нам это не нужно. Давайте сделаем все, как на проде — т.е., не важно, сколько времени нам понадобится, не важно, что мы пока не знаем, что именно нужно, но не начнем тестировать, пока не будет все прям как на проде. И вот такие бальные танцы бегемотиков между двумя полярными мнениями порой и называют стратегией развития отдельно взятой тестовой лаборатории. Цена и риски — это два основных существительных в споре.
Тестер: Будет лучше?
Менеджер: Да
Тестер: Сколько мы потратим на это времени или денег?
Менеджер: Нужно тратить деньги и время? Все работы связанные с тестовой лабораторией нужно свести к минимиму:
- Легко и быстро установить с нуля
- Легко и быстро переустановить
- Легко и быстро настроить
- Легко и быстро скопировать
- Легко и быстро перегрузить
- Легко и быстро получить сообщения об ошибках
- Легко и быстро прочитать логи
Тратить на поддержку тестовой лаборатории мало, ибо есть много других вещей, которые нужно сделать.
От кого берем, куда отдаем
Построить карту приложения
Первый, второй, третий круги бывают не только у людей. Они есть и у приложений тоже. Представьте себе схему метро. Кольцевая — это ваш проект. Все что вне — приложения, с которыми происходит обмен данными. Первая станция — это первое приложение, вторая — это приложение, которое общается с первым приложением, и так далее. Примерно так выглядят приложения в банках. И порой черт ногу сломит, чтобы узнать откуда к нам приходят данные и куда уходят. И главное — кто на этом заработает.
Поиск зависимостей, upstream/downstream приложений — еще один важный вопрос. Ибо это практически то же самое, что искать и разговаривать с клиентом. Понять — можно ли использовать псевдозаменители приложений.
Проблема всех зависимых приложений, обменивающихся информацией, в том, что они не подвластны тестировщику. Можно планировать, отслеживать, упрашивать, но жизнь показывает свою пятую точку и оказывается, что на последней неделе регрессионного тестирования одно из приложений, за которое отвечает другая команда, отваливается, либо из-за инцидента на проде они вынуждены гонять тесты производительности, либо еще какая нибудь детская неожиданность. И твоя команда опять остается один на один с решением:
- Выкатиться, не протестировав связку приложений
или
- Отложить релиз
Псевдозаменители, симуляторы, заглушки — одно из дешевых решений.
Понять, где мы можем заменить реальные внешние системы на симуляторы и насколько будет критично их использовать — еще один хороший вопрос в копилку новичка тестировщика.
