Как тестировать программное обеспечение

Серия статей про тестирование программного обеспечения. Часть 4: как тестировать программное обеспечение.

Вернуться к главной странице  Тестирование программного обеспечения.

Содержание

1. Как тестировать программное обеспечение
2. Как тестировщик тестирует программное обеспечение
3. План тестирования (тест-план)
4. Техники тестирования
5. Инструменты тестировщика
6. Баг
7. Критерии остановки тестирования программного обеспечения
8. Как тестировать

Как тестировать программное обеспечение

Многие начинающие и не только начинающие тестировщики задаются вопросом “А как тестировать программное обеспечение”, каким образом тестировать сайт или программу, как тестировать требования, как тестировать прототипы к программе или веб-сервису… В этой главе рассмотрим разные аспекты того, как тестировать программное обеспечение.

Как тестировщик тестирует программное обеспечение

Тестировщик (специалист по тестированию, QA-инженер) каждый день сталкивается с тестированием программного обеспечения, для него этот вопрос имеет необычайную важность. Одни тестировщики тестируют, полагаясь на интуицию, другие тестировщики проверяют абсолютно всё в программном обеспечении, но есть тестировщики, которые знают, как тестировать программное обеспечение, соблюдая баланс скорости и качества. Такие тестировщики умеют концентрироваться на главных сценариях и второстепенных, они обладают не только базовыми знаниями теории тестирования, но и знают и умеют использовать специальные техники тестирования, о которых поговорим чуть ниже.

В общем и целом, процесс тестирования программного обеспечения можно представить в следующем виде: начинается этап тестирования задачи, тестировщик составляет план-тестирования, пишет чек-листы по каждому направлению в задаче, расписывает каждый пункт чек-листа, после описания нужных сценариев, расстановки приоритетов наступает непосредственно этап тестирования, на котором тестировщик проверяет сгенерированные сценарии. В процессе тестирования тестировщик отмечает по каждому пункту — пройден сценарий успешно или есть проблема. Если есть проблемы, они выписываются отдельно, задача возвращается разработчику, разработчик исправляет все проблемы и переводит задачу снова на тестировщика. После этого задача тестировщика перепроверить поправленные пункты и продолжить тестирование с учетом новой информации. После окончания тестирования пишется отчет о тестировании (тест-репорт), в котором тестировщик описывает кратко список проверок согласно тест-плану, что было проверено и какие результаты тестирования. Если всё хорошо, задача уходит в релиз (выпуск на боевую, production).

План тестирования (тест-план)

План тестирования (сокращенно: тест-план) — это документ, который состоит из нескольких разделов, если кратко, это могут быть разделы про стратегию тестирования, про то, какие техники тестирования будут использоваться, про сроки тестирования, про то, что будет тестироваться, как будет тестироваться, какие будут использоваться инструменты тестирования и какие могут быть риски и ограничения при тестировании.

Хороший пример тест-плана (плана тестирования) можно посмотреть в статье  Тест план для тестирования пример. Рассмотрим, какие бывают техники тестирования.

Техники тестирования

Техники тестирования — это техники, которые помогают тестировщику эффективнее и быстрее решать свои задачи, т.е. проводить тестирование так, чтобы на меньшее время находить больше проблем, так, чтобы грамотно расставить приоритеты при написании тест-плана и чек-листов, так, чтобы не пропустить самые важные сценарии, и так, чтобы минимизировать возможные негативные последствия, если что-то пойдет не так.

Обычно выделяют базовые техники тест-дизайна и тест-анализа: классы эквивалентности, граничные значения. Это самые основные и базовые техники тест-анализа и тест-дизайна, но подобных техник существует огромное количество. Попробуем рассмотреть основные техники, а остальные техники зафиксировать в виде названий этих техник, чтобы можно было углубляться в каждую технику тестирования так, чтобы знания по каждой технике можно было расширять постепенно.

Список техник тест-дизайна и тест-анализа:

• Классы эквивалентности.
• Граничные значения.
• Причина следствие.
• Предугадывание ошибок.
• Исчерпывающее тестирование.
• Тестовые туры.
• Техника попарного тестирования.
• Техники тестирования требований.
• И, на самом деле, на этом список не заканчивается, эта тема огромна, будем стараться расширять список техник тестирования на этой странице.

