Home

Автор: Майкл Болтон (Michael Bolton).

Оригинал статьи

Перевод: Ольга Алифанова

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

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

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

Во-вторых, тестирование не делится на ручное и автоматизированное. Тест невозможно автоматизировать. Автоматизации поддаются элементы процедуры теста (в частности, проверки отдельных фактов). Но ваш тест не состоит из нажатий виртуальных клавиш, выполненных машиной, или сравнения результата с какой-либо документацией.

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

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

Куда лучшей идеей будет создание новых автоматизированных проверок, концентрирующихся на специфических продуктовых факторах, особенно на низких уровнях, с целью получения быстрой обратной связи. Их хорошо бы создавать в паре разработчик-тестировщик (или путем совместной работы двух разработчиков, один из которых играет роль создателя, а другой – тестировщика). Неплохая идея – разрабатывать эти проверки в ходе процесса создания какого-либо кода. Отличная идея – думать об инструментах шире, не фокусируясь только на быстром выполнении тест-сценариев.

Итак, я подталкиваю людей к смене формулировки вопроса. Вместо того, чтобы размышлять, какие (существующие) тест-кейсы стоит автоматизировать, попробуйте подумать вот о чем:

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

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

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