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

Зато уже через два месяца - следующая конференция SQAdays, на этот раз в Москве. И, может быть, кто-то прочитав этот отчет вдохновится, и решит съездить, а может быть даже сделает доклад! Организаторы этому всегда рады!

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

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

Помимо инженерных, на конференции много докладов, касающихся управления и организации людей. Что естественно, поскольку успешные тестировщики становятся организаторами тестирования в той или иной роли: руководя группой, организуя работу начинающих, взаимодействуя с заказчиками и во многих других ролях. IT очень гибко подходит к распределению обязанностей, по факту, никаких стандартных профилях говорить нельзя, и хотя должности называются одинаково - разработчик, тестировщик, аналитик, руководитель проекта, границы ответственности и обязанностей между ними в разных компаниях различно. А уж организация управления проектами, разделение обязанностей между руководителями отдела и проекта, аккаунтами, HR, наставниками различается еще сильнее.

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

1. Сотрудник - активный, хочет развиваться и сам определяет свои цели. Не все такие на входе, таким надо помочь. Но если он не хочет быть активным - он не перспективен, независимо от технических навыков.
2. Руководитель - лидер и ведущий для сотрудников, которые растут. И их рост - одна из основных задач, что не удивительно на нынешнем дефицитном рынке IT-персонала.
3. С другими подразделениями, заказчиком и руководством отношения надо выстраивать из активной позиции. Как с партнерами. Нужно понимать, что у них есть собственные интересы, надо понимать их позицию и совместно приходить к понимаю, выстраивая кооперацию. И не надо думать, что это сделает руководство, что это решат регламенты, хотя и эскалация и апелляция к регламентам должны быть в арсенале инструментов.

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

А еще в ряде докладов была мысль о том, что каждая команда и каждый проект - индивидуальны и им нужен свой метод управления. И это - тоже черта времени.

Как я уже отметил, организация IT-проектов очень разнообразна. Поэтому не удивительно, что у многих профессионалов есть проблемы, по которым они не могут получить ответы в докладах. И на этой конференции организаторы попробовали расширить стандартный способ обсуждения таких проблем в частных разговорах, сделав barcamp - отдельную активность при которой ведущий задает тему и формат, а кейсы и вопросы для обсуждения предоставляют сами участники. Он шел два дня конференции довольно активно, конкурируя с докладами. Особенно интересной была длинная сессия обсуждений болей участников: люди рассказывали свои кейсы, и получали консультации от других участников. Так что я благодарен Алексею Федорову, энергия которого породила этот barcamp.

Я особо выделю доклад Ивана Евтуховича, потому что помимо технической части DevOps он нарисовал интересную картину будущего.

Развитие DevOps/NoOps инструментов. Что было, что есть, что будет. Иван Евтухович

Это был очень хороший доклад в широкой рамке. Не просто про DevOps, а про тренд цифровизации, в результате которого IT становится главной технологией бизнеса:

• в банках операционная работа переходит к автоматам, а люди создают новые продукты и поддерживают технологии,
• в такси и airbnb, alibaba платформа напрямую замыкает потребителей и поставщиков услуг
• и даже авиакомпании по сути конкурируют только на поле IT: цена перелета полностью посчитана, и примерно одинакова, самая главная стоимость - аренда аэропорта. И потому конкуренция - логистика плюс продажа билетов, а это исключительно поле IT.

Цифровые компании повернуты к потребителям своим софтом. А не людьми. Все компании становятся IT-компаниями, галвное для них - совершенствование и развитие софта. А значит они не могут работать на вендорских решениях. Надо работать на своем. А значит надо еще и забирать IT внутрь - иначе ты принадлежишь внешнему подрядчику.

И на этом фоне в 2008 появился DevOps. Ранее они были раздельны:

• Ops - софт работает всегда.
• Dev - поставка новых фич.
• И переброска релиза через стену.

А надо сотрудничество, совместная ценность.

Автор термина DevOps - Patrick Debois. Agile Infrastructure, распространение Agile на инфраструктуру. По-русски книгу читать невозможно.

• CAMS - Culture, Automatization (Delivery), Measurement, Share Knowledge (обмен знаниями Dev и Ops). О ней есть много статей.
• Программный продукт - то, работает в эксплуатации. А не то, что написано.
• Delivery Pipeline. Коммиты влекут поставку релизов. Средство Continuous Delivery. По-русски книгу читать невозможно.
• Авторы показали, что любой продукт можно довести до непрерывной поставки, принципиальных проблем нет.
• И там 3 конфликта команд -Dev - QA - Ops.

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

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

