Как составить алгоритм тестирования

Уровень сложности
Простой

Время на прочтение
6 мин

Количество просмотров 9.7K

Всем привет! Меня зовут Елена Поплоухина. Я — один из авторов Youtube‑канала по тестированию «Багаж тестировщика». На канале выходил выпуск про построение процесса ручного тестирования с нуля. Данная статья содержит основную информацию из этого выпуска — 2 общих совета и 6 первых шагов для организации процесса.

Введение

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

• Проект только стартует, команда формируется, процессы строятся с нуля;

• Проект уже развивается, выпускаются публичные релизы. Но присутствуют проблемы с качеством.

Возможно, вы чувствуете себя как ежик в тумане. С чего же начать?

Совет 1 — Начните с выяснения проблем и ожиданий от тестирования

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

Не ждите, что коллеги с энтузиазмом возьмутся за дело и подробно опишут проблемы. Лучше заранее подготовить список самых распространенных проблем и отправить его команде в виде опросника.  Для таких опросов хорошо подходят Гугл формы.

Примеры проблем:

• Ошибки в требованиях обнаруживаются на стадии разработки или тестирования фич;

• Значительные затраты времени на коммуникации между членами команды;

• Баги часто не воспроизводятся по описанию. Разработчикам приходится тратить время на общение с тестировщиком для выяснения деталей бага;

• Нет критериев для выпуска текущей версии приложения в прод;

• и т.д.

Дополнительно выясните ожидания от тестирования. В отличие от перечня проблем, предложите описать эту информацию в свободной форме.  Обычно ожидания тесно связаны с проблемами, выявленными на предыдущем этапе.

Ожидания от тестирования укажут направление, с которого стоит начать строить процесс тестирования. Например, ожидание «Снизить в 2 раза% возврата багов между QA и Dev» говорит о том, что нужно внедрить шаблоны для багов и согласовать регламент работы с багами.

Совет 2 — Внедряйте улучшения постепенно

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

---

Далее рассмотрим 6 практических рекомендаций для организации процесса тестирования.

Внедрите шаблон бага

Разработайте шаблон бага и описывайте найденные ошибки по нему. Если на проекте используется система вики — заведите в ней отдельный раздел для тестирования и храните в нем шаблоны документов и регламенты.

Наличие шаблонов для багов несет следующие преимущества:

• Экономия времени на воспроизведении багов как разработчиками, так и тестировщиками. В случае короткого и неинформативного описания не только разработчик, но и сам автор бага может не вспомнить, о чем шла речь.

• Сокращение времени на коммуникации между dev и qa — этот пункт вытекает из предыдущего. Разработчики не будут стучаться к вам в личку со словами — а что имелось в виду в этом баге? А на каком стенде и тестовых данных он воспроизводится? 

• Единый стиль багов — с багами приятно и привычно работать всем членам команды.

Согласуйте список приоритетов багов

При разработке шаблона бага уделите внимание набору приоритетов. Приоритеты отвечают за порядок исправления багов. Команде нужно избегать ситуаций, когда разработчики исправляют 10 багов низкого приоритета вместо 1 критичного. 

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

Вы можете установить 5 приоритетов для багов, например: 

• Блокирующий — Blocker

• Критический — Critical

• Важный — Major

• Нормальный — Normal

• Минорный — Minor

Или обойтись более простой версией из трех приоритетов:

• Высокий — High

• Средний — Normal

• Низкий — Low

Согласуйте правила установки приоритетов, оформите в виде регламента и положите в wiki.

Внедрите регламент работы с багами

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

ЖЦ бага представляет из себя описание состояний бага и правил перехода по ним в системе управления проектами. 

Для составления регламента выполните следующие шаги:

• Продумайте набор статусов для багов. 

• Определите правила перехода между статусами и порядок назначения исполнителей.

• Согласуйте регламент с менеджером проекта.

Регламент представляется в виде наглядной схемы или текстового описания. После согласования регламента с командой положите его в wiki и следите первое время за его исполнением.

Согласуйте регламент работы с задачами в системе управления проектами

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

Вся команда должна придерживаться правил перевода задач по статусам. QA инженерам особое внимание стоит уделить статусам для тестирования задач:

• Ready for test — задача завершена разработчиками и готова к тестированию;

• Testing — задача находится на тестировании у тестировщика;

• Done — задача протестирована в рамках итерации;

• и т.д.

Пишите тест-кейсы или чек-листы… как можно раньше в процессе обеспечения качества

