Анонс конференции Heisenbug 2018 Piter. Make Heisenbug, not warǃ
Конференция: Heisenbug 2018 Piter
Дата: 17–18 мая 2018 года
Место: Санкт-Петербург, Гостиница «Park Inn by Radisson Пулковская»
Четвёртому по счёту Heisenbug официально быть. Между двумя Heisenbug проходит шесть месяцев. Это большой срок, который позволяет вам научиться жить с полученной информацией, а нам — улучшить конференцию.
Анализ отзывов участников
Перед написанием этого анонса я открыл отзывы участников и просмотрел 292 ответа. Основная тема половины отзывов — необходимость (или её отсутствие) иметь доклады по мануальному тестированию. Это то, что я хотел бы обсудить с вами.
На позапрошлый 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.
Следующие шаги
Call for Papers!
Конференция Heisenbug 2018 Piter состоится 17–18 мая этого года. Это большая техническая конференция для специалистов в области тестирования. Здесь соберутся все: тестировщики, программисты (разрабатывающие тесты для своего кода), специалисты по автоматическому, нагрузочному и другому тестированию, менеджеры команд тестировщиков и так далее.
Поэтому нам нужны доклады! Ты тоже можешь сделать доклад.
(И, если сделаешь, бесплатно попадёшь на конференцию, конечно.)
Быстро и решительно развею несколько сомнений.
Многие считают, что им нечего рассказать. Одни из самых лучших докладов начинались именно с такого заблуждения. На самом деле, то, что для тебя может казаться рутиной, для кого-то станет откровением. Например, ты взял и хитрым образом отладил процесс нагрузочного тестирования — и всё, теперь для тебя это стало рутиной. Но для большинства людей это осталось такой же сложной задачей, за шанс услышать решение которой они сделают всё, что угодно. Прямо сейчас отвлекись на минуту от чтения этого поста и подумай, что бы ты мог рассказать.
Что делать, если ты никогда не думал о себе как о докладчике? Не знаешь, как правильно подавать материал со сцены, оформлять слайды и так далее? Не беда. У нас специально для этого есть люди, которые помогают всё делать — рассказывают, показывают, проводят тренировки. Это отработанная технология, на выходе получается не только проработанный доклад, но и понимание, как делать доклады вообще. Это шанс поработать с нашим Программным комитетом — такими людьми, как Никита Макаров (руководитель отдела автоматизированного тестирования в Одноклассниках), Андрей Сатарин из Яндекса и Владимир Ситников из Netcracker.
Да, у нас большая известная площадка, на которой присутствует конкуренция. Возможно, твой доклад не пройдёт сквозь отбор Программного комитета. Но даже в этом случае будут только плюсы: доклад, почти прошедший сквозь наш комитет, возьмут почти где угодно.
Напоминаю, что приём докладов закончится 14 февраля, т.е. всего через месяц. Если задумался о том, чтобы приехать с докладом, заполни форму регистрации прямо сейчас!
Нам в особенности интересны следующие темы:
- Автоматизация тестирования;
- Нагрузочное тестирование;
- Performance-тестирование, бенчмаркинг;
- Интеграционное тестирование модульных/распределённых систем;
- Concurrency testing;
- Тестирование мобильных приложений;
- Ручное тестирование;
- UX, Security, A/B, статический анализ кода, метрики кода и продукта и т. п.;
- Инструментарий, окружение для тестирования;
- Сравнение инструментов для тестирования;
- Тестирование в GameDev;
Если твоя тема относится к тестированию, но не подходит в точности под одно из этих описаний — всё равно присылай, разберёмся.
Product placement и прочие рекламные доклады не принимаются, а предлагающие их люди берутся на карандаш (мы предупредили).
Для участников
Что можно сделать дальше?
Во-первых, написать в комментарии, что вы про всё это думаете. Согласны ли вы со мной? А с Ilari Henrik Aegerter и докладом «No Such Thing as Manual Testing»? Прямо сейчас напиши комментарий, а то забудешь.
Во-вторых, программа конференции всё ещё не зафиксирована. В комментариях можно рассказать, на каких докладах хочется побывать. Можно даже просить конкретных докладчиков! Единственное правило — нельзя требовать повтора старого доклада (старые доклады можете потом посмотреть на нашем канале на YouTube, когда они станут доступны всем).
Ну и главное: вы можете приехать на Heisenbug 2018 в Питер или присоединиться к онлайн-трансляции. Билеты можно приобрести на официальном сайте конференции.