• Автоматическое управление конфигурацией. Идея: описание конфигурации должно соответствовать реальной конфигурации.
• Infrastrucure As Code - повторяемость окружений. Управление тестовыми средами, автоматически, по нажатию кнопки. При этом еще пропадают ошибки конфигурации.
• Новые системы мониторинга. Часто разработка не знает, как ведет себя продукт в продакшене (из соображений безопасности :)) Появились новые системы мониторинга, которые позволяют это проверять, управлять мониторингом.
• Самые разные базы данных и OpenSource в корпорации. И многие банки покупают, в том числе OpenSource. И появляются OpenSource вендоры - типа PostgreSQL Pro, но он не единственный.

Популярные инструменты, конкретные списки

• Конфигурации - будут закатываться
• CI
• Мониторинг. Grafana, Prometheus, Graphite
• Централизованное логгирование ELK, Graylog
• AWS/OpenStack/GCE/VMWare - облако для развертывание
• Jenkins Stage View

Недостатки DevOps - все-таки коммуникация имеет накладные расход, даже если ты ее наладил.

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

• Есть много недостатков в интеграции и поставке многих сервисов непрерывным образом.
• И тут созрел Docker, который делает стандартную поставку: как USB - если есть Docker-контейнер, то он запуститься, независимо от того, что внутри. Конечно, решив одну проблему, он принес свои недостатки: лишний уровень абстракции, надо переделать приложение и использовать ServiceDiscovery.
• Зато ресурсами могут заниматься компьютеры, а не люди. На эту тему есть продукты.
• И стандартная поставка в будущем - через аналог MarketPlace.

Дальше был провокационный на конференции тезис - ручного тестирования не останется. Но люди не испугались, потому что понятно, что его не остается в pipeline, а вот в разработке - пока останется, как часть разработки. А вот дальше - автомат, и тесты туда включаются.

Но при этом с автоматическим тестированием, которого требует pipeline - не все ясно. Например, как тестировать программы, содержащие machine learning - они же все время обучаются, там нет повторяемых эталонных результатов. И более простой вопрос - проверять по разным разрешениям - поехала верстка до неприемлемости или нет, глаз это неплохо видит, а вот комп?

В целом доклад энергичный, достаточно провокационный и экстремистский. Ответы на вопросы тоже - был вопрос готово ли образование готовить таких тестировщиков. И ответ: "Вы о чем спрашиваете? Нынешнее высшее образование - мертво, школа - тоже."

Ответственность за качество в разных ИТ-проектах. Максим Цепков

В своем докладе Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять я как раз рассматривал спектр различных способов разделения ответственности в разных проектах и способов их разделения. При этом я положил это на единые карты, используя V-диаграмму и диаграммы альф и жизненного цикла OMG Essence. Подробности - на странице доклада.

Диагноз по фотографии или лечим Cargo Cult и другие болезни без регистрации и смс. Алексей Виноградов

Очень яркий и содержательный доклад про проявления нескольких известных проблем сознания в IT. Проблем было три: Cargo Cult, Not Invented here, Эффект Данинга-Крюгера и утопленные расходы. https://sqadays.com/ru/talk/42782

Cargo Cult. Это весьма известная история - про самолеты во 2 мировой войны, реально прослеживают до конца 20 века. Плюс вроде было распространение между островами - они распространяли инфу, что если есть такое святилище - падают няшечки.

• А в докладе речь была о том, как Agile превращают в Cargo Cult с ритуалами и без смысла, да еще с фотографиями папуасов в качестве иллюстраций.
  • StandUp как статус-митинг.
  • Отказываемся от ручных тестировщиков, ведь Atlassian так сделал! Но Atlassian-то сначала сделал автотесты, а вот эту часть не повторяют
  • Аналогично, делают continious delivery потому что так делают известные компании, но не развертывают соответствуюoe, инфраструктуру, просто непрерывно обновляют боевые сервера в ручном режиме.
  • Решают организовать тестирование - и поручают это единственному junior-тестировщику
• Обобщая, это укладывается в два шаблона
  • Подражают без понимания ситуации, этим грешат многие менеджеры, копируя без рассмотрения технических аспектов. Хотя я бы полагал, что среди разработчиков, аналитиков или тестировщиков тех, кто копирует не разбираясь тоже хватает.
  • Внедрение нового без мастеров, без обучения, без обратной связи.
• Вопрос - как отличить карго-культ. Понять, у нас BDD - работает или карго-культ. Ответ - обратиться к эксперту, изнутри сложно.

Not Invented here синдром. Изобрести колесо, а не пользоваться готовым. Известен с 1960-х.