Если Вы знаете другие техники тестирования, которых нет в этом списке, напишите комментарий в этой статье, либо присылайте в обратную связь. Сделаем список техник тестирования вместе!

Классы эквивалентности

Техника тестирования “Классы эквивалентности”. Другие названия техники: анализ классов эквивалентности, разбиение на классы эквивалентности, техника анализа классов эквивалентности, отношение эквивалентности, equivalence class, выделение классов эквивалентности, таблица классов эквивалентности, тест дизайн классы эквивалентности. Классы эквивалентности — это техника в тестировании программного обеспечения, суть которой заключается в том, что выборку тестовых данных можно разбить на классы, что тесты в одном классе будут эквивалентны друг другу. Если в одном классе 100 тестов, достаточно проверить один, и тогда мы сэкономим много времени, не проверяя все остальные 99 тестов, т.к. тесты в одном классе эквивалентны друг другу.

Про технику классов эквивалентности читайте в статье Классы эквивалентности примеры.

Граничные значения

Техника тестирования “Граничные значения”. Другие названия техники: анализ граничных значений, метод граничных значений, техника граничных значений, метод анализа граничных значений, тест дизайн граничные значений, boundary value analysis, границы классов эквивалентности.

Техника граничных значений — это продолжение техники классов эквивалентности, только базируется эта техника на том, чтобы провести анализ граничных значений классов эквивалентности. Пусть у нас есть несколько классов эквивалентности, нужно найти границы этих классов. Для простоты возьмем два класса эквивалентности. Можно рассмотреть отдельно первый класс эквивалентности, и отдельно рассмотреть второй класс эквивалентности. Для первого класса будут две границы — то, что до класса эквивалентности, и то, что после него. Для второго класса аналогично — будут две границы — то, что до класса эквивалентности и то, что после класса эквивалентности. Заметим, что классы идут подряд, поэтому можно выделить общую границу для двух классов эквивалентности, поэтому для двух классов эквивалентности будет всего три границы. Когда выделили границы классов эквивалентности, можно выделить граничные значения. Для этого фиксируем значение границы, до границы и после границы, получаем три значения для каждой границы. Итого 9 значений для всех трех границ классов эквивалентности. В этом и есть суть техники анализа граничных значений: выделяем классы эквивалентности, выделяем границы классов эквивалентности и выделяем граничные значения, остается только зафиксировать эти граничные значения в виде тестов и провести тестирование, выполнить проверки по этим тестам.

Инструменты тестировщика

Существует множество инструментов, которые помогают тестировщику быстрее и эффективнее проводить тестирование. Рассмотрим несколько инструментов тестирования (инструментов тестировщика).

Карты тестирования

Карта тестирования (чек-лист, check list, mindmap, мэпка, карта, список проверок) — это карта с проверками, то, что тестировщик проверяет при тестировании. Карта может быть в виде дерева, может быть в виде списка, и даже в виде таблицы. Формат карты тестирования (мэпки) определяется удобством использования, а также договоренностями в команде тестировщиков, в котором виде лучше всего хранить те или иные карты тестирования.

Инструменты веб тестирования

Веб-тестировщик имеет в своем арсенале множество инструментов. Часть инструментов UI-тестирования (веб-тестирования) можно посмотреть на сайте https://radar4site.ru в разделе Инструменты тестировщика: генератор идей тестирования (для новых идей по тестированию), генератор ИНН/КПП (чтобы при тестировании форм в программах и сайтах не ломать голову над тем, откуда взять правильные ИНН и КПП), определитель возраста сайта, определитель ИКС сайта, определитель числа символов в тексте (бывает полезным при вставке больших текстов в формы), а также недавно появившиеся инструменты тестирования — проверка слов на ошибки и проверка ударения в слове (эти сервисы еще пока в стадии доработки). Немаловажным инструментом тестировщика является возможность быстро и удобно делать скриншоты (снимок экрана, картинка экрана, рабочего стола) и видео. Для этого существуют специальные утилиты и программы, так называемые скриншотилки.

Инструменты процесса разработки

