- Я стал участником добровольной группы, которая проводит тестирование проекта KommandCore. Это онлайн система для управления проектами, в текущем её состоянии разработчики позиционируют её как площадку для совместной реализации проектов.

- Grig – основатель, идейный вдохновитель и главный реализатор направления программ-расширений в ALSEDI и приложений для MacOS/iPhone начал вести свой блог о iPhone, его приключениях с SDK и Apple в целом.

Общее

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

Объект – Действие – Результат

Объект – это всё что угодно: от расположения точек в картинке, до строк файлов, от кнопок до всей платформы целиком.
Действие – что мы делаем с объектом.
Результат – что получилось в результате действия с объектом.

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

Термины

В зависимости от продукта они разные, но это и понятно. Точное название зачастую могут дать разработчики, и если вы стопроцентно не уверены как правильно называется элемент – спросите девелопера, ткните девелопера, кусите девелопера, порвите его как грелку, но точное название должно быть.
Будьте внимательны и используйте правильно следующие термины «Panel» и «Form» (группировка и интерактивность), «Window» и «Dialog» (окно, контролируемое процессом и окно, желающее пользователя). Так же используйте правильно «left» и «right» (лево и право).
Не забывайте, так же что:

• «button» нажимают: «press» или «push»;
• «link» и большую часть элементов кликают: «click»;
• «menu», «menu+tree+list+grid item» выбирают: «select»;
• «check box» и «radio box» выделяют: «check» или «flag»;
• текст вводят: «type» или «enter»;
• информацию и объекты показывают: «show», «display», «pop-up» и иногда «appear» (когда хоба, его никто не ждал, а оно появилось);
• последовательность существительных в английском переводится задом наперёд;
• «number» – это и «integer» и «float» («real»);
• «string» – это и буквы и «number»;
• «number» может включать в себя буквы от «A» до «F» и «E», точки или запятые, как указатель дробной части;
• «text» – это набор «string», обычно со смыслом.

Подходы к написанию тест кейсов.

1. Прямое описание
2. Описание на основе определений
3. Группировка объектов по признаку
4. Зацикливание тест кейса
5. Ссылки на другие тест кейсы
6. Alias
7. Начальные и пост- условия

Частенько они переплетаются в одном тест кейсе.

Прямое описание

В двух словах – это то, что вижу, то и пишу. Удобно, когда сценарий простой, а объекты четко определимы. Если взять главную страницу Google.com (классическое представление), то там можно четко определить следующие элементы:

• Логотип (image)
• Поле ввода (input box, input field)
• Две кнопки (button)
• Группа из двух радио боксов (я не знаю, как правильно перевести radiobox на русский, никогда не задумывался).

Можно так же определить все ссылки, назвав их, но это будет неправильно, потому что они явно представлены в разных блоках и имеют косвенное отношение к главной функции – поиску, но об этом позже.
Имея эти элементы легко составить тест кейсы по проверке формы для поиска:
Step 1. Type “wiki test case” string into input box and press “Google Search” button
Result: New page will be opened in same window with list of sites
Step 2. Check that any word from search phrase present in any part of site representation (in title, description, URI or Sitelinks)
Result: Each site in search results list contains any or few words from search phase

Хозяйке на заметку: «Sitelinks» – это определение используется только в гугл (в контексте показа результатов поиска) и означает небольшой блок из 1 – 8 ссылок на внутренние ресурсы сайта. Причем будет или не будет показываться этот блок для сайта и какие ссылки он будет содержать решают только в Google. Впрочем, если у вас есть доступ в Webmaster Tolls, вы это уже знаете.

Нужно ли писать так много слов? Вовсе нет, можно вообще написать «Type “wiki test case” and press “Google Search” button» и «Verify that search result contains search phrase parts». Еще разок повторю, писать надо так, чтобы было понятно, что сделать, с чем сделать, и какой результат ожидать. А это значит, что использовать слова «corresponding, proper, respective» и прочие со смыслом «правильный» использовать нужно аккуратно. Например, фразы в «Expected Results»: «Respective blank appeared in the left frame» и «Check time» – ничего не значат, и писать надо, например, так «”Budviser Panel” loaded into left frame» и «Check that time format is “HH:MM:SS”, where HH – hours (24h или 12am/pm), MM – minutes, SS – seconds».
В общем и целом в прямом описании сценария нет ничего сложного или заумного, достаточно внимательно описать действия и объекты, при возможности строя новый шаг тест кейса на основе предыдущего, тогда простота описания «Expected result» получится сама собой.