• Аргументы против существующего
  • Не достаточное качество
  • Зависимость от внешнего производителя
  • Недостаточная гибкость
  • Неподходящая лицензия
• Псевдоаргументы
  • Некогда искать и анализировать существующее.
  • Существующее не бесплатно. Это не только в России, это и в Германии тоже - "я сам сделаю за месяц чтобы не платить 99$ в год"
• Типичные ошибки
  • Бинарный выбор "все сами или только готовое"
  • Отбрасывание платных без анализа, преференция бесплатных без расчета
  • Желаемые требования путают с необходимыми (в том числе - лишние ограничения)
• Но! для Core business function собственные решения - это правильно.
  • Например, разработчики Excel сами написали компилятор C, потому что для них было критична стабильность выпуска, которую не обеспечивали существующие.
  • Собственный движок автотестов web, если у вас в продукте критичный web-функционал, и нужна быть уверенное тестирование, а к Selenium есть обоснованные претензии.
• Советы
  • Рассматривайте платные решения
  • Привлекайте консультантов на выбор решения - демонстрация консультанта может быть дешевле собственного анализа.
  • Не забывайте о возможности ветвления (fork) существующих решений
  • Пользуйтесь пробными версиями, а не только рекламными проспектами

Даннинг-Крюгер эффект. 1999. Оценка собственной компетентности человека.

• Для начала развлекуха - кто угадает изречение с фото автора без подписи.
  • Я знаю, что ничего не знаю - Платон.
  • Настоящее знание - знать степень своего невежества. Конфуций
  • Невежество чаще подкреплено невежеством, чем знанием. Дарвин
  • И так далее. Фотки - были без подписью.
• Следствия. Некомпетентный человек
  • не замечает свою некомпетентность
  • не замечает степень своей неадекватности
  • после обучения - понимает
• Подопытным давали задачи, а потом спрашивали "как вы думаете, как прошли тест". Оказалось, что 20% худших оценивали себя не ниже среднего. И наоборот, 10% лучших недооценивали себя, думали, что простое для них - просто для всех.
• Известен также как Синдром самозванца, статистически больше подвержены женщины.
• График - самооценка от опыта. Самооценка быстро возрастает до 100%, потом падает, и опускается ниже опыта. А потом постепенно поднимается.
• Интересно, что на известной картинке, которая легко ищется - фигня, не No nothing а Know nothing. И Нобелевской премии за него не было, хотя во многих статьях пишут, что была :) В общем, авторы статей подвержены тому же эффекту.
• Ложные мемы
  • Не показывает, что не компетентные более уверенны
  • Что кто-то объявляя себя экспертом - не компетентен
  • Что некомпетентные считают себя умнее.
• Показывает лишь собственную траекторию. И эту траекторию надо учитывать в рефлексивной оценке.
• Важно! Исходя из эффекта, если кто-то не компетентен - недостаточно ткнуть носом. Надо обучить до уровня, когда он начнет понимать.

Sunk Costs Fallacy. Утопленные расходы.

• Дилемма. Два проекта с разной ожидаемой прибылью 5 и 6 млн при прочих равных - выбор понятен. Но! а вот в прошлом году мы на исследования по проекту A потрачено 2 млн. И все - мы не можем это бросить. И выбираем не то.
• Пример - выбрали фреймворк, ошиблись, мучаемся. И не меняем на другой -уже столько вложено. Или пользуемся купленным, неудобным софтом. В общем, не признаем ошибки прошлого. Более того, в прошлом это могло быть не ошибкой, просто компетенций не хватало.
• Прошлые расходы не должны быть аргументом решений о будущем. Это приносит ущерб компании.

Обратная связь и целеполагание, как маяки надежды тестировщика. Алексей Петров

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

Как протестировать тим-лидера. Татьяна Синтина

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

Четко, структурно, по составляющим

• Человеческий фактор
• Инструменты
• Навыки

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

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

Синергия распределенной QA-команды. Преодолеваем трудности. Инна Смирнова

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

Для Инны теорией по командам была книга Патрика Ленсиони "5 пороков команды". Почему? А потому что эту книгу "почему-то активно советуют" :)

И дальше в докладе Инна шла по пирамиде, описанной Ленсиони, и сопоставляла теорию с практикой.

• Недоверие
• Боязнь конфликтов
• Безответственность
• Нетребовательность
• Безразличие к результатам команды - зато статус и самолюбие

В распределенной команде пороки усиливаются, а то, что команда тестировщиков - вносит акценты.

