Home

Автор: Сергей Бережной

В последнее время меня постигло огромное разочарование. И как ни страшно подумать, пришло оно со стороны, с которой меньше всего ожидал – со стороны тестировщиков. Да, именно тех людей, которых я считаю одними из самых важных и ключевых в проекте.

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

«Человек не будет переживать за качество всего проекта. Он не встанет и не скажет, что проект не готов к выходу, даже если давление (в том числе и с моей стороны) будет высоко».

С моей стороны показалось странным, почему он (опытный руководитель проектов) обращает внимание именно на это, а не на профессиональные знания и опыт. Неужели читал Спольского про «smart and get things done»? Такая тема не могла быть не обсуждена дополнительно! И мы решили обсудить, какие же проблемы кроме этой Заказчик видит в нашем тестировании.

Получился вот такой список главных разочарований в тестировании со стороны Заказчика:

1. Нет ощущения, что продукт «мой».

Часто в аутсорсинге люди не воспринимают проект как что-то свое и считают, что «выполнив набор acceptance тест-кейсов» они сделают проект. А воспринимая проект как «один из многих», резко снижается концентрация и способность тестировщика находить дефекты.

Еще одним признаком такой проблемы является тот факт, что люди не хотят разбираться, что же на самом деле делает проект и почему та или иная функция работает именно так. Не воспринимая это всерьез, тестировщик не может вынести вердикт: функция работает правильно или нет.

(отступление) Знаю по себе, как относишься к багам «каких-то» продуктов или своего блога. Баги блога стараюсь фиксить быстро, чтобы моим пользователям было удобно! Если лежит хостинг – звоню и донимаю саппорт с целью «исправить и поднять». А если бы это был не мой продукт, то вполне возможно, что разрешил бы ему «полежать до завтра».

2. Нет понимания «достаточного» качества продукта.

На этом вопросе «плывут» многие из наших ребят во время собеседований (особенно синьор и лид уровней). Каждый проект имеет нужный (необходимый и достаточный) уровень качества. Именно по этому критерию тестировщик способен вынести решение: «Готов ли продукт к выпуску или нет». И эти критерии являются главным адвокатом тестировщика. Заказчик и я были очень удивлены, что многие тестировщики уверены, что функцию выяснения «достаточного» уровня качества выполняет ПМ или Заказчик. Точно также решение о соответствии этому уровню качества (и релизу) принимает Заказчик.

3. Низкий порог входа в специальность и слабая конкуренция

Посмотрите вокруг и увидите, что тестирование – специальность, с которой многие люди начинают свою карьеру в ИТ. На самом деле порог входа самый низкий, так как прочитав книжку Канера и разобравшись хотя бы с одним баг-треккером можно претендовать на позицию Junior Tester. А что самое парадоксальное, есть люди, которые работают несколько лет, так и не прочитав ни одной книги по тестированию.

Такой низкий порог позволяет людям, которые хоть что-то знают быстро расти и получается, что человек, который протестировал за всю карьеру 2-3 приложения (используя функциональное, регрессионное и UI тестирование) может стать Лидом. То есть не нужно особо напрягаться, чтобы вырасти карьерно. И почти никто не напрягается!

Вопрос от заказчика поставил меня в тупик: Как он (кандидат) может претендовать на лидскую роль, если не может толком объяснить что такое тест-дизайн? Как я могу доверить финальное решение о выпуске продукта такому человеку?

Правда, похоже на Индию?

4. Слабое понимание принципов построения программного обеспечения.

Этот пункт стал самым спорным. Никто не спорит, что тестировщику желательно это знать. Но почему Заказчик сделал упор именно на этом пункте?

На самом деле ответ прост: В основном onshore тестировщики (в силу молодости профессии) пришли или из программистов, или из аналитиков. И те, и другие классно знают основы дизайна систем. Поэтому они способны писать Unit tests и критически смотреть на дизайн компонентов системы и искать баги на этом уровне. В наших же реалиях люди с трудом (извините, пожалуйста, если написал про вас неправду) могут сказать какие компоненты системы и как взаимодействуют (хотя бы как работает http протокол).

Какие выводы можно сделать из беседы и из личного опыта:

Мы пока сильно не попадаем в «западное» понятие хорошего тестировщика. Их тестировщики – это люди, которые знают больше как в теории и практике тестирования, так и в программировании.

Дабы предотвратить ненужные комментарии, еще раз хочу сказать о том, что очень уважаю наших тестировщиков. Как говорит Слава Панкратов: «Тестирование - наше все». Я написал пост не с целью порицания, а с целью дальнейшего развития. Да, и я лично знаю нескольких тестировщиков, которые прекрасно справляются с вышеописанными проблемами, так что это вполне достижимо .

P.S. Читая статью многие подумают, что я пишу о каких-то неудачниках, которые по странному стечению обстоятельств попались мне на собеседование. Я бы тоже очень хотел так думать. Но при выборе резюме почти все кандидаты имели как минимум 4 года опыта.

P.S.S. Огромное спасибо тем ребятам, в основном из команды Paceart, которые помогли мне понять, что такое настоящие толковые тестировщики и научили меня правильным критериям оценки.

Автор статьи:

Сергей Бережной – руководитель проектов-программ в оффшорной разработке, автор блога http://anotherpm.com, в котором рассказывает об работе с Заказчиками в аутсорсинге. Много интересных материалов как на страницах блога, так и в бесплатной закрытой группе.

В дополнение к блогу часто выступает на профильных ИТ конференциях и проводит тренинги по работе с Заказчиками в ИТ.

Обсудить в форуме