2013-11-10: SQAdays - потрясающая энергетика

Материал из MaksWiki
Перейти к: навигация, поиск
Короткая ссылка: SQAdays-14-mtsepkov
О других конференциях

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

SQAdays-14-открытие.jpg

Конференция собрала много участников и проходила на стадионе, так что можно с полным основанием говорить, что конференция тестировщиков собирает стадионы :) И, кстати, Львов — прекрасный город, который я хотел посмотреть и потому приехал сильно рано. Впечатления и фотки — у меня в ЖЖ.

Было много докладов от новичков и для новичков, особенно в первый день: те, кто сделали успешные шаги делятся с другими тем, что и как они делают. Потому что они помнят о своем трудном пути, и хотят поделиться с другими, чтобы им было легче делать свое. В таких докладах нет идеи «сделай как я и будет успех», но и нет еще достаточно опыта чтобы представлять альтернативы и уместность тех или иных практик в условиях конкретных проектах и подать материал на таком уровне.

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

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

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

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

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

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

Кстати, если говорить об инструментах, то большинство современных тестировщиков не используют какую-нибудь одну среду, а пользуются множеством подходящих инструментов различного назначения. Которые как-то несложно совмещаются и интегрируются друг с другом. И у профессионалов при этом получается довольно цельный фреймворк, который они, к тому же, легко модифицируют под разные цели проектов, попутно дописывая свое по необходимости. Подробнее можно посмотреть доклад Никиты Гавриша — как они собирали фреймворк. Если говорить об аналогах, то это похоже на Linux и Java-мир, в отличие от подхода комплексных фреймворков одного вендора, который больше напоминает мир Windows и .Net с его Visual Studio. И это логично, потому что мир проектов сейчас очень разнообразен, технологии развиваются быстро, и производители фреймворков за этим не успевают, в то время как написать отдельные утилиты можно гораздо быстрее, это делают компании, занимающиеся тестированием, и, что интересно, многие из них выкладывают в свободный доступ, или распространяют за небольшие деньги — в отличие от тяжелых вендорских фреймворков. Обзоры инструментов и рассказ про конкретные были во многих докладах, и я бы хотел тут отметить прекрасный доклад Мясникова и Косарева на эту тему, который они сделали за один день как замену другого доклада. Этот тренд — компоновка цельных фреймворков из различных утилит — я уже отмечал на прошлых конференциях.

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

Было несколько докладов про совмещение ролей аналитика и тестировщика. Интересно, что несколько лет назад я делал доклад на SQAdays об этом. Тогда перед конференцией статью с тезисами доклада опубликовали на форуме software-testing и в дискуссии оппоненты говорили, что совмещение не получится, потому что тестировщик нацелен на разрушение, а аналитик — на созидание. Что мне это было странно, потому как у нас в компании такое совмещение есть с самого начала. С тех пор веяния изменились, и теперь совмещение никого не удивляет, а воспринимается конструктивно и правильно, доклад вызвал интерес у участников.

А еще на конференции было много докладов в теме «другое». И это правильно — потому что время узких специализаций прошло, и надо выходить из этих границ. Интересно, что в Европе специализация тестировщика постепенно исчезает, это звучало в обсуждениях. Хотя я думаю, значительный вклад в это даент аутсорс тестирования в Индию и к нам, в Россию, Украину и Белоруссию. И будет ли эта ниша конкурентроспосбоной, или мы ее перерастем, оказывая комплексные, а не специализированные услуги — время покажет. В любом слуаче, надо смотреть вокруг, понимать свое место в нем. Поэтому доклады про личностный рост и коммуникации — уместны и востребованны участниками.

