Намедни подходит ко мне руководитель одного проекта и говорит: Wolonter, я хочу забацать тестирование нашего продукта. А ты нам расскажешь, как это сделать.
Я ответил: Отлично.
Входные данные:
Для начала тестером берут одного человека.
Примерно 5-6 программистов уже несколько лет пишут хороший, годный продукт и успешно продают его.
Отдельного процесса тестирования нет в силу ряда причин: тут и ласковый, душевный взгляд руководителя, и интересная парадигма разработки "быстро поднятое упавшим не считается" и еще куча того, о чем я не подозреваю.
Продукт типичный: база(или несколько), сервер приложений(или несколько), клиент-браузер, кое-какие аппаратные завязки.
Чего от меня ждут: ответа на вопросы: Чем этому тестировщику нужно заняться? А чем не нужно?
Как я думаю подойти к вопросу?
Сбор информации:
- Выяснить мнение руководителя - какую проблему он хочет решить тестировщиком. Чего он от него будет ждать. Он "шоб был" никого нанимать не стал бы.
- Узнать у разработчиков, какие баги специфичны для их фреймворка, архитектуры, железок, продукта в целом. Рассказать им о прелестях наличия специально обученного тестировщика в группе, о возможностях сотрудничества. Узнать, как тестер мог бы им помочь.
- Очень плотно пообщаться с техподдержкой.
- Выяснить личное мнение ТП о проблемах продукта. На что клиенты злятся. Чего не любят.
- Взять, да и прошерстить базу Service Desk за последние полгода, вытащить из нее баги пропущенные к клиентам. (!)
- Узнать, какие средства тестирования уже есть? Статический анализ кода, юнит тесты?
- Само собой, процесс разработки. Коммиты, версии, релизы, сроки, тэги, CI.
- По-моему, у них нет багтрекера. Но я не уверен.
Дальнейшие действия, предположения и варианты:
- Вполне возможно, что хорошо сработавшейся команде тестировщик и не нужен, а надо внедрить еще пару тройку средств превентивного обнаружения багов.
- Выделить первоочередные задачи для тестировщика
- Для начала, ручная проверка функционала, в котором баги были найдены клиентами(см. базу техподдержки).
- Адекватное встраивание предыдущего пункта в процесс разработки, чтоб тестирование не было совсем уж отдельным.
- Действия, направленные на оправдание ожиданий руководителя проекта.
- Если нет CI, то завести ее.
- После того, как процесс оформится - только после этого - задуматься о постепенной автоматизации: bash скрипты, если будет необходимость - Selenium.
- Собрать результаты и выводы по предыдущим пунктам. Купить бутылку виски и долго на них медитировать. Составить план работ со сроками, ответственными и действиями. В плане - обучение новичка, решение первоочередных проблем, второочередных проблем, привязка всего этого к релизам и т.п. Результаты деятельности тестера.
- Показать план техподдержке, аналитике, разработчику. Переписать план. Показать его руководителю проекта. Таким образом я хочу чтоб было достигнуто понимание, что и как будет тестироваться, и вообще, чего ждать.
Как-то так.
Ремарки:
- Форум читал, например тут и тут.
- Документация есть. Разработчики в одном месте в пределах прямой видимости.
- О том, что тестер нужен мне сказали "снизу" - сотрудник техподдержки. Потом были мои и не только мои диалоги с руководством и это стало инициативой "сверху".
Я хочу спросить - как вам мой план? На что стоит посмотреть, куда обратить внимание? Если нужно, могу уточнить детали.
