Представьте классический проект в котором есть только огрызки документации. Ранее тестирование проводили аналитики, а вы первый тестировщик, да еще без особого практического опыта. Ошибки на бою могут доходить до миллионных штрафов, вплоть до отзыва лицензии на деятельность.
Думаю, по ощущениям это похоже на пилотаж болида Формулы-1 без подготовки.
Коллеги, доброе утро. На этой неделе заканчиваем работу по доработкам swift-rur. На следующей готовим отчётность по нерезидентам. Также нас ждут изменения по санкционным спискам. И еще по дороге мы решили взять под крыло один банк — мигрировать базу будем на новогодние. Нужно обеспечить контроль.
Кстати, сегодня к нам пришел тестировщик...
Что имеем по прибытию?
Вместо обучения мне досталась задача на проверку целого модуля. Аналитик написал инструкцию по воспроизведению на почту, приложил доку в ворде и пошел в отпуск.
Это было недели две ада. Одна проверка могла длиться до 4х часов. А в конце она падала. И непонятно — то ли я не очень, то ли оно не работает. В перерывах я готовила данные, изучала материалы, а в моменты отчаяния звонила аналитику в отпуске и периодически заглядывала проверить результаты в ночи.
Не повторяйте такое погружение у себя на проекте. Вы рискуете тем, что человек либо не справится и найдет миллион оправданий почему работа сделана плохо/не сделана, либо с такими процессами он просто сгорит.
Ну, а мне за старания досталась задача на другой модуль, который забросили еще в прошлом году. Только на изучение требований и уточнения работы ушло часов 60. В процессе я узнала, что в 7м файле 5й разработки есть дополнения. Была еще проблема с неучтенным влиянием на смежный функционал. А потом разработчик уволился.
Как из этого выбираться? Коротко
Согласовывать чек-листы с проверками
Планомерно создать пошаговые кейсы на базовый функционал
Использовать эти кейсы для обучения коллег
Записать серии видео-уроков для новых сотрудников
Поддерживать актуальность регрессионной модели
Планировать задачи в релиз заранее
Обязательно декомпозировать большое на части
Проводить не только планерки, но и ретро
Собрать документацию на ресурсах общего доступа
Внедрить тестирование требований
Автоматизировать регресс
Организовать uat-тестирование
Что нас ждало на практике? За что мы взялись в начале?
Я начала с составления пошаговых кейсов на весь функционал с которым мне приходилось сталкиваться. Бывало, что где-то в запаре детали воспроизведения шли к черту. Предусловия? Запомню, ага.
Наивнее того, что с нашей нагрузкой и разнообразием задач я смогу воспроизвести это спустя хотя бы месяц придумать сложно... Важное пришлось переделать. Остальное похоронили как есть.
Даже если вы думаете, что никто во веки вечные не увидит ваши кейсы — соблюдайте правила их создания. Хотя бы для себя. А если напарник все-таки будет, то вы сможете использовать нажитое добро для обучения. Больше воспроизводимых кейсов — меньше дергают по пустякам.
Но что если у вас появится второй напарник, а потом третий?
Тут мне стало ясно как глупо было не записывать видео-уроки с самого первого дня. Пришлось повторить одно и тоже трижды до того как я внедрила обязательную запись на часто задаваемые вопросы при погружении.
Думаете масштабироваться? Создавайте базу для обучения и легкого получения необходимых доступов. При возможности делегируйте административные вопросы отдельному специалисту.
К слову, через наш отдел в том году прошло человек 8. Мы уже отточили процесс адаптации и это отдельная история на миллион, но в кратком обзоре нас уже ждет проблема самого найма.
К этому рабочему снаряду можно подходить по-разному, но я вижу огромные плюсы участия в собеседованиях специалистов, знающих особенности проекта. Так, с большей вероятностью вы наймете тех, кого нужно. И перестанете тратить ресурсы отдела на обучение впустую.
Не сложно догадаться, что на собеседования я начала звать себя. Позже подключила ребят, которые имеют достаточно опыта. Оказалось, два специалиста с разными скиллами сильно лучше, чем один.
Только не зовите на собеседования всю команду, ей богу. Один человек с развитыми хард скиллами, второй с софт. И еще, по возможности продумайте заранее как будете мотивировать коллег на сотрудничество по факту их роста.
Не забывайте, после того как вы избавитесь от необходимости зарезать людей на испытательном сроке, можно столкнуться с тем, что вам нечего предложить талантливым специалистам позднее.
А что там по тестированию, кроме организации?
Поднятие регрессионной модели с нуля. Сейчас мы смочим базовый функционал в релизном цикле на регулярной основе и находимся на стадии автоматизации проверок. Еще чуть-чуть и вырастем до присоединения отдельной регрессионной команды.
Проведение и поддержка регресса — это отдельная активность, которая требует постоянного внимания. Но она дает отличные результаты, вроде уменьшения инцидентов на бою.
Не меньше сил мы вложили в описание модулей на ресурсах общего доступа. Зато!
Документация на ресурсах общего доступа не только оберегает проект от фактора автобуса, но и позволяет выработать внутренний регламент тестирования документации. А значит вы сможете внедрить эту активность не по форме, а по содержанию.
Мы прошли этот путь за 1,5 года. У нас были свои победы и поражения. Но главное, террористы остались без сладкого на Новый год.
