Home

Автор: Маарет Пюхяярве (Maaret Pyhäjärvi)
Оригинал статьи
Перевод: Ольга Алифанова

Давным-давно на собеседованиях мы всегда спрашивали “Как вы протестируете текстовое поле?” Мы выяснили, что ответ на этот вопрос коррелирует с квалификацией собеседника, и выявили четыре распространенных типа ответов на него.

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

Функциональные тестировщики лишь немногим сильнее начинающих. У них куда больше идей, но идеи эти скучны - вставить SQL в поле системы, не имеющей базы данных. Это имеет смысл, только если далее по цепочке имеется связь с SQL-базой данных. Список того, что мы можем попробовать, расширился, но ему не хватает глубины и понимания, что будет иметь смысл, а что нет. Типичные идеи для функциональных тестировщиков - это окружения, разделение функции и данных, функция с точки зрения интерфейса (скажем, Enter vs клик мышкой), и применение различных списков и инструментов, концентрирующихся на определенном аспекте - вроде html-валидаторов, валидаторов доступности и безопасности. Как правило, такие люди еще упоминают о том, что делать с полученной в ходе тестирования информацией, и о создании хороших баг-репортов. На этом этапе, когда они упоминают про приемочные критерии, они думают о своем в них вкладе.

Тестировщики более высоких уровней отличаются только тем, с чего начинают. Если они начинают с вопроса “зачем это кому-то вообще использовать” и продолжают пытаться опровергнуть не только то, о чем им сказали, но и то, что они, по их мнению, знают на основании того, что они видят - это настоящие senior-тестировщики, которые рассматривают любую возможность теста в контексте реального приложения, реальной команды и реальной организации с реальными бизнес-нуждами и ограничениями. Если они начинают с демонстрации техник, подходов и направлений мышления, им все еще нужно поработать над вопросом финансовых мотиваторов информации. Разница между настоящими senior-тестировщиками и теми, кто к ним близок - в немедленной приоритезации. Это один из ключевых элементов хорошего, уверенного исследовательского тестирования. То, что нечто в принципе может быть протестировано, не значит, что оно должно быть протестировано. Мы решаем, что же мы в итоге будем тестировать, каждый раз, когда думаем над своим следующим шагом.

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

Имея многолетний опыт с этим абстрактным вопросом, я стала делать его конкретнее, показывая нечто вроде текстового поля на экране и задавая два вопроса:

-    Что бы вы тестировали далее?

-    Что вы узнали из результатов этого теста?

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

1.  Test This Box. Это приложение, содержащее только текстовое поле и кнопку, и дающее минимум контекста. Сениоры хорошо справляются с выявлением теоретического предназначения, сравнением его с декларируемым предназначением, осознанием, что это первый шаг на пути к инкрементному созданию приложения, выяснением, что хоть поле (пока) и не используется, оно уже отображается, и что приложение имеет множество измерений, в которых поле может непреднамеренно отказать.

2.  Gilded Rose. Это задание по программированию - функция, принимающая три вида данных, и эти данные вполне могут поступать через текстовые поля. Текстовое поле - это просто интерфейс. Функция явно и внятно намекает на покрытие кода, но также и на покрытие рисков - кто сказал, что нельзя использовать шестнадцатеричные числа? Используя это текстовое поле, я оцениваю способности к обучению, и это мой любимый инструмент для отбора джуниоров. Я буду учить тестированию только тех, кому необходимы мои советы. К тому же, если человек не понимает, что код и IDE - всего лишь интерфейс, когда с ним кто-то помогает, я не уверена, что хочу поддерживать его на пути к становлению сбалансированным, современным исследовательским тестировщиком, который документирует при помощи автоматизации и близко сотрудничает с разработчиками.

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

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

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

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

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