И перед обзором хочу отметить те доклады, которые мне особенно понравились.

  • Андрей Ребров. Тестирование в Agile для больших команд: путь трансформации. Рассказ был про конкретный кейс в одной из компаний. И успешный: повысили скорость поставки фич в 5 раз, поставки стали регулярными 2-3 раза в неделю, ушли от работы по выходным и по ночам. Повысилась удовлетворенность работой.
  • Владимир Кривенко. Особенности тестирования NoSQL приложений. В блиц-доклад Владимир уложил все: от ликбеза до достаточно сложных особенностей NoSQL-тестирования. Круто.
  • Никита Гавриш. Внедрение автоматизации на Selenium в highload-проект. Речь шла о разных кейсах команд-проектов внедрения техники автотестов, постановки процесса. С чем надо быть готовым столкнуться.
  • Дарья Костюк. Альпинизм в тестировании или восхождение на вершину карьеры. Доклад про планирование личностного роста и следование плану. Начало было совсем замечательное: вдохновение профессии, про самореализацию в том, чтобы сделать мир лучше.
  • Станислав Косарев. Андрей Мясников. Джентльменский набор тест-лида. Очень хороший обзор различных вспомогательных инструментов, нужных тестировщику. Которые позволяют эффективно решать очень многие задачи.

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

А теперь — обзор докладов по темам, внутри доклады упорядочены по месту в программе.

Содержание

Инструменты для тестировщиков

Кроме перечисленных ниже докладов, об инструментах рассказывал Никита Гавриш в своем докладе.

Алексей Лупан, Олег Колька. Excel всё подскажет или «Вот сколько времени понадобится на тестирование»

SysIQ & Astound Commerce. Киев, Украина

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

Были интересные фенечки, например, оценка степени удовлетворенности пользователей.

Татьяна Зинченко. PairWise и тестинг инструменты

Inter Technology Group. Simferopol, Ukraine.

Про уменьшение числа тесткейсов Pair-Wise. Обычно его, конечно, сравнивают с общим перебором. Но это неправильно.

Есть методики, тулы, как именно в разных инструментах, подбирать разные параметры. AllPairs, PICT и так далее,Ю список можно посмотреть на pairwise.org. Смысл тула — вы для каждого параметра задаете списки значений, а он сам делает комбинации, алгоритмы можно параметризовать. Собственно, тулы — это отделение тестовых данных от кода, фреймворки.

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

Ольга Киселева. Автотесты на уровне API для Java-приложений

HFLabs. Москва, Россия

На доклад зашел в самом конце, так что содержание представляю не полностью. В числе прочего — был представлен собственный свободный фреймворк для тестирования на Java. Что интересно — там заполнение данных, например, для перекладки тестовых данных из Excel в БД с привязкой по именам и т. п. А еще — рассказывали про процесс у них. Например, решения про то, требовать ли исправления тесткейсов или пометить его скипнутый, поставив баг в следующий релиз.

Станислав Косарев. Андрей Мясников. Джентльменский набор тест-лида

Нижний Новгород, Москва, Россия.

Предупреждаю: список неполон, я слушал не с начала.

  • Рассылка SMS. GoogleDocs — замечательно посылает бесплатные SMS. Тесты свалились — CI ставит event в google docs календарей пользователя (он туда лезет, безопасность не появляется) — они получают сообщения, потому что у них настроено.
  • Teamer
  • Будильник. http://budist.ru/ Пишешь свой номер, тебе люди звонят и будят.
  • Писалки. Notepad++, Gedit, Vim, GNUnano, WebStorm. Подсветка синтаксиса.
  • Let’s sniff. Анализ пакетов, изменение пакетов, контроль трафика. Кейс, когда кто-то из программеров чего-то написал

Wireshark и др. Тестировщики — не забывают смотреть, как идет логин и пароль реально.

  • Запись клавиш и мышек. AutoIt, Automator, UOPilot. UOPilot — была игра, там надо было прокачиваться. И фанаты написали штуку, которая цеплялась к окошку и делала что скажешь на простом скрипте. А теперь замечательно это делать не только для игры :)
  • Скринкастинки. screencast-o-matic.com, Camtasia (50$), Adobe Captivate. Они посетовали, что не нашли бесплатной. На самом деле, бесплатная есть, ее сделал Стас Фомин, когда работал над записью конференций, смотри на http://4intra.net/ Screen2Log и ConferenceRecorder, обе доступны в исходных текстах.
  • MindMaps.
  • TeamViewer, VNC. Teamviewer — не надо устанавливать, можно просто запустить. И это плюс для многих, где следят за установкой ПО.
  • Средства общения — Skype, Jabber, Teamspeak — комнаты с голосовым общением, Raid call — аналогично teamspeak, но с няшным интерфейсом, Google talk / Hangout.
  • Плагины. Баранцев весной на конфетке. Там дофига. Для проверок сайтов.

