7884
правки
Изменения
Новая страница: «{{Conf-Ref}} С опозданием пишу отзыв о [http://sqadays.com/ru/index?eventId=40015 20 конференции SQAdays], которая был…»
{{Conf-Ref}}
С опозданием пишу отзыв о [http://sqadays.com/ru/index?eventId=40015 20 конференции SQAdays], которая была в конце ноября в Минске. И вовсе не потому, что конференция мне не понравилась. Наоборот, было много хороших докладов и интенсивное, конструктивное общение. И мне хотелось написать обстоятельный отзыв, по горячим следам это не получилось, все время были другие дела, но наконец очередь дошла.
Зато уже через два месяца - следующая конференция SQAdays, на этот раз в Москве. И, может быть, кто-то прочитав этот отчет вдохновится, и решит съездить, а может быть даже сделает доклад! Организаторы этому всегда рады!
Общее впечатление - конференция за несколько лет повысила уровень докладов. На ней по-прежнему много докладов для новичков в профессии, что не удивительно - именно активные, растущие в профессии сотрудники составляют основную массу участников. Но наряду с этим в программе есть доклады для тех участников, которые в профессии несколько лет и уже имеют приличный уровень. И хорошо, что конференция следует за зрелостью профессии: по мере того как в индустрии становится все больше опытных профессионалов, увеличивается их число среди участников, и становится больше докладов, интересных для них.
Дальше будет немного про конференцию в целом, а потом - обзор докладов. И я сразу хочу сказать, что я не смог приехать на первый, международный день конференции. А во второй день после своего доклада я ушел на barcamp отвечать на вопросы, а остался там на следующие сессии. Так что много докладов я пропустил, и не стоит думать, что я расскажу про все хорошие доклады конференции. А начну я со своего.
= Тренд - доклады про управление ==
Помимо инженерных, на конференции много докладов, касающихся управления и организации людей. Что естественно, поскольку успешные тестировщики становятся организаторами тестирования в той или иной роли: руководя группой, организуя работу начинающих, взаимодействуя с заказчиками и во многих других ролях. IT очень гибко подходит к распределению обязанностей, по факту, никаких стандартных профилях говорить нельзя, и хотя должности называются одинаково - разработчик, тестировщик, аналитик, руководитель проекта, границы ответственности и обязанностей между ними в разных компаниях различно. А уж организация управления проектами, разделение обязанностей между руководителями отдела и проекта, аккаунтами, HR, наставниками различается еще сильнее.
Тем не менее, в большинстве докладов по работе с сотрудниками можно выделить ряд положений, которые достаточно сильно отличают высказываемые позиции как от подходов традиционного менеджмента, так и от Agile-управления проектами. Именно поэтому я говорю о докладах по управлению и организации, не употребляя слова "менеджмент". Наиболее близко эта позиция, наверное, определяется словом "лидерство и коучинг", но при этом достаточно большая часть контекста относится к организации работы, взаимодействия с другими подразделениями, заказчиками, которые обычно находятся за рамками докладов по лидерству. Итак, тезисы.
# Сотрудник - активный, хочет развиваться и сам определяет свои цели. Не все такие на входе, таким надо помочь. Но если он не хочет быть активным - он не перспективен, независимо от технических навыков.
# Руководитель - лидер и ведущий для сотрудников, которые растут. И их рост - одна из основных задач, что не удивительно на нынешнем дефицитном рынке IT-персонала.
# С другими подразделениями, заказчиком и руководством отношения надо выстраивать из активной позиции. Как с партнерами. Нужно понимать, что у них есть собственные интересы, надо понимать их позицию и совместно приходить к понимаю, выстраивая кооперацию. И не надо думать, что это сделает руководство, что это решат регламенты, хотя и эскалация и апелляция к регламентам должны быть в арсенале инструментов.
Пожалуй, это основное. Эти позиции высказывались взвешено, как в великолепном докладе Алексея Петрова, или наоборот, провокационно-максималистски, как у Татьяны Синтиной. Оценка пассивного исполнителя как слабого сотрудника была у обоих. Но суть от этого ведь не меняется. Хотя восприятие доклада сильно разное, доклад Татьяны был сплошь заклеен отрицательными отзывами именно потому, что она четко формулировала необходимость активной позиции от сотрудника, в то время как Алексей говорил о выведении сотрудника в такую позицию. Может, в докладе Татьяны многие подсознательно узнали себя и это оказалось не слишком приятным? А может дело в том, что Татьяна делала упор на то, что ты сам должен занять активную позицию, а Алексей - на том, что руководитель должен к этому подталкивать. И оценки показывают, что люди любят, когда их подталкивают, и не любят развиваться самостоятельно.
А еще в ряде докладов была мысль о том, что каждая команда и каждый проект - индивидуальны и им нужен свой метод управления. И это - тоже черта времени.
= BarCamp =
Как я уже отметил, организация 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 - они же все время обучаются, там нет повторяемых эталонных результатов. И более простой вопрос - проверять по разным разрешениям - поехала верстка до неприемлемости или нет, глаз это неплохо видит, а вот комп?
В целом доклад энергичный, достаточно провокационный и экстремистский. Ответы на вопросы тоже - был вопрос готово ли образование готовить таких тестировщиков. И ответ: "Вы о чем спрашиваете? Нынешнее высшее образование - мертво, школа - тоже."
= Доклады про организацию =
== Ответственность за качество в разных ИТ-проектах. Максим Цепков ==
В своем докладе '''[[Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять (SQAdays-20, 2016-11)|Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять]]''' я как раз рассматривал спектр различных способов разделения ответственности в разных проектах и способов их разделения. При этом я положил это на единые карты, используя V-диаграмму и диаграммы альф и жизненного цикла OMG Essence. Подробности - на странице доклада.
==Диагноз по фотографии или лечим Cargo Cult и другие болезни без регистрации и смс. Алексей Виноградов==
Очень яркий и содержательный доклад про проявления нескольких известных проблем сознания в IT. Проблем было три: Cargo Cult, Not Invented here, Эффект Данинга-Крюгера и утопленные расходы.
'''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?
* Модель изменений Левина. Вывести из равновесия, ввести изменения, заморозить.
* Командные роли Белбина. Их распределение - способствует синергии команды. В этом месте была ссылка на мой [[Роли в команде - модель Белбина (Максим Цепков на SPMconf-2012)|мой доклад]] с высокой оценкой - услышать ее было очень приятно.
Синергия команды
* Разделение труда - компетенции и роли
* Специализация - каждый эксперт
* Координация. Вместе - круче, шаринг задач
* Интеграция, влияние на принятие решений, неопределенность
Поле самоорганизации, улучшений, способность повлиять на решения
А еще есть магия, она же кристаллизация.
И они пишут стихи - про баги и про клиента. И клиент пишет про них.
= Техники и подходы к тестированию =
==Пирамида Тестирования через призму 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==
Интересный доклад про критерии прохождения тестов для нагрузочного тестирования. Оно обычно выдает множество графиков. Можно формально накладывать ограничения, но реально для большинства из них не будет оснований, особенно в период интенсивного развития системы, а при нарушении придется каждый раз заново понимать: это реальное ограничение или произвольное.
Был рассказан следующий подход.
# Понятно, что не должны нарушаться ограничения платформы и, более того, по ним должен быть согласованный запас, а приближение к ним - сигнал для разработчиков.
# Резкая деградация характеристик очередного билда относительно предшествующего так же является сигналом. Но надо понимать, что рост потребления ресурсов часто не означает деградации для пользователя.
Поэтому сместили фокус с потребления ресурсов на комфорт пользователей.
Далее было много деталей. Например, потребление памяти - не в Мб, а от максимально доступного в % для конфигурации.
А время отклика для пользователя
* 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. Или бронирование отелей - вариант цветовой дифференциации против другой. И еще ряд примеров. Из интересного: для привлечения покупателей часто пишут цену со скидкой и полную рядом. И это очень хорошо работает - пока в ценах не возникает слишком много цифр и они перестают помещаться в комфортное поле - тогда надо менять конструкцию...
{{wl-publish: 2017-03-21 00:28:19 +0300 | MaksTsepkov }}
С опозданием пишу отзыв о [http://sqadays.com/ru/index?eventId=40015 20 конференции SQAdays], которая была в конце ноября в Минске. И вовсе не потому, что конференция мне не понравилась. Наоборот, было много хороших докладов и интенсивное, конструктивное общение. И мне хотелось написать обстоятельный отзыв, по горячим следам это не получилось, все время были другие дела, но наконец очередь дошла.
Зато уже через два месяца - следующая конференция SQAdays, на этот раз в Москве. И, может быть, кто-то прочитав этот отчет вдохновится, и решит съездить, а может быть даже сделает доклад! Организаторы этому всегда рады!
Общее впечатление - конференция за несколько лет повысила уровень докладов. На ней по-прежнему много докладов для новичков в профессии, что не удивительно - именно активные, растущие в профессии сотрудники составляют основную массу участников. Но наряду с этим в программе есть доклады для тех участников, которые в профессии несколько лет и уже имеют приличный уровень. И хорошо, что конференция следует за зрелостью профессии: по мере того как в индустрии становится все больше опытных профессионалов, увеличивается их число среди участников, и становится больше докладов, интересных для них.
Дальше будет немного про конференцию в целом, а потом - обзор докладов. И я сразу хочу сказать, что я не смог приехать на первый, международный день конференции. А во второй день после своего доклада я ушел на barcamp отвечать на вопросы, а остался там на следующие сессии. Так что много докладов я пропустил, и не стоит думать, что я расскажу про все хорошие доклады конференции. А начну я со своего.
= Тренд - доклады про управление ==
Помимо инженерных, на конференции много докладов, касающихся управления и организации людей. Что естественно, поскольку успешные тестировщики становятся организаторами тестирования в той или иной роли: руководя группой, организуя работу начинающих, взаимодействуя с заказчиками и во многих других ролях. IT очень гибко подходит к распределению обязанностей, по факту, никаких стандартных профилях говорить нельзя, и хотя должности называются одинаково - разработчик, тестировщик, аналитик, руководитель проекта, границы ответственности и обязанностей между ними в разных компаниях различно. А уж организация управления проектами, разделение обязанностей между руководителями отдела и проекта, аккаунтами, HR, наставниками различается еще сильнее.
Тем не менее, в большинстве докладов по работе с сотрудниками можно выделить ряд положений, которые достаточно сильно отличают высказываемые позиции как от подходов традиционного менеджмента, так и от Agile-управления проектами. Именно поэтому я говорю о докладах по управлению и организации, не употребляя слова "менеджмент". Наиболее близко эта позиция, наверное, определяется словом "лидерство и коучинг", но при этом достаточно большая часть контекста относится к организации работы, взаимодействия с другими подразделениями, заказчиками, которые обычно находятся за рамками докладов по лидерству. Итак, тезисы.
# Сотрудник - активный, хочет развиваться и сам определяет свои цели. Не все такие на входе, таким надо помочь. Но если он не хочет быть активным - он не перспективен, независимо от технических навыков.
# Руководитель - лидер и ведущий для сотрудников, которые растут. И их рост - одна из основных задач, что не удивительно на нынешнем дефицитном рынке IT-персонала.
# С другими подразделениями, заказчиком и руководством отношения надо выстраивать из активной позиции. Как с партнерами. Нужно понимать, что у них есть собственные интересы, надо понимать их позицию и совместно приходить к понимаю, выстраивая кооперацию. И не надо думать, что это сделает руководство, что это решат регламенты, хотя и эскалация и апелляция к регламентам должны быть в арсенале инструментов.
Пожалуй, это основное. Эти позиции высказывались взвешено, как в великолепном докладе Алексея Петрова, или наоборот, провокационно-максималистски, как у Татьяны Синтиной. Оценка пассивного исполнителя как слабого сотрудника была у обоих. Но суть от этого ведь не меняется. Хотя восприятие доклада сильно разное, доклад Татьяны был сплошь заклеен отрицательными отзывами именно потому, что она четко формулировала необходимость активной позиции от сотрудника, в то время как Алексей говорил о выведении сотрудника в такую позицию. Может, в докладе Татьяны многие подсознательно узнали себя и это оказалось не слишком приятным? А может дело в том, что Татьяна делала упор на то, что ты сам должен занять активную позицию, а Алексей - на том, что руководитель должен к этому подталкивать. И оценки показывают, что люди любят, когда их подталкивают, и не любят развиваться самостоятельно.
А еще в ряде докладов была мысль о том, что каждая команда и каждый проект - индивидуальны и им нужен свой метод управления. И это - тоже черта времени.
= BarCamp =
Как я уже отметил, организация 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 - они же все время обучаются, там нет повторяемых эталонных результатов. И более простой вопрос - проверять по разным разрешениям - поехала верстка до неприемлемости или нет, глаз это неплохо видит, а вот комп?
В целом доклад энергичный, достаточно провокационный и экстремистский. Ответы на вопросы тоже - был вопрос готово ли образование готовить таких тестировщиков. И ответ: "Вы о чем спрашиваете? Нынешнее высшее образование - мертво, школа - тоже."
= Доклады про организацию =
== Ответственность за качество в разных ИТ-проектах. Максим Цепков ==
В своем докладе '''[[Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять (SQAdays-20, 2016-11)|Ответственность за качество в разных ИТ-проектах: в чем она и как ее разделять]]''' я как раз рассматривал спектр различных способов разделения ответственности в разных проектах и способов их разделения. При этом я положил это на единые карты, используя V-диаграмму и диаграммы альф и жизненного цикла OMG Essence. Подробности - на странице доклада.
==Диагноз по фотографии или лечим Cargo Cult и другие болезни без регистрации и смс. Алексей Виноградов==
Очень яркий и содержательный доклад про проявления нескольких известных проблем сознания в IT. Проблем было три: Cargo Cult, Not Invented here, Эффект Данинга-Крюгера и утопленные расходы.
'''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?
* Модель изменений Левина. Вывести из равновесия, ввести изменения, заморозить.
* Командные роли Белбина. Их распределение - способствует синергии команды. В этом месте была ссылка на мой [[Роли в команде - модель Белбина (Максим Цепков на SPMconf-2012)|мой доклад]] с высокой оценкой - услышать ее было очень приятно.
Синергия команды
* Разделение труда - компетенции и роли
* Специализация - каждый эксперт
* Координация. Вместе - круче, шаринг задач
* Интеграция, влияние на принятие решений, неопределенность
Поле самоорганизации, улучшений, способность повлиять на решения
А еще есть магия, она же кристаллизация.
И они пишут стихи - про баги и про клиента. И клиент пишет про них.
= Техники и подходы к тестированию =
==Пирамида Тестирования через призму 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==
Интересный доклад про критерии прохождения тестов для нагрузочного тестирования. Оно обычно выдает множество графиков. Можно формально накладывать ограничения, но реально для большинства из них не будет оснований, особенно в период интенсивного развития системы, а при нарушении придется каждый раз заново понимать: это реальное ограничение или произвольное.
Был рассказан следующий подход.
# Понятно, что не должны нарушаться ограничения платформы и, более того, по ним должен быть согласованный запас, а приближение к ним - сигнал для разработчиков.
# Резкая деградация характеристик очередного билда относительно предшествующего так же является сигналом. Но надо понимать, что рост потребления ресурсов часто не означает деградации для пользователя.
Поэтому сместили фокус с потребления ресурсов на комфорт пользователей.
Далее было много деталей. Например, потребление памяти - не в Мб, а от максимально доступного в % для конфигурации.
А время отклика для пользователя
* 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. Или бронирование отелей - вариант цветовой дифференциации против другой. И еще ряд примеров. Из интересного: для привлечения покупателей часто пишут цену со скидкой и полную рядом. И это очень хорошо работает - пока в ценах не возникает слишком много цифр и они перестают помещаться в комфортное поле - тогда надо менять конструкцию...
{{wl-publish: 2017-03-21 00:28:19 +0300 | MaksTsepkov }}