Основная ценность доклада - в том, что Инна не следовала Ленсионе, а включила голову и активно смотрела на ситуацию, пробовала варианты. Например, недоверие. Способ борьбы - повысим прозрачность. Но не через отчетность, а через взаимопомощь и доверие. Тезис - правильный, а вот инструменты из книги - совместный спорт, рассказы о себе, как оказалось, не работают - и был поиск других.

А дальше был аналогичный разбор по ряду других теорий.

• Типы команд. Баркера
  • Функциональные и творческие
  • Постоянные и временны
  • Кроссфункциональные и интактные
  • Контролируемые и самостоятельные
• С ними надо по разному.
• Особенность тестировщиков - у них не цель, а миссия, не сыграть концерт, а играть музыку.
• Модель жизненного цикла команды Такмана Forming - Storming - Norming - Performing. Ее любят советовать. Но практически состав меняется часто, и что - вечный storming?
• Модель изменений Левина. Вывести из равновесия, ввести изменения, заморозить.
• Командные роли Белбина. Их распределение - способствует синергии команды. В этом месте была ссылка на мой мой доклад с высокой оценкой - услышать ее было очень приятно.

Синергия команды

• Разделение труда - компетенции и роли
• Специализация - каждый эксперт
• Координация. Вместе - круче, шаринг задач
• Интеграция, влияние на принятие решений, неопределенность

Поле самоорганизации, улучшений, способность повлиять на решения

А еще есть магия, она же кристаллизация.

И они пишут стихи - про баги и про клиента. И клиент пишет про них.

Пирамида Тестирования через призму ROI калькулятора и прочая геометрия. Антон Семенченко

У Антона всегда интересные доклады, и этот не был исключением. Доклад был про индивидуальные методы методы тестирования, адекватные проекту - как их подбирать и настраивать.

Но чтобы подбирать индивидуальные методы, необходимо сначала сделать карту, на которую эти методы мы будем наносить. Этой картой является пирамида тестирования, которую разные профессионалы рисуют по-разному. Минимально - 3 слоя, UI - Service - Unit. А дальше увеличивают гранулярность, например 4 слоя, 6 слоев.

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

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

А определяется это с помощью ROI. Многие боятся и считают непонятной экономикой. А реально это ответ на вполне понятные и уместные вопросы. Сколько часов мы тратим сегодня на тестирование? Сколько будем тратить на автоматизацию? Когда придет возврат затраченных часов?

• Собираем - сколько тест кейсов, сколько прогоняем и обработка...
• Оцениваем автоматизацию - фреймворк, затраты на один тест, затраты на поддержку, и на запуски.
• И самый простой калькулятор. Сколько стоит сейчас на релиз, сколько будет. Цену автоматизации делим на Выигрыш.

Если не учитывать экономику, то пирамида тестирования часто получается перевернутой - потому что заказчику видны UI-тесты, а не Service и Unit, которые он не понимает. И надо отдельно обосновывать, что тесты в основании пирамиды - дешевле, и при этом позволяют сократить число UI-тестов.

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

Дальше было много самых разных историй про особенности проектов и тестирования в них, включая влияние разных рисков.

Нагрузочное тестирование быстро и сердито. Евгений Батищев

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

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

Интернет уязвимых вещей. Kateryna Ovechenko

Доклад про уязвимости интернета вещей - их много. Изучили код платформы Samsung и запросто сделали приложение, которое прикидывается монитором батареи, а реально меняет pin-код входной двери, и делает другие вредностные вещи. В общем-то дырки давно известны. И дальше шел призыв к разработчикам тщательнее подходить к безопасности и тестировать приложения. Это, конечно, правильно, но принципиально ситуацию не изменит. Потому что такое тестирование увеличивает стоимость и, как следствие, будет увеличивать цену изделия. А дальше возникает вопрос: если есть браслет для мониторинга шагов с протестированной безопасностью за 1500 и без него за 1000, сколько людей заплатит больше денег? Подозреваю, что очень мало. А значит производители будут на этом экономить. До тех пор, пока требования к безопасности не заложат в стандарт, обязательный для платформ, и их производители не сделают внешнее ограничение безопасности приложений. Но вот такой постановки вопроса в докладе не было - что, в общем-то, естественно - это доклад для другой конференции :) А с технической точки зрения рассказ был вполне профессиональным и интересным.

С чего начинается родина в автоматизации Qiwi Wallet. Сергей Матвеев

Хороший и структурный рассказ о том, как устроена автоматизация тестирования.

Как создаются тесты. Сначала - новый функционал - и тест-кейсы, выполняемые вручную. И после этого часть кейсов автоматизируют - это выделяют.

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