А в конце были ролики. Демо AutoIt — на нем можно автоматизировать минера замечательно. Правда, собственный язык дурацкий, но есть API к Ruby, и получается хорошо. Другие ролики показать не успели, но можно было посмотреть в холле.

Continious Integration и Delivery

На эту тему был роскошный доклад от Badoo, только меня на нем не было — я слушал их на одной из прошлых конференций и потому решил послушать параллельные треки.

Максим Колотилкин. Автоматизация настолько хороша, насколько хорош человек использующий ее

Wix. Днепропетровск, Украина

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

Руфина Сарварова. CI: Автоматизация сборки, развёртывания и тестирования

Fujitsu Russia GDC. Казань, Россия

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

Тестирование интеграции (ETL, ESB и другие)

Сергей Сташенко. Особенности тестирования ETL-процессов

Luxoft. Киев, Украина.

Рассказ о тестировании ETL-процессов. Сложности тут и в больших объемах данных, и в том, что эта задача подразумевает тестирование производительности, и в том, что надо порождать тестовые наборы данных, удовлетворяя ограничениям, и нельзя многократно догружать одно и то же, и сравнение — множественное. Они используют инструмент Informatica PowerCenter и он им много с чем помогает.

Александра Волкова. Тестирование Enterprise Service Bus: Что? Где? Как?

Itera Consulting. Киев, Украина

Доклад — пошаговая инструкция как тестировать ESB в разных режимах: синхронное взаимодействие, асинхронное. Какие варианты надо проверить, где ставить заглушки. Для меня — понятная и очевидная. Но раз доклад — значит не для оно всех очевидно.

А еще им хорошо — у них есть тестовый интеграционный стенд, приближенный к боевому. Это бывает не у всех, и из одной крупной конторы мне рассказывали, что интеграционное тестирование возможно только на проме, при чем создание каждого тестового документа требует отдельного согласования :)

Михаил Дырда, Александра Волкова. В поисках магической кнопки, или как воспитать SoapUI

Itera Consulting. Киев, Украина

На этот доклад я не пошел, а в твитере много хороших отзывов. Жаль.

Тестирование в конкретных областях

Лариса Сафина. Тестирование Retail систем

Казань, Россия

Хороший доклад про тестирование retail-систем. Особенность в том, что в точках продаж (PoS) — много реального оборудования и тестировать нужно с ним, эмуляторы тут неуместны, так как эмулируют плохо. Даже печать на спец.принтерах, типа кассовых. надо проверять реально и глазками, картинка в PDF и на бумаге может сильно отличаться. Так что баланс между автоматизированным и ручным тестированием имеет свои особенности.

Владимир Кривенко. Особенности тестирования NoSQL приложений

Paralect. Минск, Беларусь

MongoDB. Они выпустили собственный бесплатный инструмент для них — который обошел по запросов родные. Есть блог на тему.

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

В блиц-доклад Владимир уложил все: от ликбеза до достаточно сложных особенностей NoSQL-тестирования. Круто.

От тестировщика к аналитику

Вера Кушнарева. От тестировщика к аналитику: путь развития

Fujitsu Russia GDC. Казань, Россия

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

И дала список компетенций, который они используют.

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

Интересно, что предметная область в дополнительных компетенциях, в конце списка, перед ин.язом.

И дальше Исследовательские группы, план развития, индивидуальные планы, квартальные цели. «Так как компания большая, то естественно она процессная :) И индивидуальный план повышает процессность компании.». Во многом они строят конструкцию управления знаниями. То есть молодцы.

Максим Псарев. Тестирование и Бизнес-анализ в agile проектах. Совмещая разделять

DataArt. Воронеж, Россия

По опыту 4 проектов, стартапы. Про совмещение аналитика и тестировщика, с рассмотрением типичных ошибок на этом пути.

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

