[СПб, 17-18 мая] Heisenbug

Конференция: Heisenbug 2018 Piter
Тематика: тестирование
Дата: 17-18 мая 2018 года
Место: Санкт-Петербург, Гостиница «Park Inn by Radisson Пулковская»

На сайте Heisenbug всегда можно увидеть самую актуальную информацию о программе конференции, а здесь публикуем её анонс от участника команды JUG.ru Group Олега Чирухина, изначально размещённый на Хабре:

Четвёртому по счёту Heisenbug официально быть. Между двумя Heisenbug проходит шесть месяцев. Это большой срок, который позволяет вам научиться жить с полученной информацией, а нам — улучшить конференцию.

Анализ отзывов участников

Перед сочинением этого анонса я открыл отзывы участников. Основная тема половины отзывов — необходимость (или её отсутствие) иметь доклады по мануальному тестированию. Это то, что мне хочется обсудить с вами.

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

«Если в двух словах — «автоматизация головного мозга». Следовало так и назвать конференцию. Была всего пара докладов про НЕ автоматизацию. Вы ведь и сами знаете, что автоматизация это всего лишь часть тестирования, и совсем не основная».

При составлении следующей программы такие мнения учитывались. Программа получилась более сбалансированной: «мануальное» тестирование обсуждалось уже в значительной части докладов. Но прямо на конференции, в дискуссионных зонах, мы встретились с хейтерами, которые, во-первых, яростно желают автоматизировать всё ©, а во-вторых, считают «мануальные» доклады слишком лайтовыми и скучными. А ещё часть людей в отзывах пишет, что хотели бы больше общих докладов (вроде рассказа про тестирование капитальных объектов — описание, слайды) и даже появления докладов про управление процессом тестирования (сейчас их, очевидно, нет).

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

С другой стороны, меня несколько смущает сама постановка вопроса.

No Such Thing as Manual Testing

В самом первом докладе самого первого Heisenbug (описание), слайды, YouTube) докладчик хорошо сформулировал: «No Such Thing as Manual Testing!» Очень рекомендую его посмотреть.

Если смотреть не готовы — дальше короткая выжимка из первой части доклада.

При обсуждении тестирования, в формировании своих взглядов на него, мы часто сталкиваемся с нарушениями системно-концептуальной модели или просто её отсутствием. Есть целые области тестирования, где внимание фокусируется на каких-то отдельных аспектах — совершенно не тех, которые нужны по смыслу. Сделанные таким образом тесты — бесполезны, а проверенная ими работа — мягко говоря, не идеальна.

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

В ту же кассу — стандартизация, ставшая результатом коммодизации методов тестирования. Знакомое слово — ISO 29119? (Не гуглите, это International Software Testing Standard). Какие-то системы выигрывают от стандартизации, а какие-то — нет. Например, розеткам лучше быть одинаковыми. А вот тестирование ПО, наоборот, выигрывает от разнообразия. Чем больше разнообразия, тем вероятней найти в тестируемом продукте что-то интересное.

Иногда мы совершенно бессмысленно фокусируемся не на самой работе, а на вспомогательных и промежуточных результатах этой работы. Составление тест-планов разных типов и видов, которое занимает 7 часов из 8 в день. И всё это — только чтобы показать менеджеру, как мы продвигаемся, с точностью до второго знака после запятой. Всё это плохо и неправильно. Тестировщик — это не написатель бумажек, а человек, занимающийся решением действительно интересных задач.

После этого докладчик переходит к животрепещущей теме: ничего не автоматизировать vs. автоматизировать всё. Первый вариант — это каменный век, и ни один человек в здравом уме на такое не согласится. Второй обычно невозможен: или это стоит слишком дорого, или просто невозможно.

Обсуждение иллюстрируется примером MVP (minimum viable product) калькулятора с кнопками для выполнения сложения «2 + 2». Очень забавный пример, это надо смотреть. ссылка на YouTube). Докладчик собирает мнения аудитории о том, какие тест-кейсы нужны, и потом демонстрирует, что аудитория даже на таком простом примере многое не обнаружила. Идея в том, что у нас есть куча неявных предположений о поведении. Куча вещей, которые мы не можем предвидеть. Задача слишком сложна, чтобы в общем случае решить её для произвольно большой системы. Вывод: человек — это машина для поиска смысла в разных ситуациях (как стандартных, так и нестандартных), использование человека для этого — наиболее эффективное решение.

