Автор — Александр Селяев
![](https://quality-lab.ru/wp-content/uploads/2024/03/1-2-300x225.png)
За последнее время мне удалось «поосваивать» — в хорошем смысле слова — несколько разных по сложности командных проектов. Каждый проект — уникальный. А задачи с созданием группы тестирования — вроде бы одни и те же…
Новый проект. Новые люди. Новые традиции и новые горизонты в тестировании. Я бы хотел сегодня покопаться в этой нелегкой куче.
Знакомиться с новыми людьми.
Изучить новый продукт.
Построить свою работу с нуля.
Как не утонуть в новом хаосе?
Как бы вы начали входить в новый проект? Или вопрос опытным — как вы входили в новый проект? С чего бы начинали? Были бы это технологии или проблемная область? На какой стратегический вопрос хотели бы сперва найти ответ? Столько направлений, столько мыслей, столько желаний…Со временем у меня сформировался свой набор эвристик вхождения в проект — своего рода записная книжка товарища Селяева маленьких шагов (побед?) к достижению стратегических целей в тестировании нового проекта. Со временем я выделил несколько стратегических направлений, которые и пытаюсь «пробежать» за как можно быстрое время (ASAP):
- Взаимоотношения с командой и пользователями
- Тестовая лаборатория
- Учет работ и планирование
- Документация и База знаний
- Визибилити и Отчетность
В этой статье поговорим про взаимоотношения и тестовую лабораторию. Мой опыт. Мои евристики.
Взаимоотношения с командой и пользователями
![](https://quality-lab.ru/wp-content/uploads/2024/03/2-3-300x234.png)
Как живете? Первый вопрос команде
Знаете, какой мой первый вопрос к новой команде? Ни о технологиях, ни о практиках, ни о хотелках менеджеров этот вопрос. И, кстати, я его никогда не произношу, никому не задаю, но «подразумеваю» постоянно. Главное, что я хочу понять с самого первого шага в проекте:
Что это вы за команда такая, что это вы за группка людей, которая вот так просто, легко и беззаботно жила все это время без тестировщика и, может быть, жила бы и дальше, если бы я не пришел?
Действительно. Команда до моего появления как-то жила, как-то разрабатывала и как-то выпускала релизы. Но вот пришел я, и в их умных глазах читаются два вопроса — уже их вопроса: как Этот может знать лучше Меня, что тестировать и как тестировать?
Нужно ли Мне теперь тестировать самому? И вот на эти вопросы приходится отвечать уже мне и отвечать, отвечать, отвечать… Не ждать нежданчиков — узнать, чего хотят.
Вы удивитесь, но очень может быть, что разработчики и менеджер проекта хотят от вас совсем не того, что вы пришли им дать.
Честно! Ожидания с обеих сторон могут быть различными. Вы хотите зрелых процессов, а им, может быть, нужно только пройти аудит. Вы хотите продукт с небольшим количеством критичных багов, а они, может быть, только быстрой победы, промоушена и уйти на более зеленое пастбище. Вы хотите знать нужды пользователей, а они понимают это как посягательство на их полномочия (это больше про менеджеров).
Спроси, чего ждут от тебя начальники и команда — договорись что будешь делать в первую очередь, пусть это не будет нежданчиком для тебя и для них.
У меня в календаре стоят даты, когда я набираюсь смелости и задаю в лоб менеджерам вопросы:
- Вам хорошо от того, что делают тестировщики?
- Вы довольны достигнутыми результатами?
- Что еще могут сделать тестировщики?
- Когда вы хотите это иметь?
А потом смотрю на список и произношу: м-да… А теперь, когда мы все поняли, что хотим очень многого, давайте расставим приоритеты. Понять, чего хочет «начальника», поможет не наступить на мозоль или грабли. В первом случае можно сделать неприятно кому-то, а во втором случае — заработать шишку себе. Шишка — не орден — гордиться нечем.
Делиться опасениями, рисками и проблемами
![](https://quality-lab.ru/wp-content/uploads/2024/03/3-3-246x300.png)
Может показаться, что о проблемах, с которыми вы сталкиваетесь, знают только вы и ваша семья. На совещании промолчал, дома — наорал на жену.
На работе, в отличие от семьи, есть две крайности:
- Ну ты же ничего не говорил.
и
- Ну тебя же взяли, чтобы ты проблемы решал, а не рассказывал о них.
Когда-то меня подобные ответы заставляли выпучивать глаза и глотать ртом воздух: они что, ничего не видели?
Прошло время, я поседел, поумнел и набрался наглости и опыта. Теперь каждый в команде знает о моих проблемах и о том, как я их решаю. Ибо:
Если человек говорит, что он решает проблему и планирует решить ее к определенному сроку, определенным способом, можно либо посоветовать, как сделать быстрее, либо не мешаться под ногами.
Хотя всегда могут найтись излишне инициативные сослуживцы и начальники. И ведь лесом их не пошлешь.
Команда — мой круг. Мой первый круг. Второй, третий…
![](https://quality-lab.ru/wp-content/uploads/2024/03/4-2-300x300.png)
Знакомиться активно
Быть новичком — это и выгодно, и невыгодно одновременно. Выгодно, поскольку нет еще груза ошибок, невыгодно — также нет и авторитета полезных решений. Но ни в одной команде не бывает так, что все против — всегда найдется человек, который может стать первым кругом.
Построить первый, второй и прочие круги общения — одна из первых главных задач новичка.
Позже вы будете складировать людей в свои круги, но сперва попытайтесь найти среди этих сильных личностей тех… кто любит печеньки. Нет, честно — ни одна команда разработчиков так и не устояла перед анекдотами, историями из жизни и печеньками. Программисты как дети, ей Богу!
Запоминать новых людей
Как опытный новичок, советую вам с первого дня создать страницу в вашей локальной вики и описывать в ней людей, с которыми вы общаетесь. Конечно, когда ваша команда локальна и не превышает 10 человек, можно обойтись без крайностей.
В текущем новом проекте за три месяца мне уже пришлось общаться кроме своей команды (15 человек в 6 странах) еще с 7-ю специалистами из 5 параллельных проектов. Из 23-х специалистов три месяца назад я знал только двоих. С 6-ю я общался всего один раз. Без записи — как вспомнить имя Rohit Gnapnadesh и что именно он отвечает за Emma сервисы на UAT?
Не бояться быть дураком и задавать вопросы
Я не знаю лучшего способа узнать о чем-то, чем спросить самому. Редко в командах есть хорошие учителя. Приходится самообучаться, записывать и применять все самому (если вы ничему не научились из этой книги — это ваша собственная вина). Если не знаешь, где что-то найти, то подход только один — спрашивать, спрашивать, спрашивать.
Быть дураком — не стыдно. Стыдно продолбать баг на 300 килоевро из за своей скромности.
Кто такой конечный пользователь?
![](https://quality-lab.ru/wp-content/uploads/2024/03/5-2-247x300.png)
Познакомиться с пользователями
Еще жив в моей памяти проект, в котором мы не знали своих пользователей. Вернее, не знали всех пользователей. А их были десятки… К тому времени, как сменилось две команды разработки, 3 ITPM-а, несколько вендоров, и, наконец, пришел я — остался список из 7 проектов, которым мы и предоставляем услуги передачи и обработки данных. Про проблемы остальных мы узнавали, только когда релизили новую версию продукта. Узнавали весьма с печальными последствиями. Это, конечно, редкий случай, но каждый раз, когда я появляюсь в проекте, я хочу знать, кто использует нашу программу и как он ее использует.
Только зная, как конечный пользователь использует программу, я понимаю, как действительно работает программа и как ее нужно тестировать, а также как она не используется и как ее тестировать не нужно — определяются риски и уменьшается объем тестирования.
Найти способ собирать жалобы пользователей
Я сразу пытаюсь присосаться к любому каналу связи, где пользователи жалуются. Нет ничего полезнее, чем крик души от пользователя. Желательно, чтобы этот канал был единственным и широким — там должны быть все. В этом похожи все сервисы — и продажа товаров, и туристические туры, и разработка ПО.
Жалобы пользователей формируют стратегию улучшения качества продукта, потому что о качестве продукта правду могут сказать только те, кто его используют, кто зарабатывает или теряет деньги, используя продукт.
Жалобы пользователей — это не тот случай, когда молчание — золото.
Тестовая лаборатория
![](https://quality-lab.ru/wp-content/uploads/2024/03/6-2-300x142.png)
Где тестировать?
Разработчик может сказать: «У меня баг не воспроизводится… Будем закрывать?»
Тест-менеджер может спросить: «Нашел проблему?… А как работало раньше — в предыдущей версии?»
Проект-менеджер может поинтересоваться: «А насколько данные в тестовой лаборатории близки к тем, что на проде?»
Вопросы не редкие, единого рецепта нет, и задуматься нужно уже с самого начала.
Отказаться от «не воспроизводится»
Разные данные, разные способы установки/запуска приложений, разные наборы компонент — все это очень сильно влияет на конечный результат. Если в системе может быть разным вообще все — утверждать, что тестировщик в описании бага не упомянул главные детали конфигурации не совсем честно. Кстати, сохранять целиком конфигурацию тоже не всегда возможно (объем данных, архитектура компонент и т.п и т.д)
Не каждый разработчик, к сожалению (и не каждый тестировщик тоже), понимает, что нужно одна точка входа для тестировщиков, разработчиков, пользователей и других заинтересованных в проверке лиц.
Слова «у меня не воспроизводятся» стоят дорого. От их причин нужно избавляться. Моя первая задача в этом случае — выбить себе тестовую лабораторию. Вторая задача — выбить тестовую лабораторию для программистов. Третья задача — сделать их похожими. Понимать, как работало раньше, в предыдущих версиях.
Бывает, что баги живут несколько релизов. Поэтому приоритеты у таких багов, как правило, но не обязательно — ниже, чем у регрессионных.
Понять — как работало в предыдущем релизе — еще одна задача, связанная с настройкой тестовой лаборатории. И не всегда эта задача простая. Ох, не всегда.
Игра «давайте сделаем одну тестовую лабораторию» нередко проходит с крайностями: Раньше и без этого обходились — т.е., и сейчас нам это не нужно. Давайте сделаем все, как на проде — т.е., не важно, сколько времени нам понадобится, не важно, что мы пока не знаем, что именно нужно, но не начнем тестировать, пока не будет все прям как на проде. И вот такие бальные танцы бегемотиков между двумя полярными мнениями порой и называют стратегией развития отдельно взятой тестовой лаборатории. Цена и риски — это два основных существительных в споре.
Тестер: Будет лучше?
Менеджер: Да
Тестер: Сколько мы потратим на это времени или денег?
Менеджер: Нужно тратить деньги и время? Все работы связанные с тестовой лабораторией нужно свести к минимиму:
- Легко и быстро установить с нуля
- Легко и быстро переустановить
- Легко и быстро настроить
- Легко и быстро скопировать
- Легко и быстро перегрузить
- Легко и быстро получить сообщения об ошибках
- Легко и быстро прочитать логи
Тратить на поддержку тестовой лаборатории мало, ибо есть много других вещей, которые нужно сделать.
От кого берем, куда отдаем
![](https://quality-lab.ru/wp-content/uploads/2024/03/7-1-300x207.png)
Построить карту приложения
Первый, второй, третий круги бывают не только у людей. Они есть и у приложений тоже. Представьте себе схему метро. Кольцевая — это ваш проект. Все что вне — приложения, с которыми происходит обмен данными. Первая станция — это первое приложение, вторая — это приложение, которое общается с первым приложением, и так далее. Примерно так выглядят приложения в банках. И порой черт ногу сломит, чтобы узнать откуда к нам приходят данные и куда уходят. И главное — кто на этом заработает.
Поиск зависимостей, upstream/downstream приложений — еще один важный вопрос. Ибо это практически то же самое, что искать и разговаривать с клиентом. Понять — можно ли использовать псевдозаменители приложений.
Проблема всех зависимых приложений, обменивающихся информацией, в том, что они не подвластны тестировщику. Можно планировать, отслеживать, упрашивать, но жизнь показывает свою пятую точку и оказывается, что на последней неделе регрессионного тестирования одно из приложений, за которое отвечает другая команда, отваливается, либо из-за инцидента на проде они вынуждены гонять тесты производительности, либо еще какая нибудь детская неожиданность. И твоя команда опять остается один на один с решением:
- Выкатиться, не протестировав связку приложений
или
- Отложить релиз
Псевдозаменители, симуляторы, заглушки — одно из дешевых решений.
Понять, где мы можем заменить реальные внешние системы на симуляторы и насколько будет критично их использовать — еще один хороший вопрос в копилку новичка тестировщика.