Один из первых навыков, которым учатся тестировщики — проектирование тест-кейсов. Это база. Тем не менее, тестировщики не всегда создают тестовые сценарии «на бумаге».

Одной из главных причин называется «нет времени». Эта проблема решается путем грамотного планирования итерации и оценки времени на тестирование.

При отсутствии чек‑листов или тест‑кейсов вы рискуете качеством своего продукта.

2 основных совета по стадии проектирования тест-кейсов следующие:

• Если нет необходимости в тест-кейсах, пишите чек-листы; 

• Пишите тест-кейсы или чек-листы как можно раньше в процессе обеспечения качества. В идеале — еще на стадии тестирования требований или до разработки.

Преимущества раннего проектирования тест-кейсов или чек-листов:

• Вы не торопитесь, сосредоточены и можете качественно продумать тестовые случаи;

• Ранний поиск ошибок в требованиях;

• Возможность приступить к тестированию сразу после передачи задачи на тест.

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

Минусы тестирования без тест-кейсов или чек-листов:

• Вы придумываете тестовые ситуации на ходу, при этом прерываетесь на тестирование, локализацию и заведение багов, коммуникации;

• Перепроверка одних и тех же ситуаций несколько раз;

• Риск пропуска тестовых случаев повышается из-за спешки или отсутствия задокументированных результатов выполнения;

• Присутствует ощущение, что “вроде вы все проверили”, но “возможно что-то забыли”.

Риск пропуска багов в таком случае гораздо выше, чем при наличии кейсов. А уверенность в качестве продукта — ниже.

Установите критерии выпуска релиза в прод

Как определить, когда текущая версия готова к релизу? Ждать до исправления последнего бага или все же нет?

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

Эти критерии вы должны согласовать с командой и придерживаться их. Для начала выберите несколько критериев, попробуйте выпустить релиз на их основе или просто завершить итерацию. После 1 или нескольких релизов  проанализируйте, насколько выбранные критерии удовлетворяют процессу. 

Пример критериев:

• По всем фичам проведено тестирование;

• По фичам исправлены баги всех приоритетов, кроме низкого;

• Проведено регрессионное тестирование;

• и т.д.

В результате тестирования вы предоставляете менеджеру проекта решение о готовности продукта к релизу. Критерии помогут вам перейти от варианта “вроде все работает” к обоснованному заключению.

Заключение

Мы рассмотрели 2 общих совета и 6 первых практических шагов для построения процесса ручного тестирования на проекте.

Спасибо за внимание и до встречи в следующей статье!

Автор: Ричард Патерсон (Richard Paterson)

Оригинал статьи

Перевод: Ольга Алифанова

Многие организации планируют тестирование, не осознавая всей ценности такого планирования. Тестировщики зачастую создают тест-планы просто потому, что всегда это делали (или процессы гласят им, что так надо). Если тест-план грамотно составлен – это мощное оружие в вашем тест-арсенале.

Писать тест-план или не писать – вот в чем вопрос! Этот вопрос регулярно поднимается в обсуждениях на Software Testing Clinic. Положительный ответ на этот вопрос, в свою очередь, породит множество новых вопросов. Вот некоторые из них, которые стоит задать себе или команде:

• В какой форме тест-план должен быть?
• Какую информацию он должен включать?
• Для кого он предназначен?

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

Нужен ли вам тест-план?

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

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

Я не собираюсь указывать вам, писать вам тест-план или не писать. Только вы можете определить, требуется ли вам этот документ в вашем конкретном контексте. Я лишь хочу, чтобы вы честно спросили себя, нужен ли вам этот тест-план?

Если вам кажется, что план вам нужен, то ниже – ряд вопросов, которые стоит задать, и несколько неплохих возможных ответов на них:

Вопрос: Кто запрашивает этот документ?

Ответ: заказчик, мы обязаны предоставить его по контракту.

Вопрос: Кто будет читать этот документ?

Ответ: Менеджер проекта, которому нужно убедиться, что я собираюсь протестировать продукт как минимум на удовлетворительном уровне.

Вопрос: Что читатель получит от этого документа?

Ответ: Вместе с прочей информацией – достаточную уверенность для релиза.

Вопрос: Что может улучшиться, если я прекращу писать тест-план?

Ответ: У меня будет больше времени для действительно ценной для проекта работы, потому что я не трачу время на то, что никто не будет читать.

Вопрос: Что может ухудшиться, если я прекращу писать тест-план?

