Просмотр исходного текста страницы Блог:Максима Цепкова/2013-11-10: SQAdays - потрясающая энергетика

{{Conf-Ref}}
Закончилась [https://sqadays.com/ru/program/8058 SQAdays-14] во Львове. Все-таки, эта серия конференций обладает потрясающей энергетикой. Наверное потому, что у тестировщиков наиболее ярко проявляется идея предназначения «Мы делаем мир лучше, повышая качество программных продуктов и, как следствие, радость людей от жизни в этом мире». При этом они наименее интровертны среди ИТ-шников.

[[Файл:SQAdays-14-открытие.jpg|right|thumb|400px]]
Конференция собрала много участников и проходила на стадионе, так что можно с полным основанием говорить, что конференция тестировщиков собирает стадионы :) И, кстати, Львов — прекрасный город, который я хотел посмотреть и потому приехал сильно рано. Впечатления и фотки — [http://maksiq.livejournal.com/tag/Львов у меня в ЖЖ].

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

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

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

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

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

Сам я, кстати, во второй день совершенно неожиданно тоже оказался в роли докладчика — один из докладчиков почему-то не явился на собственный доклад и организаторы были вынуждены искать замену с колес. Поэтому я рассказывал свой прошлогодний [[Роли в команде - модель Белбина (Максим Цепков на SPMconf-2012)|доклад на SPMconf про модель командных ролей Белбина]]. По отзывам — получилось очень удачно и уместно, несмотря на то, что у меня не было времени даже просмотреть слайды.

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

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

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

Было несколько докладов про совмещение ролей аналитика и тестировщика. Интересно, что несколько лет назад я делал [[Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQADays-2011)|доклад на SQAdays]] об этом. Тогда перед конференцией статью с тезисами доклада опубликовали [http://software-testing.ru/forum/index.php?//topic/21066/ на форуме software-testing] и в дискуссии оппоненты говорили, что совмещение не получится, потому что тестировщик нацелен на разрушение, а аналитик — на созидание. Что мне это было странно, потому как у нас в компании такое совмещение есть с самого начала. С тех пор веяния изменились, и теперь совмещение никого не удивляет, а воспринимается конструктивно и правильно, доклад вызвал интерес у участников.

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

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

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

А теперь — обзор докладов по темам, внутри доклады упорядочены по месту в программе. Впечатления от английского дня [[Блог:Максима Цепкова/2013-11-07: SQAdays - английский день|'''в предыдущем посте''']].

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

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

== Алексей Лупан, Олег Колька. 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 — он квантует время, не давая переключаться, требуя отдыха мозгов и вполне эффективен, когда задачи у вас ума требуют, а творчества — не очень, и делать их не особо хочется — ну как решение заданий в институте. Творческие задачи так решаются плохо. А еще — он закрывает путь к состоянию «работы в потоке» (это ввел Михай Чиксентмихайи, кому интересно можно посмотреть видео Алексея Пименова на [https://www.evernote.com/shard/s9/sh/497612c3-ad1d-4dd9-8502-9c203f9f691f/47ce75f2cdd5143da419f50c1d64f0b9 AgileKitchen], или почитать [[Блог:Максима Цепкова/2013-10-12: Впечатления с AgileKitchen|мой отчет]]). И геймификацией, то есть игрофикацией тоже все не просто и не безопасно, можно посмотреть там же и в других докладах Максима Коробцева.

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

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

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

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

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

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

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

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

Перед тем, как расти, стоит дать ответ на вопросы
* Для чего нужен успех в карьере.
* Как повлияет на мою жизнь карьерный рост и готов ли ты к этому.
Начинается все с желания. Потом — Идея. Затем — Намерение.

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

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

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

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

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

== Николай Москаленко. User experience, как замена юзабилити ==
Аплана. Москва, Россия

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

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

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

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

{{wl-publish: 2013-11-11 01:13:17 +0400 | MaksTsepkov }}