Может быть полезно владение инструментами процесса разработки: GIT (система контроля версий, чтобы иметь возможность быстро посмотреть, какие были изменения исходном коде программного обеспечения), SQL (язык запросов, для выполнения запросов в базу данных и добычи нужных данных), IDE (среда разработки, в которой пишется код программного обеспечения, чтобы общаться с разработчиками на одном языке и быстро доносить обратную связь по возможным проблемам программного обеспечения).

Баг

Что такое баг

В процессе тестирования программного обеспечения зачастую неизбежно возникают ситуации, когда тестировщик видит какое-то несоответствие того, что реализовано в программном обеспечении (сайте, программе, приложении) и тем, что описано в документации, либо с тем, что не согласуется с представлениями тестировщика. Когда возникает такое расхождение — это называют багом (от английского — bug, ошибка, проблема, дефект). У бага есть даже свой жизненный цикл, давайте рассмотрим его подробнее.

Жизненный цикл бага

Тестировщик нашел баг, что с ним будет происходить дальше? Рассмотрим жизненный цикл багов (бага). Данный жизненный цикл — это примерный жизненный цикл бага, он может отличаться в зависимости от команды тестирования, команды разработки, договоренностей в компаниях и т.д.

Жизненный цикл бага (статусы багов):

Новый — новым баг становится, когда только был обнаружен тестировщиком и зафиксирован в виде баг-репорта. Зафиксировать можно по-разному: в баг-трекинговой системе, в личном сообщении разработчику или команде и даже в устной форме (но так никто обычно не делает).

Исправлен (пофиксен, fixed bug) — это когда разработчик взял баг в работу и успешно его починил, исправил, пофиксил и отправил тестировщику на проверку.

Закрыт (closed bug) — это когда тестировщик проверил поправленный баг, что он действительно поправлен и не привел к другим проблемам и багам, и зафиксировал, что баг закрыт и больше не воспроизводится.

Это основные статусы жизненного цикла бага, но могут быть и другие, например: баг открыт (opened bug), баг отложен (deferred bug), баг отклонен (rejected bug), дубликат бага (duplicate bug, такой баг уже есть), баг назначен, баг проверен (verified bug), баг переоткрыт (открыт повторно, reopened bug).

Приоритеты багов

Приоритет бага — это характеристика, отражающая то, насколько тот или иной баг нужно исправлять в первую очередь, какой — во вторую очередь, т.е. очередность взятия багов в работу. Приоритет багов необходим в первую очередь для тест-менеджера, чтобы понять, что из всех багов вот эти баги первее нужно чинить, вот эти могу немного подождать первых багов.

High — баг с высоким приоритетом, самый высокий приоритет бага, его нужно брать в первую очередь в работу.

Medium — баг со средним приоритетом, его нужно брать, если нет багов с высоким приоритетом.

Low — баг с низким приоритетом, это баг, который может подождать, если нет багов с более высокими приоритетами.

Серьезность багов

Серьезность багов — это характеристика, отражающая, насколько серьезен той или иной баг (дефект, проблема, ошибка) в программном обеспечении.

Blocker — блокирующий баг, когда программное обеспечение или часть программного обеспечения совсем не работает.

Critical — критичный баг, не работает основная часть функциональности программного обеспечения.

Major — значительный баг, мажорный баг, когда проблема существенная, но есть обходные пути для прохождения сценария.

Minor — минорный баг, небольшая проблема, с которой можно жить дальше, небольшая неприятность.

Trivial — совсем мелкий баг, опечатка, какая-то неточность в программном обеспечении.

Критерии остановки тестирования программного обеспечения

В процессе тестирования может возникнуть вопрос “А когда можно остановиться тестировать? Какие есть критерии остановки тестирования программного обеспечения? Или можно тестировать бесконечно?” В процессе разработки программного обеспечения есть задачи, у задач есть примерные сроки на их реализацию и тестирование. Поэтому первым критерием остановки тестирования назовем время.

Вторым критерием остановки тестирования ПО может быть то, что проведено полноценное тестирование с проведением всех возможных тестов, поэтому второй критерий остановки тестирования программного обеспечения — это все тесты пройдены.

Третий возможный критерий остановки тестирования программного обеспечения — это дымовое тестирование не пройдено. Если в программном обеспечении не работают основные сценарии использования, не проходят самые базовые и основные тесты, то нет смысла продолжать тестирование, нужно сразу отдать задачу разработчику на переделку.