Ответ: В проекте никто не будет иметь ни малейшего понятия, что именно я тестирую.

Вопрос: Кто заметит, если я прекращу писать тест-план?

Ответ: Владелец процесса , так как создание тест-плана – это часть нашего контролируемого процесса.

Использование тест-плана как можно раньше в жизненном цикле проекта для поиска ответов на эти вопросы – это разновидность тестирования. Вы можете, например, спросить, есть ли критерии производительности, которые можно оценить и использовать для тестирования? Будет ли продукт выходить в интернет? Какие сценарии восстановления/избегания проблем должен поддерживать продукт? Задавая эти вопросы, вы подводите заинтересованных лиц к размышлениям о производительности, безопасности и устойчивости, и они займутся этим раньше, чем могли бы, не спроси вы их об этом.

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

Глаголы, а не существительные

«Планы бесполезны, но планирование бесценно» – Дуайт Эйзенхауэр.

Тест-планы статичны по своей природе, а планирование тестирования – динамический, дискурсный процесс обучения и переговоров. Документ, который никто не читает, бессмысленен. Создание того, что не принесет пользы проекту или его заинтересованным лицам, стоит денег и времени. План начнет приносить ценность только тогда, когда вы будете его использовать. Тест-план, который никто не читает, и который не информирует никого о тестировании – это трата вашего ценного времени, которое уместнее потратить на что-то более полезное.

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

Заинтересованные лица – кто они?

Документы создаются для коммуникаций между людьми. Вам нужно понимать, кто эти люди в контексте связанной с тестированием информации. Кто ваши заинтересованные лица?

Если вы не уверены в ответе, определитесь, на какие вопросы о тестировании вам нужно получить ответ, а затем выясните, кто может ответить на них наилучшим образом, и спросите их об этом. Они должны быть задействованы в тестировании продукта или приложения. Объясните, почему вы задаете эти вопросы, и расскажите им, как их ответы улучшат ваше тестирование.

Тест-планом также могут пользоваться те, кому полезна информация, полученная в ходе запланированного тестирования. Найдите их, спросите, какая информация им требуется, и планируйте соответственно. Ниже – примеры заинтересованных лиц:

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

Менеджеры проекта хотят знать, что вы собираетесь тестировать, дабы быть уверенными в решении о выходе в релиз.

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

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

Продажники сообщат, какие продукты наиболее популярны, и как именно они применяются.

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

Как написать хороший тест-план: форма, структура и содержание

Тест-планы могут принимать какую угодно форму, например:

• Word-документы – зачастую формат по умолчанию, так как Word доминирует на рынке, и люди хорошо с ним знакомы. Тест-планы варьируют от одностраничного документа, кратко описывающего основные области тестирования, до длинного, соответствующего IEEE829 / IEEE29119 стандартам мануала, подробно расписывающего каждую деталь.
• Ментальные карты – отличный способ изложить тест-информацию в структурированной графичной форме. Читателю легко отслеживать структуру плана и просмотреть его на необходимом уровне детализации. Погуглите «mindmap test plans», чтобы посмотреть на примеры.
• SharePoint / Wiki – отличные альтернативы Word, и обладают мощным инструментарием управления версиями и редактирования. Они позволяют гибко структурировать информацию, а также быстро обновлять и совместно редактировать ее.
• Web-инструменты планирования (например, Jira) можно использовать не только для планирования задач разработки. Интеграция с системами управления тестами (например, TestRail) даст команде полную картину запланированного и реального тестирования.
• Whiteboard / доски Kanban – еще один неплохой способ графически показать масштабы тестирования. Физические доски – очень прозрачный способ донести, что и как вы собираетесь тестировать.

Хороший способ начать тест-план – это одностраничный план. Он поможет вам создать краткий и информативный документ.

С точки зрения содержания тест-планы обычно создаются, чтобы зафиксировать базовые ответы на «пять почему и как» тестирования. Содержание ваших планов может меняться по ряду причин (к примеру, от релиза к релизу или от спринта к спринту). Обновляйте ваш тест-план на основании полученной от релиза к релизу (или от продукта к продукту) информации.

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

Со временем обновляйте шаблон, чтобы поддерживать и улучшать свое планирование. Пусть тетс-план работает на вас и формой, и структурой, и содержанием. Если он не работает – меняйте его.

Как оценивать тест-план

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

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

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

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

«Ни один план не выдерживает встречи с противником» – Хельмут фон Мольтке Старший.

«Только изменчивость постоянна» – Гераклит.

