Home

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

Мухаммад Саад написал на LinkedIn про интересный сценарий. Приведу его курсивом и прокомментирую.

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

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

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

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

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

Чем дольше я работаю тестировщиком, тем меньше я заинтересован в том, чтобы «приложить руку к качеству продукта». Меня интересуют превосходные наблюдения за продуктом, дабы ни одна проблема не могла от меня скрыться. Я считаю, что качество как идея очень отвлекает. Но мне это понятно. Многие счастливы от мысли, что делают продукт лучше. Пока в истории Мухаммада все идет хорошо.

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

Те же самые 20 минут? Скучно? Нет и нет. Это не те же самые 20 минут. Я каждый раз тестирую немножко по-разному. Я расширяю и меняю данные. Я думаю об инструментах, которые помогут мне генерировать хорошие данные. Я, возможно, разговариваю с людьми, которые знают продукт лучше меня (если это зрелый продукт, то я явно не первый его тестировщик, а если это незрелый продукт – каким образом в нем уже оказались сотни форм и отчетов?) Это всего лишь третий день, и мне нужно яростно учиться еще дней двести, если продукт так сложен, как Мухаммад его описывает.

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

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

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

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

Теперь вас это злит. Вы устали. Вы начинаете пропускать шаги. Вы заполняете только половину полей. Ваша точность уже не та, как и ваша энергия – и, конечно, ваши шаги тоже уже не те.

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

У меня для вас новости: это история 90% тестировщиков, которые не применяют код/инструменты в тестировании.

Возможно, Мухаммад проецирует свое личное раздражение процессом тестирования на других тестировщиков. Я думаю, по поводу некоторых он прав. Безусловно, некоторые тестировщики будут злиться, скучать и уставать. Но я определенно возражу – его точка зрения никак не может относиться к людям, которые любят тестирование, изучают его, делают его своей карьерой.

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

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

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

Но тестирование НЕЛЬЗЯ автоматизировать. Автоматизировать можно определенные проверки результатов. Я соглашусь с Мухаммадом – автоматизация важна для большинства проектов, хоть и считаю, что ей должен заниматься специальный инструментальщик, следующий советам тестировщика, а не сам тестировщик. Всегда надо держать в уме, что автоматизация может и не может делать, и что тестирование на основе опыта и взаимодействия (то, что большинство называет «ручным тестированием», что я считаю оскорбительным и неточным) может находить баги, которые никогда не найдет автоматизация.

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

Регрессионные баги – это НЕ самые болезненные баги. Самые болезненные баги – это те, которые наносят наибольший вред пользователям. Ничто в «регрессии» не говорит о том, что это особо мерзкий баг. Я хочу находить все значимые баги.

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

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

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

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

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