Home

Автор: Хьюиб Шутц (Huib Schoots)
Оригинал статьи
Перевод: Ольга Алифанова

Первая версия этой статьи была опубликована на LinkedIn 5 февраля 2020 с заголовком "Нужны ли нам тестировщики? Нет! Нужно ли нам грамотное тестирование? Да!" В эту статью я добавил дополнительные умозаключения.

На прошлой неделе я делал доклад на конференции Agile, Testing & DevOps Showcase в Амстердаме. Темой доклада было "Современное тестирование".

Девиз Agile и особенно DevOps-подходов – "автоматизируй все!" Компании вроде Facebook заявляют, что у них вообще нет тестировщиков. У Microsoft есть только SDET (инженер по разработке ПО в тестировании), другие команды перепрофилируют разработчиков, чтобы тестировали они. Новичок на районе – искусственный интеллект и машинное обучение, и, по слухам, они уж точно заменят тестировщиков. Что же действительно происходит в мире?

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

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

В IT нам нужно знать максимально много о рисках и ценностях, и для этого нужно постоянно учиться. Я думаю, что нам необходимы умные люди, занятые профессиональным тестированием и ищущие значимые проблемы. Команды должны разбираться в рисках, которые мы берем на себя, создавая, выпуская и используя программные продукты. Зачастую в этом преуспевают люди с прекрасными навыками тестирования. Мне попадались такие названия должностей, как "Тренер по качеству" и "Инженер по качеству". Стоит ли двигаться в этом направлении? Если это решит проблему одержимости автоматизацией и нехватки навыков тестирования в командах, то я только за!

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

Дэн Эшби ответил мне:

"Это очень интересный вопрос. Я считаю, что да, нам нужны тестировщики, потому что нам нужны профессионалы, а разработчики не знают, что такое профессиональное тестирование и как оно выполняется. И вот что еще: Facebook использует внешних тестировщиков (многие из них работают в компаниях, предоставляющих услуги тестирования – знаю людей, работающих на FB и на стороннюю тест-организацию). Microsoft тоже сделал крутой разворот, и снова нанимает тестировщиков, помимо SDET. У них также вновь появилась роль тест-менеджера. Возможно, многие крупные компании осознали, что им нужно качественное тестирование – и, следовательно, тестировщики, обладающие такими навыками? Если это так, то, надеюсь, компании поменьше скоро последуют за лидерами".

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

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

Это "видение будущего тестирования" не имеет к профессиональному тестированию ни малейшего отношения. Это демонстрирует, что даже институт вроде ISTQB ничего не понимает ни в IT, ни в тестировании! Это меня печалит.

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

Недавно была опубликована новая книга TMap – "Качество для DevOps-команд". Я покрывался мурашками, читая, как TMap справляется с анализом рисков и разработкой тест-стратегии. Их анализ рисков – это просто список атрибутов качества с простыми расчетами (возможное влияние, умноженное на шанс возникновение). В зависимости от полученного числа присваивается класс риска (высокий, средний, низкий), а в зависимости от класса – интенсивность тестирования. Сами посмотрите, как это выглядит – вот и вот. Теперь разберем несколько цитат из книги, от которых я закатил глаза.

Глава 47. "Тестирование на основе опыта".

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

Любое тестирование опирается на опыт, потому что это невозможно "отключить". И любой тест даст вам какое-либо покрытие. Думаю, что они просто не знают, как говорить о покрытии осмысленно. Почему они делят тестирование только на две категории? Есть множество способов классифицировать техники тестирования (отметим, что в BBST то, что TMap называет "подходом", называется техникой). Между техниками нет четкого разделения, см. слайд 62 курса BBST Test Design. "Каждый тест учитывает все эти моменты. Отдельная техника, как правило, учитывает от одного до трех, а для остального будут созданы специальные тесты". Лично мне нравится, как в BBST классифицируются техники – их выделяют на основании идей, движущих тестирование.

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

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

Глава 48 "Есть ли смысл в неструктурированном тестировании?"

"Любое тестирование без плана, указывающего, что делать и чего ожидать от системы, или без подготовки к тесту, будет неструктурированным. Оно также называется ad-hoc тестированием. Некоторые видят в нем огромное преимущество, говоря, что можно сразу приступать к тестированию, не тратя время на подготовку".

Единственная известная TMap структура – это планы и тест-кейсы. Структура – это "взаиморасположение и взаимосвязи между частями или элементами чего-то сложного", Майкл Болтон пишет об этом здесь. Тестирование – это обучение, а обучение – это ментальные модели. TMap совершенно не уделяет внимание тому, как люди учатся. Глубокое изучение – поначалу запутанное дело, но по ходу дела ситуация проясняется. Переключаясь (дефокусируясь), мы даем мозгу шанс обработать изученную информацию и интегрировать ее в модели у себя в голове. Хорошие (ментальные) модели – это очень важно. Механистические тест-подходы напрочь забывают об обучении.

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

Интересный подход от TMap – апелляция к невежеству. Тестировщики не могут что-то объяснить, значит, это плохой подход! Но в чем тут проблема, в подходе или в навыках тестировщиков?

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