И рассматривал плюсы и минусы, которые стоит принимать во внимание.

Ольга Павлова. Синтетические фокусы-II: что делать за пределами зоны аналитического комфорта

КБ «Собака Павлова». Санкт-Петербург, Россия

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

  • Отличать факты от гипотез
  • Умение объяснять факты
  • Формулирование гипотезы. Гипотеза как движущий инструмент.
  • Управление жизненным циклом (всем массивом материалов).
  • Конструирование, эксперименты
  • Выявлять численные показатели
  • Беспокоиться о расхождении представлений с реальностью
  • Отличать главное от второстепенного
  • Писать понятно, рисовать схемы
  • Задавать вопросы по-существу
  • Объяснять, что такое хорошо что такое плохо
  • …

Всем этим должен заниматься аналитик. У нас в компании, кстати занимается — у нас хорошие аналитики.

Процессы тестирования

Андрей Июдин. Как принести пользу разработке и упростить себе жизнь?

ЗАО «БАРС-Груп». Казань, Россия

Это доклад о том, как в большом проекте который ведется в «допотопном» стиле, то есть без документации, декомпозиции, понимания внутренних связей, тестировщики самостоятельно и постепенно строили процесс. Включая декомпозицию системы на модули для специализации своей работы, документирование и так далее, выполняли реверс-инжиниринг проекта, данного в ощущениях. При этом их позвали, чтобы разгрузить аналитиков — то есть аналитик присутствуют. Ребята молодцы, но какова гримаса мира!

Андрей Иваровский. Рефакторинг — на позитиве

runteo.ru. Минск, Беларусь

Рассказ о том, как он последовательно инициировал рефакторинг для повышения технологичности поддержки автотестов и, как следствие — снижения стоимости. Критерий полезности: замещение ручного труда автотестами против поддержки автотестов. Полезно мониторить. И если несопоставимо — надо менять. Часто затраты на поддержание автотестов — неоправданно. Особенность — проект совместный с индусами, анализ и предложения по рефакторингу проводил он, а делали — они, и тут есть свои особенности :)

Виталий Петруняк. Команды из разных стран — секреты успешного тестирования и дипломатии

T-Systems CIS. Санкт-Петербург, Россия

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

Никита Гавриш. Внедрение автоматизации на Selenium в highload-проект

EPAM Systems. Санкт-Петербург, Россия

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

  • Симба и Нала. Кейс, когда вы ставите автотестирвоание в существующем проекте с историей. При этом там ожидают автотестов, отношение балгожелательное. Но тем не менее. И на начальном этапе вы по-сути внешний к команде проекта, пилите в одиночестве, и только через некоторое время станете своим.
  • Тимон и Пума. Кейс, когда команда даквно работает с автотестами. Тут надо поднять технические решения.
  • Проект Генри. Банзай, Шэнзи, Эд. Проект нестабильный и не знает с ним будет через месяц — и соответственно не планируют. Проект не знает, что делать с автотестами вообще. И при этом могут пробовать забивать микроскопом гвозди. И противоречивые требования. Терпеть были готовы только 5 минут.
  • Человек-невидимка. Фантастический проект по TDD — ни разу не участвовал. Но если то, о чем рассказывал Badoo-правда, то они близки. Так что тут у него знания теоретические.

Техническое решение: написать свой или взять готовые? Велосипед vs Freeware. Сравнение. Плюсы понятны, Минусы — тоже, готовый все равно надо допиливать, зато со своим можно промахнуться и написать дурацкую конструкцию, с которой мучаешься. Вывод разумный, но очевидный: писать свое стоит если у вас проект имеет какие-то понятные особенности, из-за которых стандартные не подойдут (включая метрики, или интеграция).

Они решили писать свое. Поверх готового — Python + Selenuim + SQLite + CouchDB + HTML/JS/CSS. CouchDB взяли чтобы хранить результаты тестов, включая логи и screenshot и представлять результаты текстов красиво. CouchDB оказалось неудачным решением, он бы взял Mongo. А SQLlite хранил всякие конфиги, потому что у них конфигурации были сложные и многовариантные — если этого нет. то можно без них.

