Откуда взять информацию тестировщикам

Стандартный

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

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

На рисунке 1 приведена схема, на которой указаны основные, на мой взгляд, источники информации для тестировщика.

Рисунок 1 Источники информации

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

Источники, актуальные до внесения изменений в код.

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

Менеджер проекта.

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

User story/use-case. Т.к. менеджер формулирует задачу для разработчика, он может привести пример использования новой или измененной функции. Это бывает полезно при разработке или обновлении testcase’ов. Правда тут многое зависит от менеджера, как правило, менеджеры люди занятые, и доставать лишний раз их расспросами не стоит

Аналогичные приложения.

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

Стандарты. В качестве стандартов можно использовать продукты ведущих разработчиков ПО. Особенно полезно это бывает при тестировании GUI (например, можно ориентировать на MS Office для Windows-приложений). В споре с разработчиками тот факт, что MS делает совсем по-другому будет хорошим аргументом.

Знание предметной области и понимание реализуемых usecase’ов

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

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

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

Разработчик, архитектор

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

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

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

Само приложение

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

Release notes

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

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

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

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

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

Шаблон Release notes

Версия сборки (build’а)

  • Добавлено:
  • Изменено/исправлено:
  • Удалено:

В каждом пункте указать какие компоненты либо функции либо требования были изменены

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


PS.
Статья была опубликована на IT4business.ru. В комментариях было справедливо замечено что «В статье не упомянут самый главный и единственный заслуживающий доверия источник информации — ЗАКАЗЧИК либо ПОТРЕБИТЕЛЬ.» :) Комментарий оставил Алексей Баранцев.

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s