Как на самом деле предотвратить появление багов?

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

Здесь я хотел бы поделиться тем, как именно я помогаю предотвращать баги в проектах и как я помогаю другим выдвигать идеи о том, как также предотвратить баги.

Во время ознакомления с функциями

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

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

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

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

  • Сценарии ошибок — как будут обрабатываться ошибки; где будет проводиться проверка (бэкенд или фронтенд) и т.д.
  • Запросите документацию по бэкенду и как там будет проходить проверка, затем убедитесь, что во фронтэнде есть более строгая проверка (где это возможно), это поможет избежать проблем, когда FE принимает данные и вы отправляете форму, но бэкенд отклоняет ее (например, обязательные поля, все обязательные поля, которые требует бэкенд, ДОЛЖНЫ быть обязательными во фронтэнде).
  • Есть ли какие-либо обязательные поля, которые мы должны учитывать?
  • Есть ли другие функции, от которых мы ожидаем соответствия этой функции? Примерами могут быть: способ отображения ошибок, расположение и цвет кнопок, обратная связь с пользователем при отправке формы (если у вас уже есть подобные вещи, вы можете спросить о них и о том, будет ли новая функция согласована с существующим поведением на вашем сайте/приложении).
  • Есть ли какие-либо зависимости внутри приложения, о которых мы должны знать?
  • Есть ли внешние зависимости (например, от сторонних производителей), о которых мы должны знать?

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

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

После написания требований/пользовательских историй

Я собираюсь предположить, что требования/истории пользователей все еще подлежат/открыты для изменений, но в определенной степени ограничены. (без масштабных изменений)

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

Проведите обсуждение с разработчиками в вашей команде, ориентированное на тестирование. Здесь вы можете рассказать о том, как именно вы будете тестировать и что вы ожидаете — также не забудьте подчеркнуть, что вы могли что-то неправильно понять, и что вы открыты для идей тестирования от разработчиков из вашей команды. Я склоняюсь к использованию заметок о тестировании, а не тест-кейсов — но в конечном итоге вам решать, что лучше для вашего проекта и что реально можно сделать в рамках walkthrough.

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

Например:

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

[email protected] / -> Пожалуйста, введите пароль

nicolaemail.com / ********* -> Пожалуйста, введите действующий адрес электронной почты

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