• бизнес-логика - логин по пользователю МТС
• хелпер - переход от бизнес-кейса "пользователь МТС" к его идентификатору, несколько вызовов.
• нижний уровень - логин по строке

Тесты бизнес-логики - не меняются с реализацией. А вот реинжиниринг функционала - меняет уровень хелперов.

Было монолитное приложение. А теперь идет перестройка на микросервисную архитектуру. И там - стратегия, разные виды тестов

• Unit testing - разработчик уверен, что микросервис работает как заложено
• Integrationg testing
• Component testing
• UI testing.

Автотесты в билде.

• pull request по github commit - тестирование билда.
• Мержи индивидуальных веток в develop build - другой task
• и так далее.

Автоматизация - постоянный процесс.

Тестовые данные - есть пул тестовых пользователей с разными характеристиками, выдается произвольный. А для некоторых тестов данные создаются внтури.

Как разработчиков заставить писать unit test? Он 6 месяцев показывал с реальными метриками, показывающими время на исправление багов - которые можно было бы занять написанием автотестов.

Между молотом и наковальней. Production Quality. Владимир Мордовин

Рассказ из Wargaming о том, как у них устроено тестирование и выпуск в продакшн Warship - корабликов.

• На альфа-тестировании выпуском занимались все функциональные тестировщики, было организовано дежурство тестировщиков по сопровождению релиза.
• А на бета-тесте организовали отдельную Release and localization Team. В их ответственности, в том числе, акции и предложения, работа с деплоем, поддержка и так далее.

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

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

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

Уровни тестов

• Супер-тест - закрытый тест для опытных пользователей. Около 300 человек. Для них - отдельный баг-трекер. Им управляют отдельные менеджеры, в центре и в регионах. Распределяют задание по сессиям, люди проходят, это трекают.
• Общий тест (ограничение по регистрации). Социальные сети. В том числе - форумы по общим тестам. И не везде форум WorldWarship - основное место тусовки пользователей, надо везде присутствовать.

По результатам обрабатывают статистику по багам.

• Дайджест - показ критических зон. Цифры и диаграммы. Чтобы пояснить диаграммы.
• А еще - дайджест впечатлений. Сбор зон внимания и неоднозначных мнений.
• Светофорные результаты общих тестов. При этом дальше - детализация в конкретные посты, чтобы дойти до фактуры. В том числе - для обращения разработчиков.

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

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

Интересно было про региональные особенности. Не только локализация, но и законодательство. Классика у них - Китай.

• Другие национальные флаги, символика флотов (японской хризантемы быть не должно), командиры без отличий (погоны, награды) - законодательство.
• Логотип - тоже на китайском, а он зашит глубоко. Да еще иероглифы должны быть правильного диалекта.
• Набор фичей. На входе в игру должна быть рекомендации об играх и здоровье "игрозависимость опасна для жизни".
• А еще - anti-online gameaddition system. Должно быть уменьшение бонусов - по законодательству. Через 2 часа предупреждение, после 4 - уменьшение дохода вдвое, после 6 - обнуление заработков.
• Отдельная площадка для Китая. Партнеры специально смотрят соблюдение правил.

Определение pass/fail критериев при тестировании и анализе производительности. Alexander Shinkarev

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

Был рассказан следующий подход.

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

Поэтому сместили фокус с потребления ресурсов на комфорт пользователей.

Далее было много деталей. Например, потребление памяти - не в Мб, а от максимально доступного в % для конфигурации.

А время отклика для пользователя

• 0-100мс Good - green
• 100-200 Acceptable - yellow
• 200-300 Need Attention - red
• более 300 - Very bad, black - так нельзя.

В докладе было много конкретных примеров метрик.

В светофорной модели мы смотрим не только позицию, но и переходы между зонами и направление изменений. Улучшения, пусть в красной зоне, означают что тест прошел, а вот ухудшения в красной или переход в красную - fail.

A/B тестирование или как принять верное решение. Nadezhda Shkuda

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

А дальше было вполне по делу - какие страницы исследовать, что исследовать, какие элементы. Анализ поведения аудитории. Измеряемые метрики. Занимается всем этим тестировщик - на практике. Хотя есть всякие варианты.

Были конкретные примеры гипотез Заменить SignUp на Free SignUp. Или бронирование отелей - вариант цветовой дифференциации против другой. И еще ряд примеров. Из интересного: для привлечения покупателей часто пишут цену со скидкой и полную рядом. И это очень хорошо работает - пока в ценах не возникает слишком много цифр и они перестают помещаться в комфортное поле - тогда надо менять конструкцию...