ссылка
|
|
https://praktikum.yandex.ru/ - полный курс + задания и т.д. https://code.s3.yandex.net/qa/cheatsheets/glossary.pdf |
Основное:
|
|
Ожидаемый результат (ОР) — то, как система должна работать согласно требованиям. Фактический результат (ФР) — то, как система работает по факту. API (англ. application programming interface) — программный интерфейс приложения, который помогает сайту взаимодействовать с внешними программами и серверами. Например, авторизация на сайте через социальные сети. |
Всегда включай в отчёт:
|
|
Уникальный идентификатор (УИД — англ. uid — Unique identifier) — номер, который присваивают баг-репорту. Уникален как номер банковского счёта. Системы ведения задач генерируют его автоматически. Заголовок — кратко объясняет, что произошло. По нему можно понять суть ошибки, не читая весь отчёт. Шаги воспроизведения — это алгоритм, пошаговая инструкция, как получить баг. Результаты - описывают расхождение между тем, что должно быть и что получилось. Окружение - уточняет, в каких операционных системах и браузерах возникла ошибка. Например, в Firefox она есть, а в Yandex Browser — нет. Приоритет - показывает критичность ошибки: насколько она влияет на систему. |
Есть поля, которые необязательно включать в отчёт:
|
|
Предусловие - показывает, что надо сделать до шагов воспроизведения. Писать «Включите компьютер» или «Откройте браузер» не надо. Указывать предусловия стоит, когда нужно корректировать настройки, менять параметры перед шагами. Постусловие - прописывают, если систему нужно вернуть в прежний вид после тестирования. Описание - создают, если в заголовке недостаточно информации о дефекте. Если ошибка устроена сложно, стоит сделать небольшое описание: оно суммирует все детали баг-репорта. Описание позволяет изучить дефект подробнее. Дополнительные материалы — всё, что помогает проиллюстрировать баг. Скриншоты, скринкасты, логи, файлы для воспроизведения ошибки. Иногда ошибка комплексная, и по шагам в ней разобраться трудно: тут придут на помощь фото или видео. Прикрепи всё, что влияет на результат. |
Заголовок баг-репорта
|
|
Заголовок баг-репорта - исчерпывающе описывает проблему. Это экономит время коллег: они сразу понимают суть, не вникая в детали отчёта. Составляя заголовок, задавай три вопроса: Что? Где? Когда? Старайся описывать не ожидаемый результат, а фактический. ВОПРОС КАК РАСШИФРОВАТЬ ВОПРОС? ПРИМЕР Что? Что происходит? Открывается главная страница Яндекса Где? В каком месте страницы? Метро в логотипе Когда? При каком действии это происходит? По клику |
Классификация багов
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
Баги — очень разные. Их различают по степени влияния на систему — серьёзности (severity): Блокирующий (Blocker), на жаргоне — «блокер». Ни один элемент системы не работает: никто не может ей пользоваться. На сайте интернет-магазина нельзя сделать покупку. Продукт не выполняет свою задачу. Критический (Critical). Важная часть системы не работает: пользоваться можно, но вероятность сбоя — высокая. В интернет-магазине не работает кнопка «Купить» после авторизации в личном кабинете. Без авторизации всё работает — магазин ещё может принимать заказы. Высокий (Major). Система работает, но не так, как нужно. Пользоваться можно, элементы активны, но выполняют не то, что задумано. В интернет-магазине по кнопке «Купить» выдают скидку 3% на покупку. Приятно, но это не то, что планировали маркетологи. Кнопка работает неправильно. Низкий (Minor). С системой всё в порядке, но работать неудобно. Например, дефект в дизайне. В интернет-магазине в разделе «Товары» не работает вертикальная сортировка. Это не мешает пользователям делать заказ — ошибка не такая серьёзная. Незначительный / Тривиальный (Trivial). Баг, который не влияет на работу программы. Например, ошибка в тексте. На сайте интернет-магазина раздел «Чайники» назван «Чайник». Исправить ошибку совсем легко. |
Приоритет (priority)
|
|
Вторая классификация — по скорости исправления, приоритету (priority). Чем выше приоритет, тем быстрее надо исправить дефект. Им часто пользуются, чтобы правильно передать задачи от тестировщиков — разработчикам. Высокий приоритет (High) Срочно чинить! Без правок ПО работать не может. Пример: на сайте интернет-магазина нельзя сделать покупку. Средний приоритет (Medium) Ошибка некритичная, но без починки ПО не будет работать, как надо. Пример: в разделе «Товары» не работает вертикальная сортировка. Низкий приоритет (Low) Можно исправить, когда разобрались с критическими ошибками. Пример: раздел «Чайники» назван «Чайник». |
Приложение:
|
|
Когда описываешь окружение, иди последовательно. Порядок такой: Версия приложения — укажи версию продукта. Браузер, в котором открывалось веб-приложение — укажи название и версию (только для веб-приложений). ОС — укажи версию операционной системы: Windows, macOS, Linux. Устройство — указывают только для мобильных устройств: планшетов, смартфонов, часов. Не только тип, но и модель. Например, «смартфон Sony». |
Браузеры:
|
|
http://browsershots.org/ https://www.browserstack.com/ https://www.vanamco.com/ghostlab/ https://crossbrowsertesting.com/ https://www.google.com/intl/ru_ru/chrome/ https://www.mozilla.org/ru/firefox/ https://www.opera.com/ https://www.apple.com/ru/safari/ https://support.microsoft.com/ru-ru/help/17621/internet-explorer-downloads |
Логи
|
|
Иногда нужно уточнять: Oшибки, которые появились в приложении. Какие действия в приложении вызвали баг. Например, пользователь пытается зайти в приложение под своим логином, но что-то сломалось. Это критическая ситуация: нужно выяснять, что произошло. Пригодятся логи. Логи — это файлы, в которых хранится информация о системе: список процессов обработки информации, и что в них происходит. В веб-приложения или сайты закладывают специальные текстовые файлы: error_log и access_log. В access_log — информация о посещениях сайта, error_log — об ошибках. Нативные приложения фиксируют логи по-разному: процесс настраивают разработчики. |
Файл лога содержит:
|
|
Наборы полей логов зависят от типа сервера и настроек логирования. Как они выглядят: *pid = process id; tid = thread id — номера. Они помогут отследить, что произошло. Уровни запросов в логах разные: debug — подробные уведомления, которые помогают отладить систему; info — сообщения о процессах в системе; notice — системные уведомления; warn — предупреждение от системы; error — баги. Логи сайта хранятся на сервере: к нему понадобится доступ. Важно прикреплять к баг-репорту документ с логами, а не скриншот — копировать быстрее, чем переписывать с картинки. |
Специальные программы для записи скринкастов:
|
|
https://www.ispring.ru/ispring-free-cam https://getsharex.com/ https://camstudio.org/ https://obsproject.com/ru |
Как правильно называть вложения?
|
|
Из названия должно быть сразу ясно, что в дополнительном материале и к какому баг-репорту относится этот файл. Применяй универсальный алгоритм. Так ты подберёшь ёмкие названия вложений. {УИД бага}-{название сервиса}-{суть проблемы}.png |
Оракул
|
|
Оракулы. Это инструменты, которые помогают достроить картинку проблемы. Они подходят в отдельных ситуациях и не указывают на проблему точно. Скорее подсказывают, где скрывается баг. |
Технические оракулы
|
|
История. Сравни новую версию продукта с предыдущей. Заявления. Проверь, что система работает так, как о ней говорят: документация (требования, результаты проверки, регламенты); твоя команда (выводы с встреч, планёрок, долгосрочного планирования). Объяснимость. Убедись в том, что любой шаг работы системы можно объяснить. Известность. Проверь, что в продукте нет ошибок, которые уже нашли раньше. |
Продуктовые оракулы
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
Имидж. Убедись, что в продукте есть ценности, которые ассоциируются с брендом. Например, компания занимается экологическим активизмом, но продаёт сувениры из неперерабатываемого пластика. Конкуренты. Проверь, что у конкурентов продукт выстроен по той же системе. Например, сайт доставки цветов. Заказать цветы можно только на свой адрес при предъявлении паспортных данных. Вряд ли это будет востребовано, когда конкуренты рассылают букеты куда угодно по желанию клиента. Продукт. Проверь, что все элементы системы согласуются между собой и органичны. Например, в Яндекс.Метро кнопка «+» добавляет в приложение корзину и предлагает купить станцию. Это элемент, который не имеет отношения к логике сервиса — Яндекс.Метро помогает оптимизировать маршруты. Ожидания пользователя. Предугадай ожидания пользователя и учти их. Например, сайт, который позволяет заказать пиццу. Но заказ нельзя оплатить картой — это неудобно клиенту. |
Логические оракулы
|
|
Цель. Проверь, что продукт работает по назначению и выполняет все шаги. Например, в интернет-магазине мебели можно автоматически посчитать стоимость заказа, а сделать сам заказ нельзя. Стандарты и законы. Проверь, что продукт не нарушает никакие требования и нормы закона. Например, в интернет-магазине в России продаётся алкоголь с курьерской доставкой. Согласно последним поправкам, это запрещено. Мир. Проверь, что продукт работает по законам логики. Например, нельзя купить отрицательное количество товаров. |
Тест-кейс
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 |
Тест-кейс — вид тестовой документации, описывает процесс проверки сервиса. По структуре он схож с баг-репортом. Но если тест-кейс помогает выяснить, есть ли ошибка, баг-репорт — фиксирует дефект, который уже нашли. Обязательные элементы тест-кейса: УИД Заголовок Предусловие/постусловие Шаги Ожидаемый результат (ОР) Также указывают: Операционную систему (ОС). Устройство, на котором тестируют продукт. Другие компоненты: например, версию ПО, названия элементов, которые проверяют, роль пользователя. Зачем нужны тест-кейсы? Хранят информацию о продукте, а также требования к нему. Тест-кейсы помогают проверить ПО, а также показывают специфику продукта новым сотрудникам. Чтобы делать автоматизированные тесты. Тест-кейсы — обязательный элемент автоматических тестов. Тест-кейсы похожи на структуру кода: программа легко снимет точные шаги и ожидаемые результаты. Статус Skipped можно присваивать, если: Невозможно выполнить «Предусловие». Не хватает информации. Например, не указаны логины/пароли администратора. Сервис недоступен: в этих условиях нельзя проверить тест-кейсы. Тест-сьют, набор тест-кейсов по одной теме или области продукта. Где хранят тест-кейсы и тест-сьюты? Записывать тест-кейсы и объединять в сьюты удобнее в специальных приложениях. MS Excel — хорошо подходит, чтобы фиксировать тест-кейсы и тест-сьюты. Есть минимум необходимых инструментов. Посмотреть пример отчёта в формате Excel или скриншот. Готовые решения для профессиональных тестировщиков ещё лучше, но они платные. Например, Jira, Zephyr, TestRail, TestLink, QTest, Practitest. |
Позитивное и негативное тестирование
|
|
Позитивное тестирование — проверка, что элементы сервиса работают в тех случаях, в которых в любом случае должны. Пример: Проверь, что микроволновая печь выполняет программу «Гриль» по инструкции. Негативное тестирование — проверка, что элементы сервиса реагируют как нужно на некорректное использование, и система продолжает работать. Пример: Проверь, что микроволновая печь перестаёт работать, если дверца не закрыта или закрыта неплотно. |
Смоук-тестирование
|
|
Смоук-тестирование (от англ. — smoke — «дымовое») — проверка, что основные части приложения работают так, как написано в документации. Название пришло из инженерной среды. После того как запускают оборудование, проверяют, что не пошёл дым — нет короткого замыкания. Например, ты хочешь купить фотоаппарат и идёшь в магазин. После оплаты продавец проведёт смоук-тестирование: покажет, включается ли фотоаппарат, делает ли снимки, сохраняет ли фотографии. Смоук-тестирование выполняют, если: В приложение внесли незначительные правки. Когда обновились совсем незначительные детали сервиса (другой фон кнопки, новая надпись), проводят промежуточную внутреннюю проверку. Мало времени на тестирование. Рабочие ситуации бывают разные — иногда совсем некогда и нужно сдать проект таким, как есть. «Смоук» поможет убедиться, что приложение не сломалось. |
Регрессионное тестирование
|
|
Регрессионное тестирование проверяет, что все элементы сервиса работают так же, как и до обновления. Другими словами, что ничего не сломалось, нет регресса — отсюда и название. Регрессионное тестирование охватывает вообще весь набор тестов. «Смоук» — тоже часть регрессионного тестирования. Во время регрессионного тестирования сначала проводят «смоук»: проверяют, не сломались ли основные элементы приложения, — а затем все остальные тесты. Например, новый пульт для телевизора. В инструкции написано, как работают 20 функций пульта. Тебе захотелось проверить всё сразу. Это регрессионное тестирование. |
Локализация
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
Локализация — процесс адаптации приложения к другим языку, региону, стране. Её проводят, если приложение выходит на зарубежный рынок. Что обычно локализуется в приложении? Язык, правописание, слова и идиомы Дата и время Индексы и номера телефонов Системы мер и весов Изображения Валюта Всегда ли адаптируют все элементы сервиса? Зависит от приложения. Например, в калькуляторе валют переведут только язык, а в интернет-магазине — всё перечисленное. Тестирование локализации Как правильно протестировать адаптированную версию приложения? Получить от команды документацию версии для другой страны. Так ты выяснишь, какие элементы локализовали, а какие — оставили как есть. Составить тест-кейсы по всем элементам локализации. Обязательно узнай, как они должны выглядеть в новой версии. Локализацией обычно занимается переводчик — он поможет. Если приложение локализовали в нескольких странах одновременно, лучше проверить каждый элемент сразу во всех версиях. |
