img

3 самые большие ошибки при тестировании программного обеспечения

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

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

Ошибка при тестировании ПО №1: не задаете вопросы

Я считаю, что одна из САМЫХ больших ошибок заключается в том, что тестировщики ПО не задают достаточное количество вопросов (или не задают их вовсе) на этапе разработки продукта. Мы все понимаем, что чем позднее мы обнаруживаем ошибку или проблему, тем дороже/сложнее обходится ее исправление. Именно поэтому тестировщики ПО должны как можно раньше вовлекаться в жизненный цикл разработки ПО. 

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

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

Вот так выглядят стандартные вопросы, которые тестировщик ПО обязан задать:

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

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

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

Ошибка при тестировании ПО №2: попытка автоматизировать абсолютно все

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

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

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

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

Если вы грамотно выполните автоматизацию, то поможете команде смело вносить изменения в код и быстрее отправлять его в производство. 

Ошибка при тестировании ПО №3: повторное использование одних и тех же тестовых данных

Третья ошибка – повторное использование одних и тех же тестовых данных. Я раньше сталкивался с такой ошибкой и сам совершал ее в первые года работы тестировщиком ПО. Я снова и снова использовал одни и те же тестовые данные в цикле тестирования. Тогда я на собственном горьком опыте понял, что это была плохая идея. 

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

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

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

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

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

Ошибки – это хорошо

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

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

Ссылка
скопирована
Получите бесплатные уроки на наших курсах
Все курсы
QA
Скидка 30%
Автоматизированное тестирование на Python
Изучите автоматизацию, чтобы свести к минимуму рутинные задачи и дать себе простор для творчества, а заодно стать еще более востребованным специалистом.
Получи бесплатный
вводный урок!
Пожалуйста, укажите корректный e-mail
отправили вводный урок на твой e-mail!
Получи все материалы в telegram и ускорь обучение!
img
Еще по теме:
img
Прошли те дни, когда предприятия всецело полагались на ручное тестирование. И хотя, оно все же является неотъемлемой частью проц
img
  А вы знали, что в каждой 1000 строк кода можно найти от 100 до 150 ошибок?  Процесс создания веб-приложений может показа
img
Ошибаться полезно, особенно на начальном этапе проекта, а сделать все идеально получается редко с первого раза. Можно даже выпол
img
Вполне вероятно, что, даже если вы проработали в сфере разработки программного обеспечения в качестве тестировщика ПО более 10 л
img
Если вы хотите убедиться, что ваш сайт работает хорошо вне зависимости от интенсивности трафика, проведите нагрузочное тестирова
img
  Разработка посредством тестирования (TDD – test-driven development) – это то, что каждый разработчик программного обеспечения
ЗИМНИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59