План внедрения тестировщика

Дублирую мой пост на форуме.

Жизнь тестировщика иногда может сложиться так, что он попадает в проект или продукт, где тестирования как процесса не было, а необходимость возникла.

Альбом: randompics4lj

Конечно же, на эту тему уже была лекция Маргариты Сафаровой Аудит процессов тестирования при смене проектной команды, а еще много говорили демиурги - как правильно взлабать отдел качества.

Что делать, если тебя берут в продукт не руководителем отдела тестирования, состоящего из тебя одного, а берут тебя рядовым тестировщиком.

И говорят, что у нас все было хорошо, а теперь есть ты.

К чему это все?
Слишком часто получается так, что группа разработчиков, аналитиков и прочих рыцарей клавиатуры и монитора заманивает тестировщика к себе в логово и начинает делать страшное - объяснять ему как надо тестировать(здесь просветленные зрители ужаснулись и сделали круглые глаза). И появляется не тестировщик, но чернорабочий программист или чернорабочий аналитик.


У меня есть своя версия на все эти счета.

Входные данные:
Для начала тестером берут одного человека.
Примерно 5-6 программистов уже несколько лет пишут хороший, годный продукт и успешно продают его.
Отдельного процесса тестирования нет в силу ряда причин: тут и ласковый, душевный взгляд руководителя, и интересная парадигма разработки "быстро поднятое упавшим не считается" и еще куча того, о чем неизветно в принципе.
Продукт типичный: база(или несколько), сервер приложений(или несколько), клиент-браузер, кое-какие аппаратные завязки.

На какой вопрос я отвечваю: Чем этому тестировщику нужно заняться? А чем не нужно?

Как это обычно бывает?

1. Посадят человека учить систему и читать доки. На неделю-месяц-два.
2. Затем он будет проверять корректность работы новых фич по мере того, как программисты их создают.
3. Затем он утонет в объеме работ и будет терять смысл.

Что предлагаю я?

Сбор информации:

1. Выяснить мнение руководителя - какую проблему он хочет решить тестировщиком. Чего он от него будет ждать. Он "шоб был" никого нанимать не стал бы.
2. Узнать у разработчиков, какие баги специфичны для их фреймворка, архитектуры, железок, продукта в целом. Рассказать им о прелестях наличия специально обученного тестировщика в группе, о возможностях сотрудничества. Узнать, как тестер мог бы им помочь.
3. Очень плотно пообщаться с техподдержкой.
3.1. Выяснить личное мнение ТП о проблемах продукта. На что клиенты злятся. Чего не любят.
3.2. Взять, да и прошерстить базу Service Desk за последние полгода, вытащить из нее баги пропущенные к клиентам. (!)
4. Узнать, какие средства тестирования уже есть? Статический анализ кода, юнит тесты?
5. Само собой, процесс разработки. Коммиты, версии, релизы, сроки, тэги, CI.
6. По-моему, у них нет багтрекера. Но я не уверен.

Дальнейшие действия и варианты:

1. Вполне возможно, что хорошо сработавшейся команде тестировщик и не нужен, а надо внедрить еще пару тройку средств превентивного обнаружения багов.
2. Выделить первоочередные задачи для тестировщика
2.1.Для начала, ручная проверка функционала, в котором баги были найдены клиентами(см. базу техподдержки).
2.2. Адекватное встраивание предыдущего пункта в процесс разработки, чтоб тестирование не было совсем уж отдельным.
2.3. Действия, направленные на оправдание ожиданий руководителя проекта.
3. Если нет CI, то завести ее - это обязательно, но - факультативно и в будущем.
4. После того, как процесс оформится - только после этого - задуматься о постепенной автоматизации: bash скрипты, если будет необходимость - Selenium'ы и прочие testcomplet'ы.

5. Собрать результаты и выводы по предыдущим пунктам. Купить бутылку виски и долго на них медитировать. Составить план работ со сроками, ответственными и действиями. В плане - обучение, решение первоочередных проблем, второочередных проблем, привязка всего этого к релизам и т.п. Результаты деятельности тестера.

6. Показать план техподдержке, аналитике, разработчику. Переписать план. Показать его руководителю проекта. Таким образом надо, чтоб было достигнуто понимание, что и как будет тестироваться, и вообще, чего ждать.

7. Приступить.
...
9. PROFIT!!!

Альбом: randompics4lj

P.S. В молодую, динамично развивающуюся все еще требуется, ага.