Описание на основе определений

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

У определения есть имя и значения, описывается оно в комментариях тест кейса, например:

“Long Time” format is HH:MM:SS, where HH is hours from 0 to 23, MM are minutes 0-59, SS are seconds 0-59.

После чего «Long Time» можно использовать в тексте тест кейса вместо полного описания.

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

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

Группировка объектов по признаку

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

Step 1: Check property ‘x’ of objects: a) ‘Object a’ b) Object ‘b’ c) Object ‘c’
Expected Result: property ‘x’ is in format of (has value of)

То есть в разных объектах значение, какого-то свойства одинаковое, но при этом объекты могут быть независимыми друг от друга.

Зацикливание тест кейса

Это миф. Тест кейс зацикливать нельзя. То есть писать «Repeat steps 1-3» не стоит. А собственно почему? Только потому, что это прерывает последовательность шагов? Вот фигня то. Тест кейс – это обычный сценарий действий, и если действительно нужно повторить шаг с первого по третий, то почему бы не повторить? Но вот если шаг 1-3 говорит о том, что действие надо сделать с объектом «А», а нужно повторить эти шаги для объекта «Б», тогда придется писать эти шаги снова, но уже для объекта «Б». Так же придется делать, если количество шагов больше семи (магическая цифра, найденная психологами или психиатрами).

Ссылки на другие тест кейсы

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

Alias

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

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

Поэтому в тест кейсах в начальных условиях можно просто написать «User must be logged in», «User must be authorized», «User logged into [] under [] role». Понятно ли что нужно сделать перед тем, как начать работу с тесткейсом? Единственное «но», алиас всё равно должен быть описан где-либо в доступном месте (FAQ к проекту вполне подойдет).

Начальные и пост- условия

Состояние тестируемой системы до и после теста. Что означает «До», в принципе, проблем не должно быть. Я надеюсь. Очень.
После – это то, как изменилась вся или часть системы, когда тест пройден успешно. Это эдакая последняя проверка на то, что даже правильно работающие кусочки, проверенные последовательно не отразились в сумме своей на системе негативно.

Хозяйке на заметку: http://blog.abakas.com/2009/02/look-even-when-you-know.html
Это только начало…

Hide My Windows is an effective tool for hiding your windows and applications away from prying eyes. With a quick keystroke or flick of the mouse, Hide My Windows will ferry away sensitive information from your desktop. Sure, you can minimize windows, but a quick glance at the system tray would let anyone know that you’re playing a game, checking your fantasy league, or watching your retirement portfolio wave bye bye. Hide My Windows leaves no trace of the hidden application whatsoever. Only you know that it’s there.

Don’t forget to click on “Notify Me” on http://www.bitsdujour.com/software/hide-my-windows/

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

Заинтересованные в релизе группы людей

Список вопросов неполный, но QA должны знать ответы хотя бы на них. Для этого, в первую очередь, потребуется отслеживать выполнение задач по разработке и тестированию. Существование трекера первый шаг к построению нормальной информационной системы.
Подойдет любая система трекинга, в которой можно реализовать такую структуру (я предпочитаю Atlassian Jira, для небольших проектов Eventum):

• Backlog – группа проектов в которой по версиям и продуктам разбиваются пожелания и требования бизнес стороны. Это не только спецификации (ТЗ), но и простые заметки, пришедшие от бизнес стороны в стиле «нужно сделать это, примерно вот так функционирует и выглядит». На основе таких «business story» можно построить спецификацию и согласовать с бизнесом.
• Development Project – Группа проектов по разработке конкретных продуктов. Основная часть задач появляется с привязкой к Backlog проекту. Это позволяет отслеживать соответствие требованиям бизнеса и начать работу QA еще до завершения разработки (что-то вроде Test Driving Development, но мягче).
• Feedback – Группа проектов для получения отзывов от клиентов и бизнес стороны по работе текущей версии и проблемам с ними связанным (но не для трекинга багов по разрабатываемой версии).
• QA – Группа проектов, привязанных к таким же проектам в Development Project. В них будет вестись трекинг задач, связанных с тестированием версии или общей работы, но не багов!
• Bugs – Группа проектов, привязанных к проектам в QA и Development Project. Здесь тестировщики создают все таски связанные с найденными ошибками и предлагают улучшения проектов.