Как обновлять тест-план

Все меняется, и ваш план должен быть открыт переменам. Подход к планированию тестирования должен позволять справляться с изменениями, разъяснять, что вы будете делать иначе, какая информация вам необходима, и какую новую информацию (и кому) вы должны предоставить.

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

Тест-планы работают на вас

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

Тест-план может помочь вам обдумать, какая подготовительная работа вам нужна. Это особенно важно, если вы не контролируете то, что может вам понадобиться в процессе тестирования. Если вам нужны серверы, данные или доступ к инструментам, то с шансами вы будете во всеоружии, как только они будут доступны – если вы заранее все спланируете. Очень важно быть готовым к действиям, как только появится что-либо, что можно тестировать.

Эта информация также полезна во время ретроспектив и пост-мортемов, позволяя лучше принимать решения и обсуждать, как можно улучшить тестирование.

Полезный тест-план

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

Об авторе

Ричард Патерсон руководит тестированием и безопасностью приложений в SAS R&D (Шотландия). Он считает себя не только тестировщиком, но и дизайнером, лидером и создателем.

Контакты Ричарда: @rocketbootkid, LinkedIn и блог www.rcpaterson.co.uk/blog

Обсудить в форуме

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

В данной статье будет рассказано о том, что собой представляет тестирование, каким оно бывает и как организовывается. Также предстоит выяснить, кто такие тестировщики, всегда ли они нужны компании, чем занимаются такие специалисты. Информация будет полезна каждому, кто заинтересован в IT.

Определение

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

Системное тестирование – проверка работоспособности операционных систем. Больше относится к администрированию, чем к разработке контента. Важный процесс, без которого не состоится ни один релиз ОС.

Цели

Тестирование преследует определенные цели. К ним относят:

1. Повышение вероятности того, что программный продукт будет при любых обстоятельствах функционировать «как надо».
2. Проверка на факт соответствия итогового контента изначально выдвинутому набору требований.
3. Предоставление актуальной информации о том, в каком состоянии программа находится на текущий момент.

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

Для чего необходим

Тест – процесс проверки чего-либо. В разработке систем он очень важен. Помогает:

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

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

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

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

Немного терминологии

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

1. Качество ПО – совокупность характеристик системы, которые относятся к ее способности удовлетворять установленные и предполагаемые потребности. То, насколько контент соответствует изначальным критериям.
2. Верификация – процесс оценки системы или ее компонентов. Делается это для того, чтобы проверить, насколько результаты разработки на заданном этапе удовлетворяют начальным требованиям. Показывает, выполняются ли цели и задачи организации на том или ином шаге программирования.
3. Валидация – соответствие программного продукта или системы ожиданиям, желаниям, потребностям пользователя. То, насколько ПО соответствует явным требованиям (спецификациям).

Также стоит разобраться с фазами жизненного цикла. ЖЦ – это процедуры и процессы, с которыми сталкивается приложение/система на каждой стадии разработки от зарождения первоначальной идеи до релиза и поддержки. Жизненный цикл есть у любого программного обеспечения.

О качестве

Что собой представляет качество ПО, понятно. Данный процесс имеет несколько «видов» контроля (проверок). Каждый предусматривает свои ключевые особенности:

1. QC – контроль качества продукта (системы). Представляет собой анализ результатов тестирования и качества новых версия проекта. К его задачам относят проверку: готовности приложения к релизу, соответствие требований и качества.
2. QA – это обеспечение качества продукта. Отражает процесс изучения возможностей по внесению изменений и улучшению разработки. Позволяет делать связи в команде программистов лучше. Это помогает повысить эффективность тестирования. Среди своих задач выделяет: непосредственное тестирование, проверку технических характеристики, оценку возможных рисков, планирование задач для улучшения (ускорения) выпуска продукта. Предусматривает анализ полученных в ходе тестов результатов. За счет QA удается составить отчеты и другие документы по системе.

Выше – таблица, которая поможет лучше разобраться в соответствующих процессах.

Принципы организации

Рассматривая основы тестирования ПО и систем, нужно разобраться в принципах изучаемых комплексов мероприятий:

