Изменения

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

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

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

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

Сам я, кстати, во второй день совершенно неожиданно тоже оказался в роли докладчика — докладчика — один из докладчиков почему-то не явился на собственный доклад и организаторы были вынуждены искать замену с колес. Поэтому я рассказывал свой прошлогодний [http://spmconf.ru/talk.sdf/spmconf/spmconf2/talks/7381 [Роли в команде - модель Белбина (Максим Цепков на 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] и в дискуссии оппоненты говорили, что совмещение не получится, потому что тестировщик нацелен на разрушение, а аналитик — аналитик — на созидание. Что мне это было странно, потому как у нас в компании такое совмещение есть с самого начала. С тех пор веяния изменились, и теперь совмещение никого не удивляет, а воспринимается конструктивно и правильно, доклад вызвал интерес у участников.

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

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

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

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

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

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

* Рассылка SMS. GoogleDocs — GoogleDocs — замечательно посылает бесплатные SMS. Тесты свалились — свалились — CI ставит event в google docs календарей пользователя (он туда лезет, безопасность не появляется) — — они получают сообщения, потому что у них настроено.

Wireshark и др. Тестировщики — Тестировщики — не забывают смотреть, как идет логин и пароль реально.* Запись клавиш и мышек. AutoIt, Automator, UOPilot. UOPilot — UOPilot — была игра, там надо было прокачиваться. И фанаты написали штуку, которая цеплялась к окошку и делала что скажешь на простом скрипте. А теперь замечательно это делать не только для игры :)

* TeamViewer, VNC. Teamviewer — Teamviewer — не надо устанавливать, можно просто запустить. И это плюс для многих, где следят за установкой ПО.* Средства общения — общения — Skype, Jabber, Teamspeak — Teamspeak — комнаты с голосовым общением, Raid call — call — аналогично teamspeak, но с няшным интерфейсом, Google talk / Hangout.

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

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

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

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

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

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

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

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

* Разработка информационной системы — системы — архитектора, юзабилити

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

* Смешение ролей. Особенно при общении с заказчиком — заказчиком — важно позиционирование. Иначе не получается ни то ни другое, все в куче. Надо в голове — голове — разделять.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Направление — Направление — на перспективу. Дальновидность.

* На решение проблемных ситуаций — ситуаций — решаем, а не анализируем причины.

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

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

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

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

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