Стандартные атрибуты чек-листа
В целом чек-лист должен обладать следующими атрибутами:
| Название | В названии отражается раздел или область в ПО, для которого сделаны проверке, например «Регистрация пользователя». |
| Наименование проверки | Краткое описание сутипроверки. Должно помещаться в твиттер и быть понятным! Кратко, но емко |
| Ожидаемый результат | Сама проверка: что мы ожидаем получить. В некоторых видах чек-листов он не используется. |
| Результат | Результат проверки, прошла или нет. |
Тем не менее, четких требований к оформлению чек-листов нет. Зачастую чек-листы создают в обычных excel- файлах, разделяю листы на разные области функциональности.
Подходы к использованию чек-листов
Рассмотрим разные подходы к использованию чек-листов на примере блокнота (Notepad).
Структуризатор
В этом варианте просто выписываем основные операции, производимые продуктом. Для удобства, группируем их (плюсики/минусики слева раскрывают строки). В столбце "результат" указывается либо результат, либо текстовые комментарии, либо ссылки на найденные дефекты.
Преимущества такого чек-листа:
● Малое время создания (пример - 3 минуты);
● Структуризация информации. ГРАМОТНЫЙ тестировщик произведёт все наиболее важные проверки, а информацию по найденным дефектам занесёт в чек-лист. В результате, статус продукта будет более наглядным и более структурным;
|
|
|
● При регулярном проведении нюансы реализации тестов могут меняться, таким образом будет расширяться покрытие.
Недостатки такого чек-листа:
● Нет гарантий, что проверено всё, что нужно, т.к. в чек-листе слишком общие слова, и проверки могут быть некорректными (дефекты известны, а что именно проверено - нет);
● Не подходит для использования новичком в команде (нет информации "как тестировать");
● Не оптимизирован набор (неопытный тестировщик для покрытия обобщённого чек-листа потратит в несколько раз больше времени, чем если предварительно оптимизировать набор при помощи техник тест-дизайна);
● Не указаны факторы, влияющие на проведение тестов, в результате многое может быть забыто.
Вывод: удобно для использования в гибких условиях И в команде с опытными тестерами-джедаями И в небольшом проекте для структуризации информации о статусе продукта.
Незабыватор
Этот чек-лист основан на предыдущем, но глубже по уровню детализации. Его основная задача - перечислить все необходимые проверки, чтобы они не были забыты. Для удобства организуется в виде структуры с неограниченным уровнем вложенности. Для удобства стилями можно выделять негативные и позитивные проверки, статусы, приоритеты и т.д. Лёгкая визуализация результата - залог эффективности использования.
|
|
|
Приведённый ниже чек-лист лишь пример и не претендует на полноту тестирования блокнота, для примера заполнено только "Создание файла".
Преимущества такого чек-листа:
● Не большое время создания (пример - 7 минут);
● Структуризация информации;
● Больше информации о статусе (точнее видно в чём проблемы);
● Гарантия проверки основных влияющих параметров, опций, функционала (достаточность перечисленных в чек-листе проверок может быть предварительно согласована).
Недостатки такого чек-листа:
● Не подходит для использования новичком в команде (нет информации "как тестировать");
● Не оптимизирован набор (высокий риск потратить слишком много времени).
Вывод: удобно для использования в опытной команде при отсутствии времени на продуманный тест-дизайн. Подходит как для структуризации информации, так и для обеспечения того, чтобы ключевые тесты не будут пропущены.
Тесткейсозаменитель
В этом варианте вместо общих данных (ЧТО должно быть проверено) указывается конкретный набор параметров. Таким образом, этот чек-лист может быть не просто результатом перечисления каких-либо факторов, но результатом продуманного тест-анализа
|
|
|
Заполнены примеры только для "Создание файла". Преимущества такого чек-листа:
● Существенная оптимизация затрат на прохождение при грамотном тест-дизайне;
● Гарантированный уровень покрытия (известно, ЧТО ИМЕННО будет проверяться);
● Может использоваться неопытными сотрудниками;
● В создании и поддержке занимает меньше времени, чем тест-кейсы;
● Можно оговорить значения "по умолчанию", чтобы не указывать все каждый раз, но тем не менее точно знать что проверялось;
● Последовательности выполнения можно определить с учётом приоритетов, таким образом, чтобы в первую очередь проверялись наиболее критичные проверки.
Недостатки такого чек-листа:
● Затраты на создание выше "маленьких" чек-листов;
● "Эффект пестицида" (покрываются тестами одни и те же участки функционала, в то время как дефекты могут быть поблизости);
● Повышенные требования к квалификации в тест-дизайне;
Вывод: используется при тестировании стабильных продуктов и относительно высоких требованиях к качеству ПО.
|
|
|
Статусопоказатель
Этот чек-лист основан на любом из предыдущих (зависит от требуемого уровня детализации), и его дополнительная задача - показать статус продукта и динамику изменений.
Преимущества такого чек-листа:
● Структуризация информации, качество проверок в соответствии с уровнем детализации;
● Видны изменения в динамике продукта (больше/меньше дефектов);
● Видны области с переоткрываемыми дефектами (тот же номер после ok);
● Видны области где часто появляются различные ошибки;
● Возможен анализ информации о новых дефектах (почему не были найдены, когда были внесены).
Вывод: удобно для сохранения информации и принятия управленческих решений как в тестировании, так и в разработке.
На таком чек-листе видно состояние ПО с течением времени. Видно, что в новых итерациях появляются новые баги. Видно возникновение новых проблем, при долгосрочном использовании можно говорить что область рискованная.
Окруженияучитыватель
Этот чек-лист основан на любом из предыдущих (зависит от требуемого уровня детализации), и его дополнительная задача - показать работу продукта на разных платформах, окружениях и т.д..
Преимущества такого чек-листа:
● Структуризация информации, качество проверок в соответствии с уровнем детализации;
● Легко отличимы дефекты, вызванные окружением;
● Можно удобно получить статус работы на конкретном окружении, можно получить общее видение по поддержке окружений;
● Видны окружения где часто появляются различные ошибки.
Недостаток такого чек-листа в том, что не всегда возможно проводить полный тестовый набор на ВСЕХ окружениях, и информация может быть неполной.
Вывод: удобно для и тестирование платформозависимого ПО.
Можно увидеть платформозависимые баги или наиболее стабильную платформу.
Дата добавления: 2018-08-06; просмотров: 4248; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!