1. Тестирование указывает на наличие дефектов. Оно может указать на то, что в процессе разработки присутствует тот или иной дефект. А вот доказать отсутствие таких неполадок – нет. Проверка ПО снижает вероятность наличия дефектов, но вот то, что их нет, гарантировать никак не может.
2. Исчерпывающие проверки системе недостижимы. Полное тестирование с использованием всех комбинаций вводов и предусловий выполнить физически не получится. Исключение – нетривиальные задачи. Вместо исчерпывающего «анализа» нужно использовать оценивание рисков и расстановку приоритетов. Такой подход позволяет сконцентрироваться на более точном получении итогового результата.
3. Раннее тестирование. Проверки должны начинаться как можно раньше в жизненном цикле программного обеспечения. Это помогает быстрее обнаружить неполадки. Фокусироваться такие тесты должны на конкретных целях.
4. Скопление дефектов. Разные системные модули содержат различные дефекты – не только по типу, но и по количеству. Плотность скопления неполадок и сбоев в разных частых кода может варьироваться. Условия по тестированию систем должны распределяться пропорционально плотности обнаруженных дефектов. Основная часть критических ошибок приходится на ограниченное число модулей системы.
5. «Пестицидный» парадокс. При прогоне одних и тех же тестов несколько раз, в конечном итоге набор тестовых сценарием перестанет находить новые дефекты. Чтобы избавиться от этого парадокса, сценарии должны регулярно рецензироваться и изменяться. Новые тесты, формируемые специалистами, обязательно становятся разносторонними. Это помогает охватить все компоненты системы с целью обнаружения большего количества дефектов.
6. Зависимость от контекста. Тесты выполняются по-разному. Все зависит от того, какой контекст изначально заложен. Пример – программный продукт, для которого на передовой находится безопасность, будет проверяться на работоспособность иначе, чем обычный информационно-новостной портал.
7. Заблуждение об отсутствии неполадок. При тестировании не всегда обнаруживаются неполадки и ошибки. Это не значит, что система подготовлена на все 100% к релизу. Может получиться так, что дефекты будут критическими и скрытыми. Проект должен не только не иметь неполадок (особенно если речь идет о масштабной разработке), но и быть удобным для использования потребителями.

После изучения принципов «анализа работоспособности» системы можно перейти к более сложным процессам. Пример – рассмотрение жизненного цикла, рассмотрение ключевых видов тестирования.

Этапы

Для выполнения тестов и отладки системы, нужно организовывать процессы правильно. Существует некий алгоритм, отражающий этапы тестирования:

1. Анализ имеющегося продукта. Это – первоначальная идея (задумка) проекта.
2. Работа с требованиями. На предыдущем этапе происходит формирование технического задания. Теперь предстоит изучить его и доработать, если это необходимо.
3. Разработка стратегий тестирования и планирование процедур по контролю качества.
4. Создание тестовой документации. Это – этап, на котором формируется «отчетность» для тестировщиков. Вспомогательные документы, опираясь на которые, специалисты будут грамотно выстраивать процессы.
5. Тестирование прототипов.
6. Основной этап проверок. Здесь выявляется полноценная работоспособность приложения, а также соответствие первоначальным требованиям заказчика.
7. Стабилизация и отладка.
8. Релиз и эксплуатация.

Именно такой алгоритм используется в системах и приложениях. Он помогает не сбиться с намеченного плана даже в самых крупных проектах.

Жизненный цикл

Стадии разработки программного обеспечения – это этапы (шаги), которые проходят команды разработчиков перед тем, как проект станет доступным для широкого круга пользователей. Разработка начинается с первоначального этапа процесса (пре-альфа), продолжается поэтапно. На каждом очередном «шаге» контент будет дорабатываться, модернизироваться. Финальная стадия – выпуск окончательной версии системы или ПО.

Жизненный цикл можно представить похожим на этапы тестирования. Он обычно включает в себя:

• непосредственный анализ требований к приложению или системе;
• проектирование;
• реализацию;
• тестирование;
• внедрение и поддержку.

Каждая стадия получает свое «имя» или порядковый номер: пре-альфа, альфа, бета, релиз-кандидат, релиз, а также пост-релиз.

Основные требования

Когда с общим представлением тестирования программ удалось ознакомиться, можно приступать к более сложным задачам. Рассматриваемые операции имеют требова ния. Это – спецификации (описания) того, что должно быть реализовано в ходе разработки системы/продукта. Описывают моменты, которые нужно воплотить в жизнь, не отражая техническую детализацию.

Сюда можно отнести следующие критерии:

1. Корректность. Каждое требование обязательно точно описывает желаемые инструменты и функции.
2. Проверяемость. Требование формулируется так, чтобы существовали способы однозадачной проверки на факт выполнения.
3. Полнота. Каждое описание содержит информацию, которой достаточно разработчику для грамотной реализации того или иного функционала.
4. Недвусмысленность. Сформулированные описания являются понятными. Они трактуются только одним способом. Неоднозначные аббревиатуры и выражения в них отсутствуют.
5. Непротиворечивость. Описание не должно содержать внутренних противоречий. То же самое касается «несоответствий» техническому заданию и иным документам.
6. Приоритетность. Приоритет требования представлен количественной оценкой степени важности.
7. Атомарность. Описание нельзя разделить на более мелкие без потери завершенности. Каждое требование описывает всего одну ситуацию.
8. Модифицируемость. Указывает на простоту внесения изменений в отдельные описания или их наборы.
9. Возможность отслеживания. Каждое описание имеет уникальный идентификатор. Он помогает обнаружить требование при необходимости.

Описание не может быть необязательным. Это – явное противоречие самому замыслу требований к тестированию.

Виды

1. Тестирование программ может быть разным. Классифицировать этот процесс можно по различным признакам. Ниже – основные варианты.
2. Функциональные типы: функциональное тестирование, проверка пользовательского интерфейса, анализ систем безопасности, тестирование взаимодействия.
3. Нефункциональное тестирование: все виды проверки производительности (нагрузочное, стрессовое, стабильности или надежности, объемное), проверка установок и удобства пользования, тестирование на отказ и восстановление. Сюда также относят конфигурационные проверки.
4. Связанные с изменениями: дымовое, регрессионное, повторное тестирование. К данной категории относят проверку сборки и согласованности (исправности) системы.

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

Функциональное тестирование

Рассматривает заранее указанное поведение. Базируется на анализе спецификаций функциональности компонентом или систем. Позволяет проверить ключевые задачи проекта.

Проверка пользовательского интерфейса

Называется GUI Testing. Позволяет провести функциональную проверку интерфейса. Это – то, что позволяет понять, насколько получившийся контент соответствует изначальной задаче. Сюда относят анализ размера интерфейса, шрифтов, меню и других особенностей.

Тестирование безопасности

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

Проверка работоспособности

Процессы, направленные на анализ способности системы взаимодействовать с одним или несколькими приложениями (компонентами). Предусматривает дополнительно проверку совместимости, а также интеграционное тестирование.

Нагрузочные проверки

Нагрузочное тестирование. Базируется на автоматизации. Позволяет проверить автоматически, как бизнес-пользователи будут работать на том или ином ресурсе. Это – имитация поведения потенциальной целевой аудитории.

Стрессовые тесты

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

Объемное тестирование

Это – получение оценки производительности. В основе заложено увеличение объемов обрабатываемой в БД информации программы.

Тест надежности

Проводится для того, чтобы удостовериться в работоспособности системы. Предусматриваются ситуации, при которых клиент использует проект длительно. Нагрузка здесь – средняя.

Проверка установок

Проверяется успешная установка и настройка. Данный вариант предусматривает анализ обновлений (насколько хорошо, быстро и точно они инициализируются), а также удаления проекта.

Удобство пользования

Метод, направленные на установку степени удобства системы, обучаемости и понятности. Показывает, насколько легко управляться с системой или программным продуктом в заданных условиях.

Отказ и восстановление

Проверяет:

• способность системы противостоять сбоям;
• насколько в случае неполадок проект способен восстанавливаться;
• будет ли оборудование отключаться при багах;
• какие могут быть неполадки (пример – сбой связи), к чему именно они приводят.

Данный тест позволяет продумать концепции, реализация которых сохранит при сбоях в системе ее работоспособность.

Конфигурационные проверки

Специальный вид «анализа». Он направлен на проверку работы системы при применении разного рода настроек системы. Пример – разнообразные ОС или драйверах.

Дымовые тесты

Это с точки зрения «анализа процессов» — короткие циклы тестов. Они помогают удостовериться в том, что после сборки код будет работать и выполнять заданные функции. В основном используется при обновлениях и доработках.

Регрессионные тесты

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

Повторные тесты

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

Тесты сборок

Направлены на соответствие выпущенной версии критериям качества в начале тестирования. Это – аналог «дымового» подхода.

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

Узконаправленный «анализ». Его хватает для того, чтобы показать, что конкретная функция работает согласно задумке. Это – подмножество регрессионного тестирования. Позволяет понять, насколько определенная часть системы остается работоспособной после внедрения обновлений в коде или окружающей среде.

Иные виды

