iramind

Недавно столкнулась с ситуацией, когда на вопрос руководителю проекта «Что вам полезнее знать, прошли ли тесты или стабильна ли функциональность, которую они проверяют?» в ответ получила замешательство.

Сам по себе тестовый сценарий, это способ проверки чего-либо. Когда мы составляем сценарии тестирования, то, по сути, определяемся, как мы поймём, что функциональность работает, работает так, как надо, работает стабильно.

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

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

Пример:
Тестеровщик говорит: «всё проверил, все тест-кейсы пройдены успешно». Можем ли мы сказать, что функциональность готова? Нет! Точнее можем, но для этого нам подтребуется удостовериться в том, что используемый набор тестов полностью покрывал тестируемую область.
или так:
Тестеровщик говорит: «всё проверил, функционирование системы возможно, но в стрессовых словиях возможны сбои и потери данных».

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

Почему возникает необходимость задуматься об этом? Да просто потому, что это необходимо помнить постоянно.
Это относится и к тестам, проводимым вручную, и к автоматизированным тестам.

Главная цель теста - это диагностика, иными словами, ответ на вопрос - работает ли. Очень важно, чтобы тест отвечал только на один вопрос в один момент. Очень важно, чтобы этот вопрос был ясен всем заинтересованым лицам.

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

Зачем проверять, поместится ли в кастрюлю 5 литров воды, если у кастрюли дна нет?

Автоматизация тестирования делиться на два этапа – создание тестов и их использование. При этом хорошая работа на первом этапе стремится упростить работу на втором. Не только упростить, но и сделать её эффективнее.

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

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

Итак, обо всем по порядку.

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

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

Но далее нам понадобится определиться с тем, в каком порядке эти тесты нужно запускать. Очень удобным будет зафиксировать разные варианты последовательностей запуска тестов. Сделать списки наподобие PlayList в программе winamp.

Приведу пару примеров:

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

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

Накопленный опыт позволяет предложить следующий вариант  группировки тестов.

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

•                     Functional
Это основная группа. Группа функциональных тестов. Тесты в этой группе проверяют правильность выполнения операций при запланированном поведении пользователя.
Группа это большая и рекомендуется разбивать её на подгруппы в соответствии с тестируемыми модулями системы.

o       Module 1

o       Module 2

o       …

•                     Functional board and out of board
Это аналог предыдущей группы, но в условиях некорректного поведения пользователя. Например, попытками сохранить недопустимые значения или выполнить недопустимую операцию и т.п.
Иногда эти тесты могут проводиться совместно с описанными выше функциональными тестами.
Группа это также большая и рекомендуется разбивать её на подгруппы в соответствии с тестируемыми модулями системы.

o       Module 1

o       Module 2

o       …

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

Атомарность проверяемых действий

Правило: Один тест должен проверять одно действие.

И соответствие теста проверяемому действию должно быть однозначным. Иными словами, и тот, кто пишет тест, и тот, кто его использует должны четко представлять себе, что именно проверяется этим тестом. Идеальным (и скорее всего необходимым) будет условие, чтобы для каждого теста существовал такой вопрос, на который этот тест всегда мог дать ответ «Да» или «Нет».

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

1.      нажать кнопку, чтобы открыть форму создания объекта,

2.      заполнить её,

3.      нажать кнопку сохранить,

4.      проверить, что новый объект отображается в нужном списке.

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

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

Независимость тестов

Правило: Тест должен быть независим в некотором контексте.

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

Приведу пример. Предположим нам необходимо написать тесты для приложения, состоящего из двух логических частей (например, работа со списком объектов и работа внутри одного объекта). Все тесты у нас непременно разделятся как минимум на две группы: тесты для списка объектов и тесты для одного объекта. Назовём эти группы контекстами. Так работая в одном контексте (например, со списком объектов) мы должны составить несколько тестов, которые должны иметь возможность запускаться не зависимо от того, какой тест был запущен ранее.

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

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

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

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

Стабильность тестов

Правило: Тесты должны быть стабильнее тестируемого приложения.

            Это означает две вещи:

во-первых, тест не должен падать там, где не падает тестируемое приложение (в том числе не должен врать),

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

Модифицируемость тестов

Правило: Изменение тестов после изменения тестируемого приложения должно занимать как можно меньше времени и усилий.

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

            Приведу примеры

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

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

Мобильность тестов

Правило: Зависимость тестов от условий окружения должна быть минимально возможной.

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

            Причины переноса могут быть разные, и все, пожалуй, не учтешь. Но пример привести можно.

            Во-первых написание авто-тестов может быть делом длительным, и делать его лучше на своём рабочем месте.

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

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

Результаты тестов.

Правило: Результаты тестов должны быть информативны и удобны.

            Результат – это цель теста, итог его работы. Тест запускается для того, чтобы получить результат.

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

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

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

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

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

Что к ней приводит?

Однообразие! Однообразие! и ещё раз Однообразие!
Человек, наверное, так устроен, что абсолютный покой - это то, к чему он часто стремится, и то, в чем он жить не может. Если выполняя одну задачу, я не буду знать, что за ней следует другая, отличная от текущей, полезная и интересная, работать я буду без особого стремления.
Замечено: после того, как человек теряет направление развития в одном деле (на работе), он находит его в другом (дом, хобби...). В этом случае первое выполняется как необходимая традиция, без лишнего энтузиазма.
Помните сказку "дудочка и кувшинчик"? "Одну ягодку беру, на другую смотрю, третью замечаю, а четвертая мерещится". Смысл тот же самый. Только ягодки - это задачи, которые перед нами стоят.

Есть и противоположная причина - перегрузка.
Что я имею ввиду? Ситуацию, когда человек долго работает "на пределе" своих возможностей. Это могут быть различные пределы - интеллектуальный, эмоциональный, физический.
Голова: Если перед человеком постоянно стоят задачи, решение которых ему дается не легко, есть вероятность, что ему рано или поздно придёт в голову светлая мысль послать всё это подальше. Я не призываю не ставить таких задач вообще, они очень нужны. Но между ними обязательно должен быть заполненный перерыв. Причем именно заполненный - пусть это будет задача полегче.
Эмоции: Если человек долго работает на грани нервного срыва, пользы его работе это не принесет. Я согласна, что периодические "встряски" организму необходимы. Да и для дела спортивная злость полезна. Но держать человека в таком состоянии нельзя. Конечно, можно сказать, что у сотрудников есть отпуска, в них они и обязаны отдыхать и приводить себя, так сказать, в боевую готовность. Но это подход формальный, и даже, если хотите, бюрократический. Задачи на проекте должны планироваться с учетом и этого фактора тоже.
Тело: Физическая нагрузка в ИТ индустрии не так явна, но тем не менее заметна. Это могут быть рабочие задачи, часто требующие от человека боевой готовности рано утром и поздно вечером, которые не могут не оставить своего следа на работоспособности.

Как предупреждать усталость от проекта?

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

Что делать если уже устал?

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

Тем, кто хоть сколько-нибудь серьезно сталкивался  с тестироанием ПО, не раз приходилось задавать себе этот вопрос. И ответ на него далеко не всегда однозначен. Почему?

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

• Что включают в себя тесты?

(дело в том, что даже этот простой термин, часто понимается по-разному тестером, программистом и руководителем)
 

• Зачем предполагается автоматизировать?

(иногда авто-тесты пытаются рассматривать как замену живого тестера, что мне кажется, просто невежетсвом)
 

• Как представляется сам процесс автоматизации?
   (время и трудозатраты - сколько их нужно, в какой момент, как это зависит от разработки ... и пр.)