Инструменты пользователя

Инструменты сайта


only_one

Что делать, если вы первый и единственный тестировщик-джун на проекте

В 2005, когда я начинал свой путь в тестировании, было не так много людей, которые работали в тестировании, а уж опытных «зубров» в русскоязычном интернете можно было пересчитать по пальцам. Тем не менее, количество IT-компаний стремительно росло, процессы становились все лучше, разработчиков - больше, продукты - сложнее, и вслед за разработчиками возникла потребность и в тестировщиках. Как такового обучения тестировщиков тогда практически не было: книги, статьи, форумы, блоги, конференция SQADays. Наверняка тогда уже были курсы от software-testing.ru, но и только, такого обилия онлайн-школ точно не было. В общем, основными способами профессионального роста были самообразование и эксперименты. Таким образом, на рынке была нехватка специалистов по тестированию, с одной стороны, и отсутствие обучения - с другой. Компании не унывали - тем более, что в процессах все равно был еще бардак - и нанимали в качестве первого и единственного тестировщика просто способных людей: с знаниями в IT, процессах разработки, со стремлением развиваться, но, естественно, без какого-либо опыта в тестировании. Зачастую это были даже студенты с «программистских» и различных «околопрограммистских» специальностей, работающие по полдня. Эти студенты читали книги и статьи, ставили эксперименты над продуктами, проектами, процессами и иногда даже людьми :) Результат получался разный, было много крутых улучшений и много эпичных провалов, но в общем и целом прогресс шел.

Сейчас 2021, прошло целых 16 лет, за это время я несколько выпал из процесса постановки тестирования с нуля, поработал с теми процессами, которые я когда-то сам ставил, работал в «кровавом энтерпрайзе» по совершенно разным методологиям, от «как попало» до V-модели и разного agile-а. И мне казалось, что уж сейчас-то все хорошо, и что даже в новых компаниях организуют отделы тестирования и ставят процессы люди с сединой, полученной еще бессонными ночами в конце нулевых. Есть огромное количество курсов. Если какое-то невообразимое количество тестировщиков в России с опытом в десяток лет. У этих людей есть опыт, знания, набитые шишки. Но общение в тестерских кругах показывает, что все еще сохраняется паттерн «единственный тестировщик-джун на проекте», и это меня печалит. Ранее этот процесс происходил об безысходности: тестировщиков с опытом попросту не было, а сейчас это скорее от жадности нанимателя и общего непонимания того, как же он, процесс разработки ПО, вообще устроен.

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

Итак, первый рабочий день, новый проект, ничего не понятно кто все эти люди. И да, первый и главный вопрос действительно кто все эти люди. Тебе нужно познакомиться с командой, узнать, кто за что отвечает и какие обязанности выполняет. От этого очень сильно будет зависеть твоя эффективность работы в первое время (да впрочем, и не только в первое). Проблема в том, что в небольших проектах на ранней стадии информация о продукте обычно хранится в головах отдельных людей, их электронной почте и в чатах, а какое-то централизованное хранилище требований зачастую отсутствует либо информация в нем была актуальной полгода назад.

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

  • Google Docs или аналоги - самый простой вариант
  • Notion или другие wiki-системы
  • Внутренние бесплатные wiki-системы - MediaWiki, DokuWiki
  • Корпоративные системы для хранения информации вроде Confluence

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

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

only_one.txt · Последнее изменение: 2021/03/30 04:53 — admin