Как выглядит хороший чек лист qa engineer excel
Вы тестировщик без опыта или с минимальным опытом, либо не имеете опыта выстраивая процесса тестирования с нуля.
Имеем проект, на котором нет и не было тестирования / тестирование неэффективно организовано, есть проблемы.
Проверяем по чек-листу:
1. Наличие таск-трекера, баг-трекера . Обязательно на проекте должна быть единая система, куда заводятся все задачи, баги, стори, постановки, проблемы.
2. Документация . Ищем любые сведения о продукте и проекте. Если нет, по по-тихоньку начинаем структурировать всю информацию в одном месте и заодно приучаем всю команду к процессу ведения документации.
В первую очередь в документации хранится информации о тестовых стендах, доступам к ним, стендах для разработки. Может быть стенд для аналитиков, пред-прод. Как правило, адрес продуктового стенда тоже может быть и, возможно, будет доступ на него под тестовыми учетками.
Во вторую очередь в документации содержатся информация о заинтересованных и ответственных лицах в команде. Краткие цели, задачи и описание проекта (что, для кого и зачем)
На третьем месте в документации стоит ТЗ, постановки, описание функций проекта.
На четвертом месте в документации идет описание различных инструкций (как развернуть стенд, БД, настроить доступы, описание специфических моментов, логины и пароли для всего самого необходимого)
На пятом месте в документации идет описание пользовательских сценариев, тестовых сценариев, тестовые данные. Это одно из самых важных для тестирования.
Документацию должны вести все:
- Это, кстати, касается разработчиков тоже (пример, написал АПИ - задокументрий запросы, сформировал новую БД - кратко опиши структуру, сделал процесс поставки билда - напиши инструкцию, написал новый сервис - напиши доступы и его адрес).
- Аналитики - должны фиксировать всю информацию от заказчика, писать постановки про функционал, роли и группы в системе, цели и задачи продукта, пользовательские сценарии и альтернативные последовательности действий в продукте.
- Тестировщики - должны писать тест-кейсы / чек-листы. Храните их в общедоступном месте для всей команды. Если возникают вопросы по функционалу, делайте отсылку для команды к своим проверкам.
3. С системой управления проектами разобрались, документацию нашли/организовали . Дальше - выбираем систему управления тестами. Она зависит от бюджета, выделяемого на проект. Если руководство выделит такую возможность, как платная система управления тестами - то отлично.
Если нет возможности для приобретения платной версии системы управления тестами, то всегда можно воспользоваться бесплатными подручными средствами (гугл-документы, word/excel, таск-трекер, используемый на проекте и т.п.).
Популярные системы управления тестированием:
4. Итак, с орг.моментами разобрались. Начинаем выстраивать процессы тестирования.
Узнаем, какой на проекте воркфлоу:
- Как команде поступают задачи на аналитику, разработку, тестирование?
- Как происходит смена статусов задач?
- Какой жизненный цикл у багов?
- Есть ли стандарты оформления задач, багов?
- Когда задача считается выполненной?
- Есть ли код-ревью на проекте?
- Общается ли команда с заказчиком/клиентом? Какое участие он принимает в процессе разработки?
Обычно стандартный ворклоу проекта выглядит следующим образом (говорю про agile-методологии).
Этап 1. Проводится аналитика и дизайн пожеланий заказчика, которая переводится на язык разработки и описывается в виде задач или стори для команды разработки.
Этап 2. Заказчик согласовывает, либо вносит правки в полученное техническое задание.
Этап 3. Далее разработчик на основе сформированных задач пишет код. Тем временем тестировщик на основе задач проводит тестирование требований, оформляет дефекты по документации на аналитика. Также тестировщик пишет тесты (тест-кейсы или чек-листы) и подготавливает тестовые данные для проверок. Выбирает типы, виды и методы тестирования (это зависит от исходных требований и конечной реализации).
Этап 4. Разработчик закоммитил код и отправил его на код-ревью (в маленьких командах этот этап может быть пропущен). После чего задача переводится в статус "Готова к тестированию".
Этап 5. Тестировщик берет задачу в работу - переводит в статус "Тестирование", проводит испытания по заранее подготовленным тестам и оформляет дефекты. Тестировщик (либо по согласованию с командой) определяет приоритет и критичность дефектов.
Этап 6. Дефекты назначаются на разработчика, производится фиксы, которые после коммитов отдаются на повторное тестирование.
Этап 7. Как только все запланированные в данной итерации задачи и баги протестированы и закрыты, тестировщики проводят регрессионное тестирование и формируют отчет о тестировании. Команда принимает решение о качестве продукта и демонстрации заказчику.
Далее новая итерации с шага 1 или 3 (по готовки постановок), либо финальная сдача проекта.
5. С процессами разработки и воркфлоу разобрались . Дальше поговорим о том, что должен сделать тестировщик для выстраивания процессов тестирования на проекте?
5.1. Внедрить тестирование на всех этапах разработки. Начинаем тестировать требования, искать ошибки и неточности, двойной смысл и противоречия. Проверяем требования на "характеристики" требований (корректность, атомарность, полнота, однозначность, непротиворечение, поддаваемость проверки, понимаемость, модифицируемость, и т.д.)
5.2. Внедрить тестирование в процесс разработки. Любой написанный код должен быть протестирован.
5.3. Внедрить практику оформления дефектов. Внедрить стандарт оформления дефектов. Обязательно дефект должен содержать название, описание шагов, ожидаемый/фактический результат, скрин ошибки, стенд, где был обнаружен дефект, под каким пользователем был обнаружен дефект - это основные категории дефекта.
5.4. Написать тесты / чек-листы для Smoke и Регрессионного тестирования. Вовремя обновлять все тесты. Хранить всех тестовых пользователей и тестовые данные в одном, доступном для всей команды месте.
5.5. Определить, какие виды тестирования применимы для Вашего проекта. Требуется ли кросс-браузерное тестирование? Какие платформы задействуются пользователем? Вся информация о проекте поможет выбрать тестовую стратегрию проекта.
5.6. Тестировать! Заводить баги, отслеживать их исполнение и вовремя ре-тестить. Следить за "повторяющимися" багами (пофиксили - проверили - через время снова всплыл).
5.7. Изучать область Вашего проекта, предлагать улучшения в функционале, которые помогли бы пользователю интуитивнее пользоваться приложением.
5.8. Собирать обратную связь от команды. Спрашивать напрямую, чего не хватает в тестировании? Может Вы слишком задалбываете команду вопросами? Или мало общаетесь с разработчиками?
Совет : хороших тестировщиков любят и ценят! Как правило, именно тестер разрабирается максимально хорошо и точно в проекте и знает все и обо всем. Поэтому разработчики очень часто советуются, как лучше сделать, какие условия правильно отрабывают или нет.
1. Введения баг - трекинговой системы (если нет). Если есть, то настроить под себя
2. Сбор всей документации в одном месте, заставляем обновлять и вести базу знаний всем
3. Выбрать способ хранения тестов
4. Выбрать методы тестирование
5. Написать тест стратегию
6. Выстроить процесс воркфлоу
7. Обязательно определиться: что тестируем, где тестируем, как тестируем
Также предлагаю список публикаций о тестировании и IT на моем канале:
Основы компьютерных сетей
Методологии разработки и жизненный цикл ПО
- Техники: Техники тест дизайна (Test Design Technics), Практическое применение техник тест дизайна при разработке тест кейсов, Немного о простом. Тест-дизайн. Часть 1
- : Класс эквивалентности «Ноль-не ноль», Классы эквивалентности для строки, которая обозначает число, Классы эквивалентности для строки, которая обозначает дату, Тестирование текстового поля, Тестирование полей ввода, Тестируем поля логин/пароль, Классы эквивалентности для населенных пунктов в адресах
- : Расширяем тестирование граничных значений, Как найти границы на клиенте и сервере
- :Таблица принятия решений, Таблицы решений и их применение в тестировании, О “Decision Table” простыми словами, Таблицы принятия решений: техника проведения тестирования с использованием Functional Tester от IBM Rational, Тестирование таблицы решений
- : Предугадывание ошибки как техника тест-дизайна
- :Тестирование на основе диаграмм состояний сущности, Тестирование таблицы переходов состояний, Тест-дизайн. Таблица состояний и переходов (часть 1), Таблица состояний и переходов (часть 2)
- : Метод попарного тестирования, Что такое Pairwise Testing, и с чем его едят, Метод попарного тестирования, История одного pairwise или как заменить мозги Гуглом и проиграть, Открытый вебинар «Метод Pairwise Testing в Black Box тестировании», Попарное тестирование (Pairwise testing)
- : Исследовательское тестирование: когда его стоит применять и как это делать, Введение в исследовательское тестирование, Туры в исследовательском тестировании, Создание плана исследовательского тестирования: картография ПО, Переводы туров для исследовательского тестирования
- : Ad-hoc testing, Что такое ad-hoc тестирование?
Тестирование мобильных приложений
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Кто-то в процессе своей трудовой деятельности составляет чек-листы, а кто-то этим не занимается и пишет только тест-кейсы. Я считаю, что чек-лист и тест-кейсы неотделимы по своей сути. Сюда же можно добавить и интеллектуальную (функциональную) карту приложений. Поясню почему они неотделимы, а потом перейдём непосредственно к чек-листам.
О принципах правильного написания тест-кейсов и создания карт приложений я рассказывал в отдельных статьях, ссылки на которые приведу в конце данной статьи.
Какая взаимосвязь существует между тремя озвученными сущностями? Когда я обучаю специалистов по тестированию, то обучение мы начинаем с карт приложения. Картами мы охватываем весь возможный функционал программы. После того как карта полностью создана мы на основании конечных проверок, зафиксированных на карте, создаём чек-лист. Создав чек-лист, мы начинаем создание тест-кейсов.
Для чего мы так делаем? Для того чтобы не упустить какой-либо функциональный блок программы при создании тест-кейсов. По опыту знаю, что когда пишешь тест-кейсы и нет ни карты приложения, ни чек-листа, то после пятидесяти или сотни написанных тест-кейсов становится трудно удерживать в голове информацию, что описано тест-кейсами, а что ещё надо описать тест-кейсами, а впереди ещё надо написать несколько тысяч тест-кейсов. В этом случае чек-листы нам помогают и нам не надо в голове держать большие объёмы информации по тому, что мы описали тест-кейсами, а что ещё надо описать.
Поэтому примите на вооружение правило написания тест-кейсов:
- Создаём карту приложения или функционального блока приложения.
- Создаём чек-лист опираясь на карту приложения.
- Создаём тест-кейсы опираясь на чек-лист.
Теперь рассмотрим, как правильно составлять чек-лист на основании карты приложения. Сейчас мы не будем рассматривать создание чек-листов без карт приложений, так как это делается аналогично, только не используются карты приложений и в таком случае можно часть функционала приложения забыть зафиксировать в чек-листе.
Для начала у нас должна быть составлена карта приложения:
На карте приложения у нас имеются конечные проверки, обозначенные галочками в зелёных кружочках. Эти проверки мы и будем переносить в чек-лист.
Чек-лист
- Проверка работы кнопки «Свернуть приложение».
- Проверка работы кнопки «Развернуть приложение».
- Проверка работы кнопки «Закрыть приложение».
Раздел «Содержимое окна»:
- Проверка ввода текста в поле ввода текста (числа, буквы, спецсимволы).
- Проверка работы вертикального скролла (полосы прокрутки).
Раздел «Строка меню» мы не вносили в чек-лист так как карта приложения в данном разделе ещё не завершена и нет конечных проверок. Когда карта приложения будет завершена, тогда и внесём в чек-лист проверки из данного раздела.
Если внимательно присмотреться в чек-лист и глянуть на функционал программы, то мы увидим, что после того, как программа сворачивается она скрывает свою форму и отображается на панели задач операционной системы, а значит нам надо проверить, что программа может разворачиваться из панели задач и снова отображать свою форму. Для этого мы вносим в чек-лист дополнительную проверку:
- Проверка работы кнопки «Свернуть приложение».
- Проверка работы функционала разворачивания приложения из панели задач.
- Проверка работы кнопки «Развернуть приложение».
- Проверка работы кнопки «Закрыть приложение».
У нас получился следующий чек-лист:
Принцип создания понятен. Важно всегда помнить, что одна конечная проверка из карты приложения, может разделиться на несколько проверок в чек-листе, т.е. в чек-листе будет больше проверок.
Приведём пример. В карте приложения имеется конечная проверка:
Мы знаем, что в личный кабинет на сайте мы можем войти несколькими способами, поэтому все эти способы должны быть зафиксированы в чек-листе:
- Проверка входа в личный кабинет на сайте с помощью логина;
- Проверка входа в личный кабинет на сайте с помощью email;
- Проверка входа в личный кабинет на сайте с помощью номера телефона;
- Проверка входа в личный кабинет на сайте с помощью сертификата.
Как видите из одного пункта проверки карты приложения у нас появилось четыре пункта в чек-листе. Эти проверки могли быть зафиксированы и в карте приложения, тогда у нас одна проверка из карты приложения перешла бы в одну проверку в чек-листе.
Имея полностью созданный чек-лист, мы можем дальше создавать тест-кейсы. Опытные тестировщики знающие хорошо функционал тестируемого приложения могут тестировать приложение по чек-листу без тест-кейсов. Тестировщикам плохо знающим функционал приложения тестировать по чек-листам будет затруднительно.
В видео рассказываю как создавать чек-лист:
О принципах правильного написания тест-кейсов я рассказывал в статье «Правильно пишем тест-кейсы». О создании карт приложений я рассказывал в статье «Облегчаем тестировщику жизнь при написании тест-кейсов». В статьях имеются подробные видеоматериалы по данным темам.
Если хотите научиться создавать карты приложений, чек-листы, тест-кейсы и узнать многое другое, то пройдите обучающий курс «Тестирование ПО. Начальный уровень».
Что пишут в блогах
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Перевод: Ольга Алифанова
Во время тестирования веб-приложения нужно обращать внимание на нижеперечисленные пункты. Этот чеклист применим практически к любому типу веб-приложений в зависимости от бизнес-требований.
Чек-лист для тестирования веб-приложений состоит из:
- Тестирования удобства использования.
- Функционального тестирования.
- Тестирования совместимости.
- Тестирования баз данных.
- Тестирования безопасности.
- Тестирования производительности.
Теперь давайте рассмотрим каждый пункт по отдельности.
Тестирование удобства использования
- Это не что иное, как тестирование дружелюбности приложения для пользователя.
- При тестировании удобства использования проверяется, легко ли новому пользователю разобраться в приложении.
- В целом при тестировании удобства использования тестируется системная навигация.
Какова цель этого тестирования?
Тест удобства использования удостоверяется в простоте и эффективности использования продукта при использовании стандартных практик тестирования удобства использования.
Сценарии тестирования удобства использования:
Функциональное тестирование
- Тестирование функциональностей и операционного поведения продукта с целью убедиться, что они соответствуют спецификациям.
- Тестирование, игнорирующее внутренние механизмы системы или компонента. Оно концентрируется исключительно на выходных данных, полученных в ответ на пользовательский ввод и условия исполнения сценариев.
Какова цель функционального тестирования?
Цель функционального тестирования – убедиться, что ваш продукт соответствует нужной функциональной спецификации, упомянутой в вашей документации по разработке.
Сценарии функционального тестирования:
Тестирование совместимости
- Тестирование совместимости используется, чтобы убедиться, что ваше приложение совместимо с другими элементами системы, в которой оно работает – например, браузерами, операционными системами или железом.
Какова цель тестирования совместимости?
- Цель тестирования совместимости – оценка того, насколько хорошо ПО работает в определенном браузере, под определенной ОС, с другим ПО или железом.
Сценарии тестирования совместимости:
- Протестируйте сайт в различных браузерах (IE, Firefox, Chrome, Safari, Opera) и убедитесь, что сайт правильно отображается.
- Убедитесь, что используемая версия HTML совместима с соответствующими версиями браузеров.
- Убедитесь, что картинки корректно отображаются в разных браузерах.
- Убедитесь, что шрифты верно отображаются в разных браузерах.
- Убедитесь, что Java Script код работает в разных браузерах.
- Проверьте анимированные GIF в разных браузерах.
Инструмент для тестирования совместимости
Тестирование баз данных
- При тестировании баз данных проверяются бэкэнд-записи, введенные через веб или десктоп-приложение. Данные, которые отображаются в приложении, должны совпадать с данными, хранящимися в базе данных.
Чтобы тестировать базы данных, тестировщик должен знать следующее:
- Тестировщик должен понимать функциональные требования, бизнес-логику, основной сценарий приложения и дизайн базы данных.
- Тестировщик должен разбираться в таблицах, триггерах, процедурах хранения, способах отображения и указателях, используемых для приложения.
- Тестировщик должен понимать логику триггеров, процедур хранения, способов отображения и указателей.
- Тестировщик должен понимать, какие таблицы затрагиваются, когда операции вставки, обновления и удаления выполняются в приложении.
Понимая вышеперечисленные пункты, тестировщик может легко написать сценарии для тестирования баз данных.
Сценарии тестирования баз данных:
- Проверьте название базы данных: оно должно совпадать со спецификацией.
- Проверьте таблицы, колонки, типы колонок и значения по умолчанию: все это должно совпадать со спецификацией.
- Проверьте, позволяет ли колонка значение null.
- Проверьте первичный и внешний ключ каждой таблицы.
- Проверьте процедуры хранения.
- Протестируйте, установлена ли процедура хранения.
- Проверьте название процедуры хранения.
- Проверьте названия параметров, их типы и количество.
- Проверьте, обязательны параметры или нет.
- Проверьте процедуру хранения, удалив некоторые параметры.
- Проверьте базу данных, если на выходе ноль – записи с нулем должны быть задействованы.
- Проверьте процедуру хранения, задав простые SQL-запросы.
- Убедитесь, что процедура возвращает значения.
- Проверьте процедуру вводом тестовых данных.
- Проверьте поведение каждого флага в таблице.
- Убедитесь, что данные правильно сохраняются в базе данных после каждого ввода.
- Проверьте данные при каждой операции обновления, удаления и вставки.
- Проверьте длину каждого поля. Длина на бэкэнде и фронтэнде должны совпадать.
- Проверьте названия баз данных QA, UAT и прода. Имена должны быть уникальными.
- Проверьте зашифрованные данные в базе.
- Проверьте размер базы и время отклика на каждый запрос.
- Проверьте данные, отображающиеся на фронтэнде, и убедитесь, что они совпадают с бэкэндом.
- Проверьте целостность данных, вводя невалидные значения в базу.
- Проверьте триггеры.
Что такое тестирование безопасности?
Тестирование безопасности нацелено на поиск недостатков и пробелов с точки зрения безопасности приложения.
Сценарии тестирования безопасности:
Что такое тестирование производительности?
Тестирование производительности проводится для оценки соответствия системы или компонента специфичным требованиям к производительности.
Общие тестовые сценарии:
- Определение производительности, стабильности и масштабируемости приложения под разной нагрузкой.
- Определение, может ли актуальная архитектура поддерживать приложение при пиковых нагрузках.
- Определение, какая конфигурация приводит к наилучшим показателям производительности.
- Определение бутылочного горла приложения и инфраструктуры.
- Определение, не изменилось ли время отклика у новой версии приложения.
- Оценка продукта и/или железа с целью удостовериться, что они выдержат прогнозируемые объемы нагрузки.
Как проводится тестирование производительности? Вручную или автоматически?
В целом невозможно проводить тестирование производительности вручную по ряду причин:
- Понадобится большое количество ресурсов.
- Невозможно одновременно осуществлять ряд действий.
- Отсутствует подходящий способ отслеживания поведения системы.
- Сложность выполнения повторяющихся задач.
Читайте также: