Зачем необходимо хранить тесты если программа уже выпущена

веденному выше крит ерию – перебор всех возм ожных входных значений .

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

должен включать р авносторонние треугольники с длинами сторон вплоть

до максимального цел ого чи сла . Это , безусловно , астрономическое чис —

ло , но и оно не обеспечивает по лноту пр ове рки . Вполне вероятно , что ос —

танутся нек оторые

ош ибки , например , метод может пр едставить тре —

угольни к со сторонами 3, 4, 5 неразносторон ним , а со сторонами 2, А , 2 –

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

перебрать не только все разу мные , но и все вообще возможные входные

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

тестиров ания задачи о треугол ьниках требу ется бе сконечн ое число тестов .

Если такое испытание представляется слож ным , то еще сло жнее соз —

дать исчер пывающий тест для большо й программы . Образно говоря , чис —

Почему тесты IQ не могут измерить интеллект

ло тестов можно оценить « числом , большим , чем бесконечность ». Допу с —

тим , что делается по пытка тестирования методом черного ящика компи —

лятора с языка Java. Для построения исчер пывающ его теста ну жно ис —

пользовать все множество правильных прог рам м на

Java ( фактически их

число бесконечно ) и все множество неправильных прог рамм ( т . е . дейст —

вительно бесконечное число ), чтобы убедить ся в том , что компилят ор

обнаруживает все ошиб ки . Только в этом случае синтаксически невер ная

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

ну ю памя ть ( напр имер , операционная система , база данных ил и система

распределенных вычислений ),

то дело обстоит еще хуже . В таких пр о —

граммах исполнени е команды ( напр имер , задание , запрос в базу данных ,

выполнение расчета ) зависит от то го , какие события ей пр едшествовали ,

т . е . от предыдущих ком анд . Здесь следу ет перебрать не только все воз —

можные команды , но и вс е их возможные последовательности .

Из изложенного следует , что построение

исчерпывающего входного

теста невоз можно . Это подтверждается дву мя аргу ментами : во — первых ,

Источник: www.studmed.ru

Зачем необходимо хранить тесты если программа уже выпущена

Когда-то в юности я начала работать сотрудницей отдела тестирования в одной компании. Тестовая документация там существовала в виде чек-листов в Excel и каких-то требований на 1-2 странички для разработчиков, куда также иногда могли заглянуть и тестировщики. Со временем компания перестала выделять время на написание ЧЛ, но документация для разработчиков все еще оставалась в более или менее достойном виде. Так как компания занималась обычной разработкой программного обеспечения для мобильных устройств, то поддерживать актуальной тестовую документацию и вообще её создавать для тестировщиков оказалось накладно. Спецификация стала редкостью.

Зачем и как писать качественные Unit-тесты — Алексей Солодкий (Badoo)

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

— Мы закончили делать in-app покупку тем!
— Ad-hoc сборка уже собралась! Через час надо выложить!
— Ещё мы критические баги исправили и вот эту “штуковину” засунули в код.
— Прогоните какой-то смоук, вдруг что-то сломалось!
— и т. д.

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

— Слушайте, а кто-нибудь помнит, что тут было? Кто-то знает, как оно должно работать?
— Не помню уже. Надо спросить у разработчиков…
— Хм… Думаешь, я помню, что я делал три месяца назад? У меня 5 приложений! Я уже не помню, где и что я когда-то писал…
… (время уходит)
— Да не знаю. Ну, пусть так будет.
— У меня твой баг не повторяется. А-а-а… ты э-э-ту кнопку нажимаешь при выходе. А я всегда ту нажимаю…
— Слушай, а ты не помнишь, как мы проверяли такие подписки? И вот это каким должно быть? Кажется, оно не должно быть таким… Не помню.

И спросить не у кого. Специалистов, которые бы занимались документацией, нет. Тестировщиками часто проводилось полное тестирование приложения, что отнимало много времени – целые недели, а иногда, и месяцы. И на вопрос: “Когда вы закончите проверять?”, следовал ответ: “Критические баги лезуууут!” Не было четкого понимания, сколько времени необходимо для тестирования программы. А время, как известно, – деньги. В итоге получалось нечто, что начинало жить своей жизнью…

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

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

Давайте напишем нормально.

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

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

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

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

В каком виде и для чего нужна тестовая документация?

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

Рабочая проектная документация, используемая тестировщиками

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

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

ЧТЗ (частное техническое задание) – создается на основе ТЗ. Обычно содержит полное описание конкретной части разрабатываемого продукта и ВИ (варианты использования, сценарии использования предмета разработки пользователями, макеты разрабатываемой части предмета разработки, его логику и суть).

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

ЧТЗ и ТЗ можно отобразить:

• в текстовом виде с картинками

в виде графического шаблона-таблицы

в виде интеллект-карт, UML или подобного алгоритма

Проектная документация, подготавливаемая тестировщиками

ЧЛ (чек-лист) – список того, что нужно проверить.

• Помогает планировать сроки окончания работ в будущем и настоящем, т.к. в ЧЛ можно указать, сколько времени необходимо для проверки и сколько было затрачено.
• Хранит историю пройденных тестов. Можно будет легко вспомнить, какие именно тесты проходили с ошибками, и перепроверить именно их.
• ЧЛ с результатами наглядно показывает любому сотруднику компании текущее состояние разрабатываемого продукта. Помогает определить его степень готовности.
• Помогает помнить, что уже было проверено, а что нет.
• Помогает не забыть, какие тесты необходимо выполнить в первую очередь, какие во вторую, какие в третью и т. д. Это рождает уверенность, что за определенное запланированное время самые важные тесты будут проведены, а результаты по ним — получены.

Чек-листы можно записать:

• в виде таблиц (удобно в Google Sheets)

в виде интеллект-карт (удобно в XMind)

в виде списка проверок в специально предназначенной системе (удобно в Sitechco)

в виде списка в текстовом документе, который привычен.

ТК (тест-кейс) – создается на основе ЧТЗ (если оно есть) тест-аналитиками и тестировщиками.

• Совместно с ЧЛ может хранить историю тестирования и отображать, что именно и как тестировалось. Можно убедиться, что та или иная функциональность обязательно была или будет проверена и затронута при тестировании.
• Помогает быстро включить в работу новых сотрудников. Сотруднику не обязательно неделями изучать предмет разработки, ему будет достаточно открыть сохраненный ТК и пройти его по шагам так же, как проходил другой опытный специалист, ранее работавший в компании.
• Помогает увидеть как предмет разработки (программа, сайт и т. п.) должен выглядеть. С имеющимися скриншотами экранов, если они есть, можно будет не забыть о том, что “вон та” кнопка должна быть серой, а не красной.

Тест-кейсы можно отобразить:

• в виде таблицы с текстовыми данными

в специальном сервисе для ведения тест-кейсов (например, в TestLink).

Отчет о тестировании – письменный или медийный отчёт о проделанной работе и ее результате.

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

Пример отчета в письменном виде:

Как определить, какую именно документацию необходимо внедрить в проект?

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

На проекте до 15 человек (проекты низкой сложности):

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

На проекте от 15 до 50 человек (проекты средней сложности):

• техническое задание;
• чек-листы;
• тест-кейсы;
• база знаний (например, в Wiki);
• отчеты в виде письма с приложенным пройденным ЧЛ с указанием критических багов.

Большой проект – от 50 человек и больше (проекты высокой сложности):

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

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

Что делать, если написание документации занимает много времени?

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

Источник: quality-lab.ru

Выбор хорошего инструмента для хранения тест документации и сравнительный анализ 3 выбранных инструментов

Ведение документации для тестирования в Google-доках и Google-таблицах — не лучший способ работы с тестовой документацией. Такой подход имеет свои недостатки.

В этой статье я расскажу, как мы перешли от хранения тестовой документации с Google docs к специализированным SaaS-решениям, сделаю сравнение трех разных инструментов (HipTest, Leantesting, Test Management for Jira) и поделюсь результатами такого перехода.

Меня зовут Татьяна и уже 2,5 года я работаю в компании Englishdom на позиции qa engineer. Мы — онлайн-школа английского языка, и наш IT-отдел разрабатывает уникальную цифровую платформу — учебник для изучения английского, а также несколько приложений для тренировок и домашних заданий. QA-команда тестирует эти продукты и для этого мы ведем документацию.

Использование Google-доков и Google-таблиц имеет свои преимущества:

• бесплатные ресурсы без ограничений;
• легкая адаптация — так как таблицы — простой и понятный инструмент.

Но у такого подхода есть и свои недостатки:

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

Когда я пришла на работу в проект Englishdom, в качестве тестовой документации мы как раз использовали чек-листы в Google-таблицах и в Confluence. Из-за недостатков, описанных выше, одной из главных задач для улучшения процессов был переход с чек-листов на тест-кейсы. А для этого требовался хороший инструмент для их хранения и управления.

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

• избегание переезда или нежелание переноса множества тестов на другой инструмент;
• дискомфорт при выходе из зоны комфорта и получении непривычного нового опыта;
• отсутствие необходимого бюджета, т.к. почти все Test Case Management Tools — платные;
• выбор self-hosted, а не saas-cloud решений для Test Case Management System, что также является платным, и может быть проблемой ввиду отсутствия или ограниченности бюджета;
• имеются сложности договориться с менеджментом о необходимости или стоимости для такого инструмента.

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

HipTest

Дальше настало время экспериментов. Первый инструмент, который мы решили попробовать — это HipTest . Представлю краткий его обзор.

Преимущества:

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

Недостатки:

• создание и редактирование сценариев и action words (при создании новых шагов-действий можно квалифицировать их как шаг, ожидаемый результат или многоразовое действие, это называется action words в HipTest) возможно только в HipTest, а редактор там специфичный. Чтобы понять, нужно попробовать и сравнить с блокнотом или, скажем, с google docs/sheets;
• массовый быстрый рефакторинг сценариев не получится так же, как это легко можно делать в текстовых редакторах;
• необходимо быть аккуратным с переименованием (случайным или нет) action words, т.к. в случае, если сценарий уже автоматизирован, то переименование только в HipTest приводит к упавшему тесту, потому что в части реализации наш action word остался с прежним именем;
• нет возможности прикреплять скриншот к step, а только ко всему тест-кейсу.

Пример тестового сценария в hiptest

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

P.S. В моем рассказе HipTest представлен в том виде, который был на момент нашего использования. На данный момент HipTest объединен с Cucumber под одним брендом, запустив CucumberStudio и новый улучшенный веб-сайт Cucumber.io. Однако теперь инструмент платный.

LEANTESTING

Итак, поиски инструмента продолжились. Следующим был вариант — https://leantesting.com/ (по сути это бесплатный аналог Test Rail, однако есть возможность приобрести расширенные возможности за дополнительную плату. Сейчас мы рассмотрим особенности бесплатной версии.

Пример тестового сценария в LeanTesting

Преимущества:

• неограниченное количество пользователей;
• неограниченное количество проектов;
• неограниченное количество тестов и тест сайклов;
• удобные отчеты;
• в новом обновлении Lean Testing может запускать автоматизированные тесты с Selenium.

Недостатки:

• интеграция с другими вебхуками (например, Slack, GitGub, BitBucket ) платная;
• настройка пользовательских статусов и типов ошибок также платная;
• нет интеграции с какими-либо системами баг-трекеров (в нашем случае Jira);
• скриншот можно прикрепить только к тест-кейсу в целом, но не к шагам;
• нет возможности импортировать тест-кейсы из других Test Case Management Tools или Excel.

Изначально приняв решение о переходе на этот инструмент, мы видели одно большое преимущество — более удобный пользовательский интерфейс, чем в HipTest, но спустя год активного использования все-таки решили уйти от Lean Testing. Главной причиной для нас на тот момент стало отсутствие интеграции с Jira (на проекте мы активно ее используем для ведения всех задач и, конечно же, было бы удобно хранить все в одном месте) и возможность прикреплять скриншот только ко всему тест-кейсу, а не к каждому шагу. Также на тот момент в бесплатной версии было ограничено количество создаваемых кейсов.

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

Test Management for Jira (TM4J)

Спустя какое-то время поиска выбор пал на Test Management ( https://www.adaptavist.com/doco/display/KT/Test+Management+for+Jira+Server) — встраиваемый в Jira инструмент, простыми словами — плагин.

Преимущества:

• красивые и понятные отчеты в виде диаграмм (но довольно простенькие);
• добавление и удаление статусов к тест-кейсам, тест прогонам и результатам;
• возможность проставлять лейблы, компоненты, приоритеты в каждом кейсе;
• возможность добавлять скрины в каждый шаг тест-кейса (!);
• связь с Jira.

Недостатки:

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

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

Визуализация тест сайклов

Визуализация создания тест-кейса (скрин1)

Визуализация создания тест-кейса (скрин2)

Сравнительный анализ трех инструментов приведен в таблице

Итоги

Методом проб и ошибок мы сменили инструмент, выбрав тот, который оказался самым удобным для нашего проекта, изменили подход к ведению тестовой документации, ее хранению и управлению, забыв про чек-листы в Google-таблицах и полностью перейдя на тест-кейсы в специальной системе Test Management. За все время использования еще ни разу не пожалели о выборе. Ведение тестовой документации прямо в Jira оказалось неимоверно удобным. Такой подход планируем использовать и в будущем.

Совет для тех, кто еще не решился — уходите из Google-доков и переходите на специальные инструменты для тестовой документации. Какой — решать вам, предложений по инструментам действительно много, но точно найдется вариант под ваш проект и ваши цели. Я лишь поделилась историей опыта нашего qa-отдела. Могу сказать, что это сэкономило нам немало времени.

Пара примеров: актуализация, формирование тест-сайкла и распределение ответственных qa раньше занимало приблизительно час, сейчас 40 мин. Также создание бага — раньше занимало до 15 мин, сейчас около 5 мин времени. Итого, экономия времени составила до 30%.

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

• Блог компании EnglishDom
• Тестирование веб-сервисов

Источник: habr.com