Home

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я разговаривала с коллективом и предположила, что тестирование – не всегда решение вопроса. Они были озадачены.

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

У тестирования и автоматизации два основных принципа, и если вы меня знаете, то, возможно, уже про них слышали:

1. Тестирование – это про верный баланс.

2. Автоматизация – это про экономию времени.

Оба связаны с издержками: в первом случае, если тестировать дороже, чем продолжать без тестирования, то лучше пропустить этот тест (или тесты).

Во втором случае, если автоматизация займет больше времени, чем общее время на ручное тестирование, автоматизировать не нужно.

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

Когда остановить тестирование?

Помню, этот вопрос мне задали на собеседовании, когда я пришла в Microsoft. «Когда тестирование нужно остановить?» Я тогда честно ответила, толком уже не помню, как, потому что очень нервничаю на собеседованиях (если я когда-либо собеседовала вас, и вам кажется, что вы не очень справились – верьте, я вас не осуждаю, у всех нас бывали плохие дни).

Думаю, что вроде бы я ответила как-то так: мы никогда не останавливаемся. Спустя более чем 10 лет я более уверена в ответе: мы останавливаем тестирование, когда продолжать его дороже, чем не продолжать.

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

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

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

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

Бесконечные тест-наборы

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

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

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

Иметь большой список тестов нормально, если каждый удовлетворяет условиям:

• Каждый тест проверяет что-то одно.
• Они хорошо документированы.
• Они всегда выдают одинаковые результаты в одинаковых обстоятельствах – это называется «идемпотентность».
• Их можно запускать параллельно.
• Их можно равномерно сгруппировать по фиче или приоритету.
• У них отсутствуют зависимости, кроме случаев, когда тест проверяет зависимость.

Помимо этого у вас могут быть тесты верификации билда (BVT), которые запускаются в рамках регресса. Идеальные для этого тесты проверяют высокоприоритетную, высокорисковую или ключевую функциональность.

Поиск баланса в тест-пирамиде

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

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

Однако чем выше вы поднимаетесь по тест-пирамиде, тем дороже ваши тесты, тем дольше они прогоняются, тем сложнее их поддерживать, и т. д.

Следовательно, важно тестировать правильные вещи в правильное время. Не больше, не меньше. Это принцип тест-пирамиды и исходная причина ее существования.

Что не нужно автоматизировать

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

Думаю, что все потенциально можно автоматизировать, но цель – сберечь время.

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

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

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

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

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

Обсудить в форуме