Главная » Статьи » База знаний » Релиз-менеджмент или подготовка проекта к запуску

Релиз-менеджмент или подготовка проекта к запуску

Релиз-менеджмент — это подготовка проекта к состоянию, когда на него можно запускать реальных пользователей.
 
Мы будем говорить о ручном тестировании. Он дешевле для небольших проектов. Чтобы проводить тестирование, тестировщику необходимо на что-то опираться.
 
Это могут быть чек-листы (критерии проверки готовности задач), утвержденные результаты предыдущих этапов (ТЗ, прототипы, бэк-логи), здравый смысл.
 
Проверка макетов
 
На этом этапе мы сверяем макеты с перечнем функций, которые запланированы к реализации.
 
Такая проверка необходима не всегда, лишь в небольших проектах, где их сильно больше дюжины. Наша задача — убедиться, что дизайнер в творческом порыве не придумал лишних новых функций, и в угоду красоте или по неосторожности не забыл какие-то элементы страницы (или даже целые экраны).
 
Если дизайнер получает ТЗ в письменном виде, рекомендуем проверять законченную работу методом светофора.
 
Красный цвет — сделано с ошибками.
Желтый цвет — есть незначительные расхождения.
Зеленый цвет — все в порядке.
Серый цвет — есть вода.
Белый цвет будет означать, что тестировщик это место еще не проверял.
 
Красить нужно не абзацами, а слово за словом. Бывает, что разница в нескольких буквах кардинально меняет смысл задачи (к примеру, “и” прочитают как “или”).
 
Тестирование верстки
 
Переводим картинки в интерактивный HTML.
 
В этом нам может помочь инструмент, который прямо в браузере сможет сравнить макет и готовую работу и показать расхождения.
 
Одним из таких инструментов является плагин для браузера PerfectPixel.

тестирование верстки

Загружаете макеты, выставляете прозрачность и сопоставляете макеты с версткой.
 
Обратите внимание, что “Пиксель в пиксель” не равно “Здравый смысл”.
Представим, что для повышения скорости, над несколькими макетами работали разные дизайнеры.
 
По некоторым макетам могли быть доработки, некоторые приняты с первого раза. В таком случае, вероятность того, что макеты будут одинаковыми крайне мала. Так что добавление людей в опаздывающий проект скорее всего его только затянет.
 
Чтобы избежать таких результатов, используйте общий гайдлайн, который иллюстрирует основные элементы и отступы. Теперь не требуйте верстки “Пиксель в пиксель”. Но если отступ от заголовка в гайдлайне = 20 пикселям, он должен быть таким во всех аналогичных местах.
 
Теперь даже если в одном месте отступ = 18 пикселям, а в другом = 21 пикселю, тестировщик должен отметить это ссылаясь на гайдлайн, а разработчик — исправить. В случае спора, финальное решение принимает менеджер.
 
Что еще важно проверить — валидность кода, загрузка на медленном канале и адаптив. Повторно проверяем, когда проект собран.
 

Тестирование разработки
 
На этом этапе собираются все недоработки и мелочи с предыдущих этапов. Часто поэтому на программистов ложиться вся вина за недоработки, в том числе невнимательность самого менеджера.
 
Тестирование проекта закладывается еще на этапе планирования.
Если идет работа по SCRUM, то имеет смысл привлекать тестировщика к планированию спринта. Это активность, когда вся команда собирается вместе, зачитываются и обсуждаются вслух постановки по задачам, которые пойдут в работу.
 
Тестировщик наравне со всеми участниками принимает участие в планировании и оценке, слушает обсуждение задач, понимает детали. Так у всех будет общее понимание задач и необходимых результатов + тестировщик получит навыки оценки и декомпозиции задач. Эти навыки помогут ему в дальнейшем стать менеджером.
 
После планирования пишем тест-кейсы к задачам. Это критерии, по которым разработчик будет проверять готовность задачи. После выполнения каждого элемента разработчик будет проверять по чек-листу корректность своей работы.
 
Тест-кейсы пишет тестировщик и разработчик (как правило, более опытный). Большая часть тест-кейсов пишется на основе полного чек-листа проверки проектов.
 
Чек-лист общий и не учитывает контекст, поэтому в тест-кейсах необходимо прописать именно те пункты, которые применимы к решению конкретной задачи.
 
Тест-кейсы пишутся таким составом (тестировщик + разработчик), чтобы сэкономить время в будущем. Если тестировщик пишет тест-кейсы в одиночестве, он может придумать то, чего вообще не было в задаче, или наоборот — не указать что-то важное.
 
Менеджер в подготовке тест-кейсов участвует только в случае, если возникают вопросы, требующие его решения.


(голосов: 3)
Загрузка...