Дмитрий Химион. Деградация автоматизаторов — «горе от ума»

Performance Lab. Москва, Россия

Рассказ был о конкретном кейсе тестирования. Завязкой был неуклонный рост времени прохождения тестов, который при апроксимации выводил общее время в недопустимую область. И как он с этим разбирался, выдвигая различные гипотезы и проверяя их наблюдением за различными метриками. Причина оказалась любопытной. У них был собственные библиотечки хелперов для тестирвоания GUI, и первоначально в тесте надо было определить 4 переменные, чтобы указать элемент экрана для тестирования. Пор мере совершенствования в него встраивали разные эвристики, чтобы не все переменные можно было не задавать. Они работали. Только в 10 раз дольше, чем при задании переменных — а дальше по мере увлечения доли тестов, где переменные были не заданы время медленно, но неуклонно росло…

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

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

Наталья Руколь. Аутсорсинг тестирования

Лаборатория качества. Москва, Россия

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

Строительство команд и личный рост

Вячеслав Лукьяненко. Командоварение: полевая кухня

Wargaming. Минск, Беларусь

Доклад о личном опыте создания команд. Разном, удачном и неудачном. С анализом причин неудач. Ситуация: самооценка начальника Ковбой, команда считает Диктатором и никто не подозревает, в чем дело. Варианты развития: может выдавить лидера или лидер команду. Оба проигрышные, но лучше когда команда выдавила — потому что тогда можно назначить другого, и команда останется. А если команду подавили, то фиг, они все — как дети за крысоловом.

Подходы рассказывал известные. Квадрат моделей лидерства Can/Want: Supporting, Directing, Coaching, Delegating. Кстати, Supporting тут по-видимому политкорректное и лишнее, я слышал ту же модель от Петелина и у него гораздо жестче — Controlling. Стадии команды — Forming Storming Norming Performing и роль лидера в них. Из любопытного: на storming. Лид должен гасить конфликты, и должен провоцировать, но на нерабочие темы — чтобы люди выяснили отношения. А в norming — традиции, стикеры на дверь. Только не придумывать самим — должны сами зародится.

Дальше будет меняться состав — будет Reforming, опять штормить.

Святослав Римар. 10 «тестхаков» для улучшения процесса тестирования

SoftServe. Львов, Украина

В докладе был набор разных практик самого разного характера: квантование времени Pomodoro, MindMap для любых списков, противодейстиве закону Паркинсона о том, что работа занимает все отведенное время, завоевание доверия клиента через индикатор прогресса — организацию ночных сборок с отгрузкой так, что клиент может пощупать, автоматизация повседневной работы, работа с мотивацией и геймификацией. В общем, много всего. И смысл доклада в том, что возьмите — и попробуйте применить, вам тоже может помочь.

Только вот, добавлю от себя, что может помочь, а может и навредить. Можно это проверять экспериментальным путем, а можно сначала подумать, покопать механизмы и границы применимости, подумать об эффекте в долгую. Потому что многие практики при неуместном применении, давая эффект в моменте, портят ситуацию в долгую, при чем неочевидным образом. Тот же pomodoro — он квантует время, не давая переключаться, требуя отдыха мозгов и вполне эффективен, когда задачи у вас ума требуют, а творчества — не очень, и делать их не особо хочется — ну как решение заданий в институте. Творческие задачи так решаются плохо. А еще — он закрывает путь к состоянию «работы в потоке» (это ввел Михай Чиксентмихайи, кому интересно можно посмотреть видео Алексея Пименова на AgileKitchen, или почитать мой отчет). И геймификацией, то есть игрофикацией тоже все не просто и не безопасно, можно посмотреть там же и в других докладах Максима Коробцева.

Андрей Ребров. Тестирование в Agile для больших команд: путь трансформации

ScrumTrek. Москва, Россия

Рассказ был про конкретный кейс в одной из компаний. И успешный: повысили скорость поставки фич в 5 раз, поставки стали регулярными 2-3 раза в неделю, ушли от работы по выходным и по ночам. Повысилась удовлетворенность работой. Как процесс — ставили Канбан — это самая простая методология, всего 4 правила, хотя самая сложная в поддержании. Самое распространенное — задачу пускают в работу партизанскими методами, в обход ограничений канбан-доски. А это — нарушение целей методологии.