Каждый тестировщик говорит о том, что тестирование систем и ПО бывает разным. Способов классификации очень много. Кроме перечисленных вариантов можно выделить:

1. Статическое тестирование. Код не будет выполняться. Все проверки осуществляются вручную. Направлено на повышение качества итогового продукта.
2. Динамическое. Это – выполнение кода. Нацелено на функциональное поведение системы, использование памяти, общую производительность. Позволяет подтвердить то, что проект работает согласно задумке.
3. Ручное тестирование систем. Начинать и организовывать анализ проекта придется вручную. Долгий и затратный процесс.
4. Автоматизированный вариант. Хотя ручное тестирование до сих пор есть, на передовую выходить автоматизация. Это – проверка работоспособности ПО при помощи специальных приложений и функций.
5. Позитивные тесты. Здесь применяются только корректные электронные материалы.
6. Негативные тесты. Проверка системы, при которой используются некорректные данные. Выполнять будут «неправильные» операции.
7. Модульный подход. Проверка логически выделенного и изолированного компонента системы.
8. Интеграционный вариант. Проверяет, насколько несколько модулей системы хорошо взаимодействуют друг с другом и иными частями ПО.

Основы тестов изучены. Перед тем, как начать проверку работоспособности, нужно обратить внимание на типы «анализа». Без них специалисту не обойтись.

О типах

Существует тестирование белого ящика. Это – метод, который предполагает, что внутренняя структура, устройство и реализация известны специалисту. Сюда можно отнести проверки, базирующиеся на анализе внутренней структуры элемента/системы, а также тест-дизайн.

Есть тестирование серого ящика. Метод, предполагающий сочетание «черного» и «белого» ящиков. Внутреннее устройство программы будет известно лишь частично.

Тестирование черного ящика – тест, базирующийся на спецификации. Является тестированием поведения.

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

Стадии тестирования ПО, его ключевые виды и иные особенности рассмотрены. Тестировщик – это специалист, которые проверяет системы и приложения. Обычно непосредственной разработкой такой человек не занимается.

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

P. S. Большой выбор курсов по тестированию есть и в Otus. Есть варианты как для продвинутых, так и для начинающих пользователей.

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

• Задачи на online-алгоритмы, т.е. такие алгоритмы, которые не читают все входные данные сразу, а могут читать их только по мере своей работы. Простой пример: задано множество из n чисел. Надо обработать n запростов. Каждый запрос содержит элемент множества, до обработки запроса надо вывести минимум чисел в множестве, а потом удалить этот элемент. Естественно, после последнего запроса множества станет пустым. Если решать эту задачу как офлайн-задачу, то можно решать ее <<с конца>>, обрабатывая запросы от последнего к первому (т.е. фактически добавляя в множество элементы). В таком случае решение совсем тривиально. Онлайн-формулировка не позволяет решению прочитать очередной запрос до обработки предыдущего, что вынуждает писать решение, обрабатывающее запросы в прямом порядке. В таком случае необходима структура данных типа std::set в С++ для поддержания минимума в динамическом множестве.
• Задачи на игры. В таком случае участнику надо написать программу, которая делает какие-то ходы, а ответы на эти ходы зависят от того, как именно сходила программа. Здесь в качестве игр могут выступать не только типичные игры, но и «угадайки». Например: было загадано число от 1 до n. Программа участника пытается его угадать, а интерактивный модуль отвечает больше или меньше загаданное число очередной попытки участника. Требуется отгадать число, сделав не более попыток. В качестве решения здесь участник может использовать бинарный поиск.

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

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

Пакет задачи состоит из:

1. Одного или нескольких тестов, возможно с ответами (на картинке это файл file.in и file.a). В качестве ответов обычно используются выводы интерактора при тестировании модельных авторских решений.
2. Интерактивного модуля (сокращенно, интерактора) — специальной программы, которая <<общается>> с решением.
3. Тестирующей программы (чекера).
4. Крайне желательно наличие авторского решения.
5. Крайне желательно наличие специальной программы — валидатора. Валидатор получает на вход текст теста (file.in) и возвращается с кодом возврата 0 тогда и только тогда, когда тест корректен. Здесь есть хитрость, так как по-идее еще надо валидировать непосредственно данные, отосланные решению (стрелочка от интерактора к решению stdout-stdin). В настоящий момент такую валидацию лучше встраивать в интерактор.

Как происходит запуск решения и его оценка в интерактивной задаче.

