Обнаружение дефектов в ПО

Бывали ли у вас ситуации, когда вы были приняты на работу в компанию на должность тестировщика вместо разработчика? Вам также сеньоры неоднократно советовали выбрать проект, который даст вам опыт разработки программного обеспечения вместо тестирования? Говорили ли вам, что в начале карьеры можно поработать тестировщиком, но позже желательно перейти к разработке ПО? Вам когда-либо говорили, что тестирование требует минимального уровня навыков?

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

О чем эта статья?

Эта статья показывает, почему тестирование так же важно, как и разработка. Она также подчеркивает, что обнаружение дефектов или ошибок в ПО требует предварительного планирования, таланта и большого количества навыков у тестировщиков.

Что такое тестирование?

Тестирование – это проверка продукта на соответствие требованиям заказчика.

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

Цель тестирования – обнаружение ошибок и убеждение в том, что продукт соответствует или превосходит ожидания.

Важность тестирования

Если задуматься, то тестирование тесно связано с нашей повседневной жизнью. Возьмем такой распространенный пример, как шоппинг. Когда вы идете в магазин одежды, вы примеряете одежду и проверяете, подходит ли вам размер. Разве это не является в некотором роде тестированием?

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

Около 50% времени разработки ПО уходит на тестирование, чтобы убедиться, что код работает в соответствии с заданными требованиями. Исправление ошибок или дефектов на ранних стадиях разработки обходится гораздо дешевле, чем на поздних стадиях.

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

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

Что такое дефект?

Дефект – это несоответствие программы или функции ожидаемым результатам.

Главная цель тестировщика – выявить как можно больше дефектов и как можно раньше. Это требует не только внимательности, но и способности проникнуть в суть системы и определить, какие ситуации могут вызвать сбой.

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

Так как вы думаете, у кого больше навыков и знаний?

Как найти как можно больше багов?

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

1. Исследование продукта

В основном это подразумевает получение глубоких знаний о разрабатываемом приложении.

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

2. Планирование сценариев тестирования

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

Планирование тестовых сценариев является очень важным этапом в жизненном цикле тестирования ПО (STLC, Software Testing Lifecycle ). Тестовые сценарии, которые вы разрабатываете, являются прямым отчетом о качестве продукта и степени проведенного тестирования.
После прочтения документа по сценарию использования приложения или любого другого технического документа по функционалу приложения, уделите время на разработку тест-кейсов. Важно иметь баланс между сценариями happy path и unhappy path testing. Также уделите некоторое внимание сценариям ad-hoc, white box и black box testing.
Будьте внимательны при описании сценариев и убедитесь в их достоверности. Проведите несколько ревью с командой разработчиков и убедитесь, что вы учли их комментарии при написании тест-кейсов. Это позволит не тратить время на создание недействительных тест-кейсов.

3. Настройки среды

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

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

4. Техники тестирования для поиска дефектов

Обнаружение слабых мест: Во время тестирования очень важно найти те места в программе, где код может “сломаться”.
Happy Path Testing: Отведите достаточное время на тестирование happy path сценариев. Обычно на этом этапе тестирования ошибки встречаются редко, так как разработчики уже провели модульное тестирование и убедились, что код работает правильно.
Error Path Testing: Затем переходите к тестированию error-path сценариев. Это обычно самая интересная часть тестирования, где вы можете проявить свою креативность. Здесь вы вероятнее всего и найдете ошибки.
Ad-hoc testing: Хотя этот вид тестирования часто относится к error-path тестированию, полезно выделить и для него некоторое время, поскольку оно может помочь найти существенные дефекты в приложении.

Рекомендуется постоянно поддерживать связь с разработчиками и информировать их о найденных дефектах по следующим причинам:

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

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

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

Это позволяет избежать временных задержек при исправлении ошибок и минимизировать время существования дефекта в ПО.

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

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

Вот пример того, почему логи важны:

Во время цикла тестирования многократно наблюдалось, что программа работает в соответствии с требованиями. Однако у заказчика во время работы приложения появилась проблема, связанная с серией “null pointer exceptions ” в логах. Это была очень серьезная проблема, которая незамедлительно должна была быть устранена. Для решения этой проблемы были разработаны специальные скрипты, которые позволили получить детальный отчет об ошибках “null pointer”.

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

Запускайте логи: Это практика, которая может показаться накладной для тестировщика, но она полезна в долгосрочной перспективе.

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

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

Заключение

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

Перевод статьи «How to Find Maximum Valid Defects in Any Application?».