Сделали сессия рассказа требований от аналитиков. «Зачем рассказывать, есть же документ. — Мы прочитать можем, мы понять не можем.». Использовали Спецификация на примерах — Goiko Adzic.

Начали думать о рисках. Пока в варианте выписать, оценить и принять превентивные меры. Как сказал Андрей «Если кто-то думает, что это работа тестлида или менеджера, то подумайте, делает он это :)». Уже от себя добавлю, что превентивные меры для рисков — хорошо, но часто дорого. Есть другой способ: придумываем метод раннего обнаружения и План-Б, который включается.

Начали использовать DevOps. Квадрат Culture (хотя бы общайтесь) — Automation (google в помощь, список велик) — Measurement (нужен не только инструмент, но и разумная система измерений) — Sharing (делиться знаниями). Про Sharing — почему-то в больших компаниях у админов своя закрытая вики, у тестировщиков — своя и каждый дрожит.

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

Дарья Костюк. Альпинизм в тестировании или восхождение на вершину карьеры

Softengi. Киев, Украина

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

Перед тем, как расти, стоит дать ответ на вопросы

  • Для чего нужен успех в карьере.
  • Как повлияет на мою жизнь карьерный рост и готов ли ты к этому.

Начинается все с желания. Потом — Идея. Затем — Намерение.

Успех — не дело случая, а дело выбора. Примите прямо сейчас и начните движение к цели. Сформулируйте цель. Назначьте дедлайн. Чтобы туда идти. Определите промежуточные цели. Составьте список препятствий. Восхождение — это приключение. Надо получить кайф. Но придерживаться маршрута и не сдаваться.

И 10 навыков и качеств

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

Навыки все правильные, включая видение картины.

Ну и ретро — в позитиве. Что сделано хорошо, что дало наилучший результат, что можно улучшить.

От себя я хочу отметить, что в личностном развитии есть две составляющих: видение картины и собственно движение. И вот способ движения, о котором говорит Дарья — сознательно и планомерно двигаться к цели. А есть другой способ — ловить возможности, он куда прикольнее — мир такие штуки подбрасывает! А если серьезно, идти планомерно — это Решающие (Judging), а ловить возможности — Воспринимающие (Perceiving). Это типы личности Майерс-Бриггс (не путать с соционикой), и по тестам человечество делится пополам.

Доклады-размышления

Николай Москаленко. User experience, как замена юзабилити

Аплана. Москва, Россия

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

Николай Юденко. 3 закона робототехники: или безопасность, функциональность и защищенность ПО

Независимый эксперт. Днепропетровск, Украина

Security testing. Безопасность и защищенность — суть разные вещи. И спроецировал на законы робототехники, потому что это актуальная для него конструкция. Из двух компаний он уходил, когда ПО становилось небезопасным, а он не мог повлиять.

Законы.

  • Робот не может причинить вред или бездействием допустить вред — Безопасность
  • Робот должен повиноваться, пока не противоречит первому — Функциональность
  • Робот должен беспокоиться о личной безопасности — в мере, не противоречащем первым двум — Защищенность.

Собственно, известно много кейсов, когда из-за багов в ПО первый закон нарушался и тем или иным образом причинялся вред. А баги связаны с ненадлежащим тестированием, вызванным разными причинами… И некоторые кейсы Николай рассказывал.


[ Хронологический вид ]Комментарии

Сохраняю для себя.

— Максим Цепков • 24 апреля 2016 в 10:53 последняя правка 24 апреля 2016 в 10:59

А это - ссылка на пост Макса Богуславского с впечатлениями о конференции, FB принес в ленте воспоминаний.

— Максим Цепков • 10 ноября 2020 в 11:50

Войдите, чтобы комментировать.

— Максим Цепков • 00:13, 11 ноября 2013 • 2 комментария
Источник — «https://mtsepkov.org/index.php?title=Блог:Максима_Цепкова/2013-11-10:_SQAdays_-_потрясающая_энергетика&oldid=2981»