В общем и целом, это все основные критерии, но могут быть и другие. Можете поделиться в комментариях.

Как тестировать

Как тестировать программное обеспечение? Вооружившись знаниями прошлых глав, воодушевившись техниками тест-дизайна и тест-анализа можно начинать тестировать свой первый сайт, первую программу или первое приложение. Не важно, что тестировать, главное — начать. И остановиться будет уже невозможно.

Как тестировать сайты

О том, как тестировать сайты есть отдельная статья  Как протестировать сайт пошаговое руководство, опишем вкратце, как выглядит процесс тестирования сайта: тестировщик получает задание — протестировать сайт, интернет-магазин, лендинг, либо часть функциональности сайта. Тестировщик пишет план тестирования, составляет чек-листы, карты тестирования по тестированию сайта. Затем тестировщик проходит пункты чек-листов, дописывает новые проверки и тесты в чек-листах и картах тестирования, описывает баг-репорты и в после финального этапа тестирования пишет отчет о проведенном тестировании сайта. Если очень кратко, то так выглядит процесс того, как тестировщики тестируют сайты.

Как тестировать программное обеспечение

Процесс тестирования программного обеспечения выглядит следующим образом. Для примера можем взять простой калькулятор в Windows. Что нужно сделать, чтобы протестировать программу калькулятор? Для начала нужно определить цели и задачи тестирования, зачем мы будем тестировать калькулятор? Для кого будет производиться тестирование калькулятора? В нашем случае — может быть тестирование с обучающей целью, чтобы понять, как тестировать калькулятор, нужно его протестировать.

Когда цели и задачи ясны, можно перейти к написанию плана тестирования. Открываем калькулятор и записываем все идеи, которые приходят в голову. Можно отталкиваться от основных сценариев, например, посчитать 2 + 2 и увидеть, что программа выводит корректный результат. Затем нужно выписать список функций калькулятора, что умеет делать калькулятор, исходя из функций провести тестирование каждой функции программы. Затем вспомним техники тестирования — классы эквивалентности и граничные значения и попробуем составить их применимо к нашему калькулятору, на основе составленных комбинаций можно провести тестирование. Для удобства можно открыть программу для составления интеллектуальных карт и составить мэпку (карту тестирования), в которой обозначить основные ветки и ответвления от основных веток, где ветки — это направления функций калькулятора, а подветки — это конкретизация каждого направления, каждой функций. Работая над картой тестирования можно составить множество сценариев, тестов, каждый из которых нужно протестировать. В процессе проверки возле каждого пункта можно поставить либо зеленую галочку, либо красную. Зеленая будет означать, что тест пройден успешно. А красная — то, что есть проблема, найден баг (ошибка) в программном обеспечении, в данном случае, в программе калькулятор. Мы описали вкратце процесс того, как тестировать программное обеспечение.

Как тестировать мобильные приложения

Как тестировать мобильное приложение? Допустим, у нас есть мобильный телефон, на нем установлено новое приложение, которое только отправил Вам разработчик. Как протестировать мобильное приложение? Процесс тестирование мобильных приложений несколько отличается от тестирования программного обеспечения.

Во-первых, у мобильного телефона есть множество специфичных настроек, таких как, сотовая связь, наличие сим-карты, возможность подзарядки и т.д. Во-вторых, мобильное устройство имеет небольшие габариты, небольшой экран, на нем помещается не так много информации, из-за этого в мобильном телефоне есть специфичные элементы и технологии, которых нет на стационарном компьютере, на desktop-устройстве, такие как: компонентных мобильных операционных систем, сенсорный контакт (пролистывание — свайпы) и т.д.

Процесс тестирования мобильного приложения может выглядеть следующим образом: на телефон скачивается мобильное приложение, тестировщик открывает его, выделяет основные функции (основные сценарии) приложения, проверяет основные сценарии, дальше смотрит неосновные сценарии (негативные сценарии), и после этого пишет отчет о тестировании и отчет о найденных ошибках (багах). Если рассматривать объект — приложение, его, как правило, тестируют на разных мобильных операционных системах (Android, iOS), на разных устройствах, обычно на самых последних версиях.