Зачем нужно три проекта для QA? Для того, чтобы не создавать мусорной кучи. Feedback доступен не только тестировщикам (которые, по идее, знают о разрабатываемых продуктах больше остальных), но и бизнес стороне. Люди со стороны бизнеса имеют полное право не знать о том, что существует множество версий и множество компонент внутри продуктов, но должны иметь возможность сообщить о проблеме при работе. Для этого им нужно знать только что они делали и версию продукта, с которым они работали (а не всю систему), когда появилась проблема.

Причем, не важен тип решения (а пользователь может и не знать что там еще стоит за окном в которое он смотрит), разрабатываемого компанией:

• самостоятельное приложение;
• серверное приложение с доступом из стороннего (Web сервис, XML/HMTL сервер);
• клиентское приложение с доступом к стороннему (Debuggers, разнообразные сетевые клиенты);
• клиент-серверное приложение, с собственным сервером и клиентом (платформы с удаленным доступом);

Разобраться где конкретно ошибка и ошибка ли дело QA и разработчиков. Часто разработчики могут сделать это быстрее.

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

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

Принципиальная схема процесса при такой структуре проектов выглядит так:

Потоки информации между проектами

При использовании этой схемы Backlog объединяет в себе первичные требования бизнеса, общее обсуждение технической реализации или ТЗ (в зависимости от возможностей), проблемы из Feedback и Bugs, которые требуют много времени на исправление или переработки бизнес логики. Основные задачи в Backlog описывают большие куски работы, разбиение которых делается через сабтаски. Далее эта информация клонируется (или разбивается на части и клонируется) в проекты по разработке и добавляется в задачи по подготовки к тестированию в QA проектах (написание тесткейсов, переработка существующих тестов, автоматизация и так далее). После релиза в соответствующем проекте QA создаётся общая задача на тестирование, а конкретная работа выделяется в сабтаски. При нахождении ошибок при тестировании они описываются в соответствующем проекте Bugs и либо клонируются в Development Project, либо заносятся в Backlog для позднего исправления. Процесс запускается по новой… в идеале.

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

Когда я пришел в компанию, у меня был довольно большой опыт в ведении тестирования (как части QA) и разработки программ. Опыта управления процессом, в котором задействовано много людей и разные команды, практически не было. Фактически, на тот момент «картина мира» для меня выглядела так.

Мифическая организация разработки

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

В большой компании, выпускающей крупные продукты, с разделенными географически офисами (сюда можно включить оффшорные компании и местные (domestic) филиалы компании), эта схема разбивается вдребезги. Всё оказалось намного сложнее. Бизнес сторона не всегда может что-либо спланировать или четко сказать, что нужно сделать. Изолированность оффисов приводит к недостатку коммуникаций и не пониманию реальной ситуации и потребностей. А о технической документации вообще задумываются редко, особенно когда речь заходит о взаимодействии связанных, но разных частей системы (лучший пример клиент-серверная архитектура). А помимо пресловутого треугольника существует еще множество разнообразных служб и подразделений: Application Management, Системные администраторы, Backoffice, поддержка клиентов и пользователей и бог знает кто еще. И все, даже новенькая уборщица, имеют свой собственный взгляд на то, каким должен быть финальный продукт. Шутки шутками, но в реалиях действительно существует множество людей, прямо или косвенно использующих финальный продукт, имеющих разные взгляды на разработку и качество продукта. В результате всего этого, при отсутствии продуманного менеджмента, через некоторое время, возникает хаос. Часто, в этот момент владельцы или топ-менеджеры задумываются о тестировании и Quality Assurance.

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

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

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

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