Когда тестировщик решает писать качественные тест-кейсы и хочет увеличить свою продуктивность, есть несколько ключевых моментов, которые помогут достичь этих целей.
Во-первых, нужно подготовить себя профессионально и психологически для некоторых ключевых моментов, необходимых для каждого успешного тестировщика ПО в IT-индустрии. Они будут рассматриваться как “исходные данные” для работы тестировщика перед началом написания тест-кейсов.
Далее необходимо определить метрики качества, задействованные в проекте, которые используются в качестве инструмента для оценки работы тестировщика на различных этапах жизненного цикла тестирования. Это будет рассматриваться как “Выходные данные” работы тестировщика после завершения написания тест-кейсов.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Наконец, тестировщик должен знать, как сообщать о дефектах, как происходит эскалация проблем и как составляются отчеты о тестировании в соответствии со стандартными процессами, понятными заинтересованным сторонам проекта.
Чему вы научитесь:
Подготовка к написанию тест-кейсов
1) Написание тест-кейсов – это искусство, а не просто рядовая задача. Компонент или сегмент ПО может быть спроектирован и разработан, но до тех пор, пока он не будет полностью протестирован на все сценарии с помощью эффективного подхода к тестированию, он будет бесполезен и не может быть выпущен и использован кем-либо. Поэтому относитесь к себе как к важному человеку в проекте, а к своей деятельности по тестированию – как к важной задаче в проекте.
2) Страсть к работе и позитивный настрой являются важнейшими качествами тестировщика, которыми он должен обладать на протяжении всего жизненного цикла проекта. Страсть мотивирует на создание команды, а позитивный настрой приносит большую продуктивность в написании качественных тест-кейсов. Таким образом, деятельность по написанию тестов представляет собой сочетание профессиональных и личностных качеств для получения отличных результатов.
3) Позитивные и негативные тестовые сценарии являются частью написания тест-кейсов, но тестировщики должны иметь полупозитивный образ мышления, чтобы уметь сломать тестируемое приложение путем поиска ошибок. Это не негативный образ мышления, а скорее избежание ситуации выявления ошибки кем-либо после релиза или момента, когда система будет сломана реальными пользователями системы.
4) Эффективность тестировщика должна оцениваться не по количеству выявленных дефектов в тестируемой системе, а по его способностям к написанию эффективных тест-кейсов, результатом которых является обнаружение дефектов. Таким образом, тест-кейсы должны быть написаны так, чтобы их покрытие и отслеживаемость были максимальными, исходя из границ и набора функциональностей системы.
5) Тщательно изучите домен приложения. Например, тестирование веб-сайта проще, чем тестирование финансового ПО, разработанного для фондовой биржи, которым одновременно пользуются тысячи людей. Простая функциональность веб-сайта может быть понятна любому тестировщику, в то время как финансовые термины и функциональные возможности не могут быть понятны всем тестировщикам до тех пор, пока они не получат соответствующее образование или подготовку, или не будут иметь опыт работы в данной области.
Поэтому, когда тестировщик назначается на новый проект, он/она должен провести самооценку, подходит ли он/она по требованиям и может ли он/она выполнять свою работу в соответствии с ожиданиями или нет. Если функциональные требования сложны для понимания, об этом следует заблаговременно сообщить команде проекта, чтобы избежать будущих недоразумений в отношении эффективности работы тестировщика. С этим справится руководитель проекта или менеджер по тестированию с помощью надлежащих планов и обучения.
6) Требования проекта и виды тестирования, которые необходимо выполнить, варьируются от проекта к проекту. Тестировщик должен быть готов к проведению любого вида тестирования. Не ограничивайте свои возможности только своими навыками и специализацией. Будьте готовы взять на себя ответственность и задачи по написанию и выполнению тест-кейсов для любого вида тестирования.
Многие тестировщики пытаются идентифицировать себя как тестировщиков только ручного или только автоматизированного тестирования. Когда речь идет о тестировании производительности, нагрузочном тестировании или стресс-тестировании, очень немногие тестировщики берут на себя эти роли и готовятся к ним путем обучения или получения необходимых знаний. Поэтому будьте готовы быстро брать на себя новую ответственность и расти по карьерной лестнице.
7) Определите виды тестирования, необходимые для приемочного пользовательского тестирования, и соответствующие навыки. Например, некоторые проекты требуют только тестирования “черного ящика”, а некоторые требуют навыков тестирования “белого ящика”. Знание скриптов или опыт работы с SQL или с языком разметки, таким как HTML/XML и т.д., или даже системные знания о том, как установить/устранить неполадки при установке ПО и т.д. – это некоторые специфические для конкретного проекта требования, которым вы должны научиться сами или пройти соответствующее обучение.
8) Убедитесь, что тест-кейсы охватывают такие виды тестирования как тестирование производительности, безопасности и регрессионное тестирование. Например, для входа в приложение с помощью окна, приведенного ниже:
- Тестирование производительности может потребоваться для проверки стабильности работы приложения при одновременном входе в систему 1000 пользователей, и тест-кейсы должны быть написаны с учетом этого сценария.
- Тестирование безопасности может потребоваться для проверки того, что приложение позволяет использовать систему только пользователям, имеющим соответствующие права и разрешения, и тест-кейсы аналогично должны быть написаны с учетом этих сценариев.
- Регрессионное тестирование может потребоваться для проверки правильности работы основных и критичных функциональностей в каждом релизе.
9) Ревью тест-кейсов: Одной из самых важных и самых упускаемых из виду фаз жизненного цикла разработки и тестирования ПО является ревью. Наиболее качественных результатов можно ожидать, когда план проекта включает достаточное количество времени, отведенное на процесс ревью на каждом этапе разработки проекта.
Например, прежде чем приступить к написанию тест-кейсов, тестировщики должны проверить, был ли пересмотрен документ “Спецификация требований” и все ли пункты ревью учтены и обновлены в документе. Если организация следует правильному и зрелому процессу, все шаблоны документов должны содержать информацию об изменениях на первой странице самого документа.
Наборы тест-кейсов должны быть пересмотрены как минимум 3 раза:
i) самостоятельное ревью
ii) ревью коллег
iii) проверка другими лицами на предмет полноты тестового покрытия, отслеживаемости и того, является ли тест-кейс полнимым или нет.
10) Разберитесь как оценивать и планировать задачи тестирования. Планируйте работу только в установленные рабочие часы. Этого можно достичь, если начинать и завершать задачи вовремя и ежедневно составлять план задач на следующий день.
Не засиживайтесь допоздна и не проводите выходные в офисе. В настоящее время существуют эффективные agile-подходы к управлению проектами. Если запланированные на определенный этап задачи не достигаются проектными командами, это будет рассматриваться как неэффективное управление проектом, а не как неэффективность самих команд.
Примечание: Помните, что даже для автоматизированного тестирования тест-кейсы должны быть четко прописаны и пересмотрены хотя бы один раз, полностью охватывая сценарии для функциональностей тестируемого приложения. Любой инструмент автоматизации может успешно генерировать и выполнять тест-кейсы только тогда, когда четко определены ручные тест-кейсы.
Метрики качества
Рассчет метрик качества – важный вид деятельности на всех этапах тестирования ПО. QA команда должна быть полностью осведомлена о различных метриках тестирования, используемых для достижения цели проекта. Работа тестировщика оценивается не только на основе фазы выполнения теста, но и на основе всех метрик тестирования, собранных в ходе анализа требований, написания тест-кейсов, их выполнения, составления отчетов о дефектах и, наконец, этапа составления отчетов о тестировании.
Ниже приведены несколько важных метрик тестирования, которым следуют большинство организаций для повышения производительности тестировщиков и эффективности этапов тестирования.
1) Средняя эффективность тестирования
- Количество дефектов на человеко-месяц работы по тестированию.
- Рассчитывается как среднее (Общее количество дефектов за время тестирования в человеко-месяцах).
- Рассчитывается после каждого внутреннего релиза, а также после завершения тестирования.
- Допустимый лимит: не более 50
2) Средняя плотность дефектов, найденных клиентом
- Дефекты, о которых сообщил клиент после релиза, в сравнении с общими работами по тестированию в человеко-месяцах.
- Рассчитывается как среднее значение (общее количество дефектов после релиза/общее количество работ по тестированию в человеко-месяцах).
- Рассчитывается после внешнего релиза и завершения проекта.
- Допустимый лимит: не более 1
3) Не пройденные функциональные тесты
- Количество непройденных тест-кейсов/ Общее количество выполненных функциональных тест-кейсов.
- Рассчитывается ежемесячно или раз в две недели.
4) Ошибки с уровнем серьезности 1
- Общее количество выявленных дефектов с уровнем серьезности 1 (блокирующие).
- Тестирование ПО не может быть продолжено из-за блокирующих дефектов.
- Подсчитывается на еженедельной основе.
5) Ошибки с уровнем серьезности 2
- Общее количество выявленных дефектов с уровнем серьезности 2 (критические).
- Тестирование не может быть продолжено для данной функциональности из-за наличия серьезных дефектов, но может быть продолжено для других компонентов системы.
- Подсчитывается на еженедельной основе.
6) Ошибки с уровнем серьезности 3
- Общее количество выявленных дефектов с уровнем серьезности 3 (средние).
- Тестирование может быть продолжено, так как выявленные дефекты незначительны и не останавливают тестирование.
- Подсчитывается на еженедельной основе.
7) Ошибки с уровнем серьезности 4
- Общее количество выявленных дефектов с уровнем серьезности 4 (незначительные).
- Тестирование может быть завершено без каких-либо проблем, поскольку выявленные дефекты носят косметический характер и будут исправлены в следующем релизе.
- Подсчитывается на еженедельной основе.
Отчеты о дефектах
Механизм отчета о дефектах должен контролироваться с помощью развитого процесса тестирования, это необходимо для поддержания качества ПО. Должен существовать налаженный процесс эскалации к соответствующим уполномоченным лицам, чтобы знать статус, серьезность и приоритет дефекта. Существует множество бесплатных и коммерческих баг-трекинговых систем, таких как Bugzilla, Mantis и т.д., которые очень эффективны в механизме отслеживания проблем и могут быть легко интегрированы с любым инструментом управления тестирования, используемым в проекте.
В каждом проекте тестирования необходимо следовать стандартным процедурам для ежедневного онлайн-отчет о статусах. Каждый дефект/проблема, зарегистрированный в баг-репорте, должен немедленно отправляться по электронной почте ответственным, что поможет им спланировать и принять соответствующие меры.
Отчеты о тестировании
Помимо отчетов о дефектах, созданных, зарегистрированных и эскалированных в баг-трекинговой системе, отчет о тестировании является одним из наиболее важных документов, позволяющих узнать статус тестирования и другие важные показатели, выявленные и рассчитанные в течение заданного в отчете периода времени.
Заключение
Процесс подготовки к написанию тест-кейсов – это не только распределение ресурсов в проекте, но и ряд других ключевых моментов: подготовка себя как квалифицированного тестировщика и понимание метрик качества, которые отслеживаются на протяжении всего жизненного цикла тестирования и даже после релиза.
Таким образом, следование процессам, стандартам, процедурам и отслеживание метрик качества, автоматически приведет вас к высокой эффективности тестирования, продуктивности и войдет в привычку в вашей карьере.
Эти факторы качества можно проанализировать самостоятельно или в группе, ответив на несколько вопросов, которые покажут, находится ли команда на правильном пути самосовершенствования и улучшения процесса с целью достижения эффективного подхода к написанию и выполнению тест-кейсов:
- Просматривали ли вы документы функциональных требований/пользовательских требований/примеров использования в бизнесе?
- Был ли документ функциональных требований рассмотрен и обновлен должным образом согласно комментариям по результатам рассмотрения?
- Получили ли вы прототипы дизайна для всех тестируемых функциональностей?
- Умеете ли вы писать тест-кейсы, которые можно использовать на протяжении всего жизненного цикла тестирования?
- Обладаете ли вы необходимыми навыками и знаниями для тестирования текущего приложения?
- Требуется ли вам какое-либо обучение или технические знания, необходимые для выполнения тестовых примеров?
- Есть ли у вас график разработки, ревью и выполнения тест-кейсов, который включает в себя время на подготовку качественной документации?
- Есть ли у вас договоренности с другими членами команды для ревью тест-кейсов и эксперт для проверки полноты и охвата тестируемых фунукиональностей?
- Достаточно ли у вас тест-кейсов для всех функциональных требований?
- Достаточно ли у вас тест-кейсов для тестирования производительности, нагрузки и безопасности?
- Достаточно ли у вас тест-кейсов для проверки установки ПО и для регрессионного тестирования?
- Есть ли у вас контактное лицо для эскалации проблем или сообщения об ошибках?
- Правильно ли настроен инструмент отслеживания дефектов с необходимыми правами для всех?
- Удобно ли вам следовать всем процессам, определенным в плане тестирования?
- Участвуете ли вы во всех ревью-митингах и получаете ли возможность пообщаться с командой разработчиков или с руководством?
- Повысилась ли ваша производительность и эффективность или вам необходимо принять какие-либо меры для этого?
Существует множество подобных вопросов, которые тестировщики могут задавать себе для анализа самосовершенствования, в зависимости от типа проекта или организации, в которой они работают. Самое главное, что все эти действия не должны выполняться только ради следования процессам, а должны стать вашими ежедневными привычками, что можно сделать только если вы страстно заинтересованы в тестировании.
Перевод статьи “How To Prepare Yourself For Test Case Writing [Productivity Tips]”