Вполне вероятно, что, даже если вы проработали в сфере разработки программного обеспечения в качестве тестировщика ПО более 10 лет, вы все равно успели наделать немало ошибок. Совершать ошибки – это неплохо. Как правило, люди учатся именно на своих ошибках – совершенствуют свои методы работы и навыки. Особенно это касается тестировщиков программного обеспечения, которые только начали свой путь в этой области. Они совершают более простые ошибки, но, как я уже говорил, ошибки могут пойти во благо.
В этой статье я поделюсь с вами тремя самыми большими ошибками, которые допускают при тестировании программного обеспечения. Причем эти ошибки люди совершают независимо от опыта работы тестировщиком. Эта статья предназначена для того, чтобы уберечь вас от этих ошибок. Итак, давайте приступим!
Ошибка при тестировании ПО №1: не задаете вопросы
Я считаю, что одна из САМЫХ больших ошибок заключается в том, что тестировщики ПО не задают достаточное количество вопросов (или не задают их вовсе) на этапе разработки продукта. Мы все понимаем, что чем позднее мы обнаруживаем ошибку или проблему, тем дороже/сложнее обходится ее исправление. Именно поэтому тестировщики ПО должны как можно раньше вовлекаться в жизненный цикл разработки ПО.
Если мы говорим о самом хорошем раскладе, то тестировщики должны вовлекаться уже на этапах исследования продукта, объединяться с руководителями по программному продукту, проектировщиками и конструкторами взаимодействия, которые работают над новыми системами и функциями, чтобы иметь возможность задавать вопросы о способности к тестированию, удобстве использования и потенциальных технических проблемах, которые они уже могли заметить. Под техническими проблемами я имею в виду, скорее, нефункциональные проблемы, с которыми может столкнуться приложение. Например, проблемы с производительностью, вопросы безопасности, проблемы обеспечения доступности, и это лишь некоторые из них.
Как мне кажется, тестировщик ПО должен тесно сотрудничать с руководителем по программному продукту на всех этапах исследования, а также с командой разработчиков на этапе реализации и тестирования. Тестировщик ПО должен быть частью команды разработчиков, должен присутствовать на их ежедневных докладах, совещаниях по доработке, планированию и анализу, чтобы всегда иметь возможность задать необходимые вопросы.
Вот так выглядят стандартные вопросы, которые тестировщик ПО обязан задать:
- Знаем ли мы, для кого создается новая функция?
- Известны ли нам какие-то технические ограничения со стороны пользователя, например, ограничения, касающиеся устройства, Интернет-соединения пользователей и т.д.?
- Как мы можем протестировать эту функцию на наших промежуточных системах?
- Есть ли у нас какой-то регламент, который необходимо соблюдать?
- Есть ли какие-то вопросы потенциальной защиты данных, которые необходимо обсудить?
Этот список – это лишь часть вопросов, которые нужно задать. Список вопросов зависит от продукта, который вы разрабатываете и тестируете, и в зависимости от специфики вашего продукта, он может выглядеть совершенно по-разному.
Помимо всего прочего, здесь большую роль играет опыт тестировщика ПО. Опытный тестировщик задает совершенно иные вопросы, так как имеет довольно большой багаж знаний о технологиях, который он приобрел за годы своей работы. Зато новички могут задавать «более простые» вопросы на свежую голову, так как они не знают историю продукта. И то, и другое может быть полезным.
Ошибка при тестировании ПО №2: попытка автоматизировать абсолютно все
Вторая ошибка – это склонность к автоматизации абсолютно всего. В последнее время я довольно часто наблюдал такую ошибку во многих командах и организациях. Как правило, такая философия присуща людям, которые не понимают, для чего на самом деле нужна автоматизация и что от нее требуется.
Прежде чем приступить к автоматизации, команда должна обсудить все компоненты архитектуры ПО. Некоторые части приложения могут все еще находиться в стадии интенсивной разработки и быть неготовыми для того, чтобы их тестировали автоматически. В то же время в приложении могут быть части, которые имеют критически важное значения для продукта, и здесь следует уделить куда как больше внимания автоматизации и тестированию качества. А могут быть программные продукта, жизненный цикл которых ограничен, например, маркетинговые целевые страницы или специальные страницы событий, доступ к которым прекращается через несколько дней или недель. В таком случае автоматизация будет абсолютно бесполезной и лишь потратит ваше время.
В связи с этим, первый шаг перед написанием автоматического тестирования – оценка риска продукта и формулировка правильных вопросов.
Как только команда определит, какие части можно протестировать автоматически, она должна снова обсудить, на каком уровне необходимо реализовывать автоматические тестирования. В этой ситуации вам может помочь пирамида тест-автоматизации.
Если вы грамотно выполните автоматизацию, то поможете команде смело вносить изменения в код и быстрее отправлять его в производство.
Ошибка при тестировании ПО №3: повторное использование одних и тех же тестовых данных
Третья ошибка – повторное использование одних и тех же тестовых данных. Я раньше сталкивался с такой ошибкой и сам совершал ее в первые года работы тестировщиком ПО. Я снова и снова использовал одни и те же тестовые данные в цикле тестирования. Тогда я на собственном горьком опыте понял, что это была плохая идея.
Программные продукты слепо доверяют данным. Эти данные могут вводить пользователи. Это может быть текст, изображение, речь или данные, передаваемые в определенном формате между системами. Кроме того, в качестве тестовых данных могут быть выбраны конкретные состояния или конфигурации тестируемой системы.
После того, как вы воспользовались тестовыми данными в тестовом цикле, они измени свое состояние. Вполне вероятно, что пользователь ввел уже другие данные, изменилось состояние или конфигурация системы. Когда кто-то в следующий раз попробует выполнить тестирование с теми же данными, он не сможет гарантировать, что система ведет себя как положено, так как она доверяет тестовым данным, которые уже использовались. А это может серьезно повлиять на результаты тестирования и на продукт, который вы выпускаете.
Для того, чтобы протестировать приложение, команда разработчиков ПО должна определить данные, которые будет обрабатывать ПО. Следующим этапом команда должна сгенерировать тестовые данные для цикла разработки и тестирования для того, чтобы проверить, работает ли продукт так, как предполагалось. Генерация тестовых данных – это непростая задача. Этот процесс может оказаться довольно трудным; все зависит от сложности системы и технологий, которые были задействованы.
В идеале команда может сгенерировать тестовые данные с помощью сценария. После чего эти тестовые данные можно использовать для проведения какого-то определенного тестирования, а потом удалить или вернуть в исходное состояние.
Хорошая стратегия генерации тестовых данных – это ключ к успеху современных программных приложений. Не стоит ее недооценивать, а время, которое вы на это потратите, будет того стоить.
Ошибки – это хорошо
В этой статье я пробежался по трем ошибкам, которые совершают при тестировании ПО и которые я, как инженер по тестированию ПО, встречал в разных командах и организациях за последние несколько лет. Конечно же, когда дело доходит до тестирования ПО, команда или отдельный взятый человек могут совершить гораздо больше ошибок.
Все мы люди, и все мы совершаем ошибки, и я не считаю, что это плохо. Мы учимся на своих ошибках и, таким образом, совершенствуем свои навыки и пополняем багаж знаний. В идеале было бы здорово, чтобы команды была честна и поделилась своими ошибками с другими компаниями, чтобы избавить их от предрассудков, связанных с неудачами.