1. Сначала запускается в <<связке>> одновременно решение и интерактор. На решение как обычно наложены традиционные ограничения на время и память. На интерактор похожие ограничения тоже должны быть наложены, но довольно лояльные (например, 15 секунд/256MB). Интерактор запускается с теми же параметрами командной строки, что и обычный чекер — именем файла для чтения описания теста (в схеме file.in), именем файла для вывода информации о результатах взаимодействия (в схеме file.out), именем файла с ответом (в схеме file.a). Возможны дополнительные классические параметры testlib, если интерактор написан на нем.
2. Ждем события, что один из процессов завершился (сам собой или был прерван).
3. Первый случай, первым завершилось решение:
   • Если завершилось по причине превышения каких-то ограничений, то сразу возвращаем вердикт Time Limit Exceeded, Memory Limit Exceeded или Idleness Limit Exceeded (последний, если программа продолжительное время вообще не расходовала процессорное время).
   • Если завершилось с кодом возврата неравным 0, то возвращаем Runtime Error.
   • Если завершилось благополучно и с кодом 0, то продолжаем ждать пока завершится интерактор.
4. Второй случай, первым завершился интерактор:
   • Если завершился по причине превышения каких-то ограничений, то сразу возвращаем вердикт Judgement Failed.
   • Если завершился с кодом возврата неравным 0, то обрабатываем его как обычный чекер:
     • код 1: возвращаем вердикт Wrong Answer,
     • код 2: возвращаем вердикт Wrong Answer (или Presentation Error, если такой вердикт поддерживается),
     • код 3 или любой другой: возвращаем Judgement Failed.
   • В случае любого из ненулевых кодов возврата, вывод интерактора на стандартный поток ошибок (stderr) следует считать комментарием тестирующей системы о тестировании на этом тесте.
   • Если интерактор вернулся с кодом 0, то ждем завершения решения. Применяем к нему пункты о превышении ограничений или ненулевом коде возврата из предыдущего пункта. Таким образом, считаем, что оно благополучно завершилось с кодом 0.
5. Ждем завершения второго процесса, считаем, что он благополучно завершился с кодом 0, иначе вердикт очевиден.
6. Запускаем чекер, передавая ему в качестве аргументов file.in (описание теста), file.out (вывод интерактора) и, если есть, file.a (файл ответа). Таким образом, командная строка запуска имеет вид: check file.in file.out или check file.in file.out file.a. Чекер запускаем с лояльными ограничениями (например, 15 секунд/256 MB). Ждем завершения процесса. Если ограничения были превышены, то возвращаем Judgement Failed. В противном случае смотрим на код возврата:
   • код 0: возвращаем вердикт OK,
   • код 1: возвращаем вердикт Wrong Answer,
   • код 2: возвращаем вердикт Wrong Answer (или Presentation Error, если такой вердикт поддерживается),
   • код 3 или любой другой: возвращаем Judgement Failed.
7. В случае любого из ненулевых кодов возврата, объединенный вывод чекера на стандартный поток вывода (stdout) и ошибок (stderr) следует считать комментарием тестирующей системы о тестировании на этом тесте.

Некоторые тестирующие системы используют альтернативные способы получения информации о вердикте после запуска чекера. Например:

1. PCMS2 считает, что чекер всегда должнен возвращаться с кодом 0, а его вердикт считывается из специального XML-файлика.
2. EJUDGE имеет свою собственную систему кодов возврата, несовместимую с общеприятой.

По этой причине настоятельно рекомендуется использовать testlib для разработки как чекера, так и интерактора, чтобы инкапсулировать способ передачи вердикта в проверенную совместимую библиотеку.

Вот пример простого интерактора под testlib.h, который делает задачу A+B интерактивной:

#include "testlib.h"
#include <iostream>

using namespace std;

int main(int argc, char* argv[])
{
    setName("Interactor A+B");
    registerInteraction(argc, argv);
    
    // reads number of queries from test file
    int n = inf.readInt();
    for (int i = 0; i < n; i++)
    {
        // reads query from test file
        int a = inf.readInt();
        int b = inf.readInt();

        // writes query to the solution, endl makes flush
        cout << a << " " << b << endl;

        // writes output file to be verified by checker later
        tout << ouf.readInt() << endl;
    }

    // just message
    quitf(_ok, "%d queries processed", n);
}

В данном случае не имеет смысла встраивать логику проверки в интерактор, хотя это возможно сделать. В некотором смысле она в нем имеется, например он может остановиться с вердиктом PE, не найдя ответа на очередной запрос (программа участника завершилась досрочно).

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