Сегодня я сломал свой код. И я рад, что сделал это.

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

Я счастлив, что нарушил свой код раньше, чем кто-либо другой. Я обнаружил проблему до того, как она вызвала проблемы у пользователей, и до того, как я потратил время на QA (обеспечение качества) и рецензента. Мы все должны стремиться к этому. Легко получить код, который работает в 90% случаев. Но в остальных 10% случаев обо всех этих надоедливых пограничных случаях трудно даже подумать, не говоря уже о том, чтобы ваш код правильно их обрабатывал. Итак, что вы думаете об этих крайних случаях, которые нам нужно обрабатывать?

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

Так что же QA думает о взломе вашего кода?

Поймите, что должен делать ваш код

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

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

Протестируйте случаи успеха

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

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

Тест на известные сбои

Вы знаете, что должен делать код. Вы знаете, код делает это успешно. Теперь пришло время протестировать ошибки, которые, как вы знаете, произойдут. Может быть, эти сбои прописаны в требованиях. Например, он может сказать: «При нажатии на ссылку вы переходите на страницу продукта. Если продукт не найден, перенаправьте на страницу со списком продуктов». Это легко проверить, поскольку ваши заинтересованные стороны говорят вам, что делать, когда это не удается.

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

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

Делать глупые ошибки; сделать что-то неправильное намеренно

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

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

Итак, какие хорошие глупые ошибки можно совершить?

Доведите проверку до предела

Что произойдет, если вы не включите входные данные? Что произойдет, если вы используете слишком длинную строку или большое число? Как насчет отрицательного числа или передачи строки вместо числа?

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

Делайте противоположное тому, что вы ожидаете от пользователей

Буквально делайте противоположное тому, что вы ожидаете от пользователей.

  • Делайте что-то не по порядку.
  • Щелкните вне страниц в середине процесса.
  • Нажмите кнопку отмены в модальном окне, снова откройте модальное окно и повторите попытку отправки.
  • Все остальное, о чем вы можете подумать, не имеет смысла для этой функции.

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

Взломайте свой код

Ваша очередь быть хакером. Можете ли вы найти какие-либо проблемы безопасности в вашем коде? Пробовали ли вы SQL-инъекцию, XSS (межсайтовый скриптинг), CSRF (межсайтовый запрос на подделку) и т. д.?

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

Сделайте это так медленно, что вам станет скучно

Вы не хотите намеренно делать свой код неэффективным, но вы должны тестировать функции с кучей данных. Есть ли возможность изменить количество записей на странице? Что произойдет, если вы сделаете это число 10 000? Это все еще быстро? Можете ли вы загрузить файл с более чем 10 000 записей, не скучая в ожидании его завершения?

Легко заполнить 5 фиктивных записей и начать тестирование функции. Мы часто забываем, что реальные пользователи могут пытаться работать с огромными объемами данных одновременно. Обычно это происходит после того, как наш первый опытный пользователь достигает 10 000+ записей, и у нас есть срочное исправление ошибки, потому что страница не загружается; мы понимаем, что производительность является проблемой. Найдите предел объема данных, который может обрабатывать ваш код, а затем попытайтесь его оптимизировать. Если вы больше не можете оптимизировать его, убедитесь, что ваши пользователи не могут выйти за этот предел, или предоставьте способ разгрузить процесс фоновому заданию, чтобы пользователь мог быть предупрежден, когда это будет сделано, вместо того, чтобы заставлять их ждать.

Вы сломали свой код; теперь пришло время это исправить

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

И последнее замечание: важно понимать, что вы не будете находить каждую проблему каждый раз. Есть причина, по которой QA — обширная профессия, необходимая в нашей отрасли. Разработчик, выполняющий этот тип тестирования, стремится исключить обмен данными между разработчиками и QA и сэкономить время, а не найти и исправить все проблемы.

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

Теперь получайте удовольствие и ломайте свой код, чтобы никто не узнал, что он был взломан.

Первоначально опубликовано на https://kevinhicks.software 17 февраля 2021 г.