Дальше докладчик задает нам вопрос: а в чём, собственно, суть нашей работы как тестировщиков? Скорее всего, в доставке информации о качестве продукта заинтересованным лицам (типа стейкхолдеров или руководителей разработки).

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

Что касается автоматизации тестирования, то не все тесты являются pass/fail-тестами, даже если они сформулированы как проверки. Не всегда провалившийся тест означает, что у нас есть проблема. Часть тестов обязательно будут то срабатывать, то не срабатывать. Если ВНЕЗАПНО всё стало зелёным — обычно это не повод для радости «как у нас всё хорошо», а, скорее, повод быстро начать проверку: где же мы накосячили. Или, например, если внезапно все тесты стали красными, то это, скорее, из-за поломанной среды тестирования, чем из-за того, что разработчики сломали весь код за один вечер. Ты как человек (машина для поиска смысла) в этом разберёшься гораздо лучше, чем хитро написанная эвристика. Тем не менее, автоматика в этой области справляется очень хорошо.

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

Например, если посмотреть на это таким образом, то окажется, что TDD — это не «тестирование» в чистом виде. Оно не находит новую информацию, а только проверяет существующую. (Докладчик ссылается на закон необходимого разнообразия Эшби). Скорее, это такая особая, живая документация.

В результате докладчик приходит к центральной идее доклада: «No Such Thing as Manual Testing». Он спрашивает аудиторию: «А есть ли среди вас разработчики-программисты?» Несколько человек поднимают руки. Следующий вопрос: «А вы мануальные разработчики или автоматические? Вы нажимаете кнопки на клавиатуре, вводите всякие штуки в IDE — очевидно, что вы мануальные?» (Там есть забавная дискуссия на эту тему, можно посмотреть на YouTube. Все смеются.

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

Если же мы говорим, что часть работы — это некое «мануальное» тестирование, то обычно под этим подразумевается, что его выполняет кто-то куда менее опытный и неразумный, чем ты. Условно говоря, берём бомжа с улицы и заставляем фигачить по плану, от корки до корки. Обычно как бы подразумевается, что «мануальное тестирование» делается только потому, что ещё не готовы его «автоматизировать». Эта дихотомия заложена в самом слове «мануальное тестирование».

На самом деле, работая тестировщиком, ты приносишь пользу разными способами. Иногда помогает автоматизация, иногда — работа по тест-плану, иногда — глубокие эксперименты. В начале проекта много хорошего можно сделать, просто задавая правильные вопросы коллегам. Если мы решились выбросить термин «мануальное тестирование», можно задуматься вот над чем: насколько сильно мы используем инструменты в своей деятельности? Мы не можем жить без инструментов (даже клавиатура — это инструмент, а ещё никто не научился вводить код силой мысли), и разные задачи требуют разной степени интеракции с ними, но самая главный элемент — это ты и твоя способность поиска смысла.

Выводы

Там ещё половина доклада, но давайте вернёмся к изначальному холивору. Если взглянуть на программу предыдущего Heisenbug, доклады можно легко распределить по градиенту интерактивности от 0 до 10. Начиная от «Инструментов тестировщика» Юлии Атлыгиной, который ближе к левой части, и заканчивая укрощением Docker с помощью TestContainers Сергея Егорова. С этой точки зрения, между лагерями «мануальщиков» и «автоматизаторов» нет особых противоречий, и доклады будут полезны всем.

Конечно, с определёнными оговорками: тестировщику для быстрого восприятия докладов по автоматизации нужно иметь определённый уровень понимания программирования, а программисту — кругозор в большом количестве связанных тем одновременно (а не только в своём одном любимом инструменте типа Java или .NET). Но ничего сверхъестественного. На сайте программы рядом с каждым докладом есть специальные значки («смузи», «бородач» и «хардкор»), которые показывают необходимый уровень погружения в тему. Не имеет смысла ходить на «хардкор» в чужой теме (ничего не поймёте вообще), а вот поход на «хардкор» в «своей» теме может оказаться полезным. Как всегда будут дискуссионные зоны, в которых можно найти интересующего докладчика и допросить с пристрастием — докладчики очень хорошо знают свою тему и могут ответить даже на самые странные вопросы.

Короче, на мой взгляд, ничего невозможного в идее нахождения под одной крышей «мануальщиков» и «автоматизаторов» нет, а само такое разделение у нас появилось исключительно в результате искаженной системы верований относительно современных IT-реалий. Make Heisenbug, not war.

Напоминаем: за актуальной информацией о Heisenbug 2018 Piter и за билетами надо обращаться на сайт конференции.

Tags from the story