?

Log in

No account? Create an account

Previous Entry | Next Entry

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

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

Альбом: 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. В молодую, динамично развивающуюся все еще требуется, ага.

Comments

( 2 comments — Leave a comment )
koneko_sham
May. 23rd, 2011 06:17 pm (UTC)
"уже несколько лет пишут хороший, годный продукт". Те кто писал бОльшую часть, давно уволились, но судя по всему, они были не очень адекватны.
"пообщаться с техподдержкой". Техподдержка? Какая техподдержка, мы сами отвечаем на вопросы наших пользователей (если захотим, конечно), а уж они внешним пользователям чего-нибудь ответят. Например, спасибо скажут.
"Статический анализ кода, юнит тесты". Если начнут звонить и говорить, что не работает, - значит не работает, посмотрим тогда.
"релизы, сроки". Можем сделать эту задачу дня за три. Или пять. А может и две недели понадобится. Точнее не сказать никак. А, вот, позвонили пиарщики, сказали срочно сделать. А еще я хотел вздремнуть на рабочем месте и новую серию любимого сериала посмотреть. А вот эта задача вроде сделана, прямо сейчас на продакшн залью.

Так бывает. Почему-то мне кажется, что подобного не меньше половины. И зачем им тестировщик, понимают в таких компаниях далеко не все.
w_bf
May. 24th, 2011 04:01 am (UTC)
Конечно, так бывает. И нужен тут не тетировщик, а цыгане и кардебалет. Для комплекта.

Впрочем, это может нравится, на вкус и цыет, как известно...
( 2 comments — Leave a comment )

Latest Month

April 2015
S M T W T F S
   1234
567891011
12131415161718
19202122232425
2627282930  

Tags

Page Summary

Powered by LiveJournal.com
Designed by Lilia Ahner