Короткая ссылка: SQAdays-2013a

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

С каждым разом на конференции все больше народа. Эта конференция проходила в Park Inn Прибалтийская и собрала больше 600 человек. Реально гигантские залы, и полные. С задних мест докладчик - где-то вдали, на горизонте, особенно в большом зале - поэтому стоят плазмы, идет трансляция и экрана и докладчика. Думаю, следующая конференция будет еще более многолюдная. Она состоится во Львове, будет 3 дня вместо обычных двух и там будет день западных спикеров.

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

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

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

Что я вынес с конференции

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

Новые тренды

DevOps, здесь про него рассказывал MS. Кстати, InfoQ оказывается, включил его в голосовалку IT-трендов 2013. А мы и не подозревали, что это - важная проблема, потому как в нашей компании она отсутствует, то есть решена на уровне dissolution.
Явным трендом конференции были рассказы по подготовке тестовых наборов данных, с практиками классов эквивалентности, pairwise и кластеризации. Кто-то просто порождает такие наборы, кто-то просто контролирует репрезентативность. Все это говорит о том, что этап автоматизированного тестирования взял очередную планку зрелости: задачи создания и исполнения тестов воспринимаются как технические (хотя инструменты важны), а вот быть уверенными, что наборы данных покроют возможные ситуации и выловят баги, которые возникают на сочетаниях значений, а не на одном - важно. И сообщество практически осваивает наработанные теоретиками методы решения, превращая их в простые и доступные практикам конструкции.
Интересно, что доклады про JIRA вызывают раздражение. По-видимому она явно лидирует в популярности из-за доступности начального старта. И восторг новичков по этому поводу вызывает раздражение более опытных людей, которые видят в ней инструмент, один из подобных, с плюсами и минусами. Это можно сравнить со скепсисом по отношению к SCRUM у профессионалов в противовес восторгам недавно освоивших адептов. А еще в JIRA есть ловушка кастомизации: широкие возможности настройки при неуемном использовании имеют тенденцию к превращению продукта в неоправданно навороченную конструкцию. Правильная борьба с этим - в головах, надо разумно подходить к кастомизации, ограничивая фантазию. Но это понимают не все, и часто реакция "гадость ваша Jira", особенно от тех, кто получил этого навороченного монстра в готовом виде как исполнитель.
Еще по нескольким конференциям отмечу, что IT-сообщество успешно осваивает теорию ограничений Голдратта применительно к разным аспектам IT-производства. Тут надо сказать, что прямое применение практик менеджмента, разработанного в других отраслях, в IT - невозможно. IT-производство отличается и от промышленного производства и от конструирования в других отраслях. От первого - тем, что это работа умственного труда. От второго - малой ценой воплощения в железе, которая в IT означает просто build, с точки зрения других отраслей IT-разработка - это этап проектирования. Так что IT-менеджмент - это отдельная ветвь менеджмента, и методики могут ассимилироваться только через подъем до уровня идей и подходов, а затем - применения их с учетом специфики IT. При этом они часто изменяются очень сильно.

Еще я отметил для себя несколько интересных тем.

Было несколько докладов про behavior testing, в основном на основе Jbehave. Особенно интересен рассказ разработчиков из Deutsche Bank, они это использовали при тестировании рисков и прошли путь от "это не работает, на наших проектах - точно не работает" до пилотного проекта, когда аналитикам получается писать такие тесты, это уже не код.
А еще у меня возникли интересные ассоциации между моделью behavior testing с выделением ключевых слов и реализацией на них тест кейсов на почти естественном языке с применяемой нами при проектировании модели DDD с технологическими рельсами. Я еще подумаю об этом.
Jibula - новая тыкалка для Java-Swing(+SWT) тестирования. В России пока не очень распространена, проект новый и интенсивно развивается.
В докладе Сергея Никонюка был интересный sample DSL-языка на Groovy. Мне тут интереснее практический пример.
Непрерывная интеграция Badoo. Выпуск фич по готовности с включением. Параллельная работа тестов на одном домене - для ускорения. Да, они могут случайно упасть, и падает до 50% запусков (1-2 теста), если после перезапуска работает - не страшно. Я эту мысль слышал, это к вопросы о необходимости максимальной изоляции, из-за которой такое тестирование, мол, невозможно. Для меня это информация о том, что так построить процесс - релизы дважды в день, но при этом полный цикл тестирования - тоже можно, при этом достаточно подробно описано - как именно. И это расширяет спектр рассматриваемых вариантов при организации проектов.
Доклад Рины Ужевко про тестирование пользователями. В нашей enterprise-разработке по определенным видам функционала довольно часто окончательное тестирование осуществляется пользователями, при чем даже не на тестовом сервере, а на боевом - этому есть объяснения, так правильно. По факт процесс имеется, но он явно не выделен, как отдельный, а, наверное, стоит, в том числе для того, чтобы обеспечить передачу опыта между командами.

О докладах конференции

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

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

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

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

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

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

Если классифицировать доклады конференции, то можно выделить следующие категории.

Практика, личный опыт по решению проблемы от новичка. Например, time management или непрерывная интеграция. При этом автор сам решил стоящие перед ним задачи. Другими эти задачи уже решались, он об этом не слишком знает, и, собственно, это - основной недостаток доклада, если бы знал - позиционировал свою задачу относительно подобных. При этом, правда есть опасность увидеть отсутствие предмета доклада...
Практика, личный опыт по решению проблемы от профессионала. Отличается от предыдущего как раз тем, что знает, чем его проблема отличается от других, позиционирует это в докладе. И среди этих докладов много тех, в которых идет рассказ о действительно сложных проблемах, на переднем крае опыта.
Новая методология от новичка. Обычно связана с прочитанной книгой, которой он вдохновился и только-только начал или даже собирается применять. К сожалению, хорошего изложения тут часто не получается в силу недостатка опыта в отрасли, а также опыта докладов. Основная ошибка докладчика в следующем: он думает, что если он это расскажет - все заинтересуются и проникнутся. Так рассказать - не получается, плюс в аудитории, что интересно, находится прилично людей, которые с методикой знакомы и поняли ее на более высоком уровне, и у них - отрицательное мнение о докладе. Хороший же доклад получается, если автор уже пропустил методику через личный опыт, пусть не очень много, и рассказывает именно об этом, проецируя общую методику, часто не связанную с тестированием, например, личностного роста или эффективного управления, на деятельность тестировщика. Но для этого нужно, во-первых, тот самый личный опыт использования, а, во-вторых, хорошая рефлексия по этому опыту, что реально непросто.
Новая методология от профессионала. Отличается от предыдущего тем, что автор как-раз осознает перспективность методики и ее место в отрасли. А еще - понимает, что значимые результаты на собственном опыте он получит через значительный промежуток времени, поэтому сейчас он не может ничего особого рассказать. Но хочет поделиться, чтобы другие тоже могли поиспользовать заложенный потенциал. В результате доклад получается довольно эклектичный, но другого в этих условиях - быть не может, а раз так - лучше такой, чем никакой.
Методология от профессионалов. Это как раз ниша образования. Понятно, что за 40 минут много не расскажешь, поэтому профессионал берет некоторую тему, и структурирует информацию по ней, рассказывает главное и дает ссылки, по которым те, кого тема затронула могут глубже это узнать. При этом сама тема знакома автору не только теоретически, но и практически. И это - наиболее ценные доклады. И, хотя с моей точки зрения им не всегда хватает экспрессивности изложения, я понимаю, что для восприятия другими спокойное изложение может быть наоборот преимуществом. Кстати, отмечу, что изложение методологии может идти из двух позиций: "Что " - с цельной задачей, проблемой, и обычно общими рекомендациями, и "Как" - с конкретным решением, иногда - касающимися нескольких проблем. Они очень редко бывают в одном докладе, и даже книге, причина в том, что конкретные решения, как правило, решают частные варианты задач, и потому авторы "Что" считают, что частным решениям тут не место, а авторы "Как" - что теоретические рассуждения перегрузят описание практики, и желающие теорию легко смогут найти. Поэтому между "Что" и "Как" образуется лакуна.

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

Особенно понравившиеся доклады

Сергей Атрощенков VIAcode. Гендерные аспекты постановки задач

Методология от профессионалов. Блиц.

Гендер - социальный пол, определяющий поведение человека в обществе и его восприятие. Личность: воспитание, мотивы, опыт, знание, опыт, тип личности.

Мужская (мускулинная) культура. Престижная должнось, высокий статус, притупленность в чувствах, видение в крупном, соревновательный момент...
Женская (феминная). Выжен личный рост и совершенствование, открытые отношения внутри, внимание к деталям, отсутствие соревновательности...

Культура - напрямую не связана с полом.

Есть методология SMART постановки задач - Specific Measurable Achivable Relevant Time-bound. Так вот, если ей формально следовать, то представление задачи получаются неадекватным гендерной составляющей. И это надо учитывать, добавляя релевантные вызовы. Были формулировки по конкретным принципам, по specific - был пример, а по остальным - автор ждет примеров от слушателей, лучшие будут премированы.

Андрей Мясников Undev. Работаем с огоньком!

Наиболее понравившийся мне доклад. Блиц. О правильном отношении к работе, можно сказать, что методология от профессионала для этой области, очень зажигательно изложенная.

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

Результат - памятка. Правда весьма сумбурная.

Типы задач: одноразовые, регулярные, внезапные, волшебные (это которые любимые). Некоторые люди замечательно делают именно внезапные задачи, выдают результаты. Определитесь с типом задач, которые вам нравятся, скажите. Не обязательно, чтобы были только такие, но такие - должны быть.
Добавьте элемент игры. Сам себе.
Личным проблемам на рабочем месте - не место. Каждый день у вас есть 8 часов для этого - и пользуйтесь :) Работа как отдых от личных проблем, драйв!

Пустой слайд в середине презентации. Буддизм. Там - все. А смысл "не бывает работы мечты". Но есть хинт - можно ее такой назначить.

Профилактика

Выгулять лень. Останьтесь дома и НИЧЕГО не делайте.
Общее хобби с коллегами.
Раскрутите начальство на поезку на SQdays

Из вопросов

Где взять внезапных задач? - Придумайте!
Как назначить работу любимой? - Берешь и назначаешь!

Юлия Саенко Alcatel-Lucent. Применение MBT для генерации тестовых сценариев для ручного и автоматического тестирования

Практика от профессионала. Model Based Testing. На основе модели системы. Для разработчиков модель архитектурная, для тестировщиков - поведенческая. Рассказ про систему MaTeLo - в которой ты описываешь поведение пользователя через состояния, задаешь наборы значений для полей, а дальше она осуществляет генерацию реальных тестов так, чтобы пройти состояния. Инструмент очень простой, и это - преимущество. Он платный, есть аналогичные бесплатные инструменты - GraphWalker, SpecExplorer, но их не смотрели, потому что в головной французской компании MaTeLo куплен и используется, и они ставили у себя. Еще есть Conformiq, но он - на основе поведения системы, а не поведения пользователя, больше подходит для разработчиков, и гораздо более сложный в освоении, разработчики предлагают 2-3 месяца пилотный проект с их поддержкой.

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

MaTeLo тесты порождает, для их исполнения нужен фреймворк, скриптовые конструкции, у них используется TestComplete, плюс собственные парсеры XML. Тесты конструируются и запускаются в MaTeLo вручную, а готовые - подключаются через Jenkins к Continious Integration.

Тестируют бизнес-skype. Работают и распределенные тесты, многопользовательские звонок-ответ. Еще у них рисование на whiteboard a-la презентации, и тоже в интерактивном многопользовательском режиме. Так что приложение непростое.

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

Рина Ужевко. Королевство. Тестируем с пользователями. Школа результативного выживания

Тестируют игры и сайты к игре. Идет тестирование с пользователями, по сути в команде тестировщик - она одна, а остальное тестирование выполняют пользователи, ей набранные и организованные. И Рина рассказывал об этом опыте: как отбирать людей, как ставить задачи, как обеспечить достаточное тестирование при такой слабо управляемой и контролируемой добровольной команде. У нее - получается, и она делилась каким образом.

Подход, с ее точки зрения, применим не только в играх, но и в других областях. Кстати, в конце с места был вопрос - а к билинговым приложением, с объяснением сразу почему точно нельзя - а у докладчицы есть опыт, что можно, работает.

Где набирать - техподдержка, суппорт, форумы. Как отбирать? Она: адекватность, лояльность к администрации, общительность и ответственность. В команде - около 40 пользователей. При этом отбирала тщательно, но кто отобрался - почти не отбракован (двоих).
Мотивация: скидки, преимущества, "ничем". Ничем - тоже работает, им интересно поучаствовать.
Где? Допуск на предпродакшн. Отдельный логин, не совпадающий к продакшн. Контролировать доступ к консоли.
Тест кейсы - просто, прозрачно. Не "провести регрессионное тестирование", а "вот это протестировать еще разик". Тест на нагрузочное тестирование "заходим и ломаем".
Обязательно - куда баги. Это сложнее, чем тест-кейсы. Skype - можно, но флудят. email - неудобно. Какой-то ворд писать, посылать :( Google-docs - удобнее всего.
Две группы по опыту. Сначала сама самое сложное, потом опытные - остальные сценарии, потом - неопытные.
После допуска пользователей - ускорились в неколько раз, при этом полное тестирование версии.
Главное: пользователю либо хорошо, либо никак, они не могут делать плохо. Отвечайте на все вопросы. Давайте выбор, при этом будьте своим админом, держите рамку. Информируйте о фиксах багов и приеме улучшений.
Объясняет как писать баги, чтобы не было "не работает". Всего 5 минут.

Даниил Подойницын AT Consulting. Автоматизация тестирования Java GUI приложений при помощи Jubula

Гайд по инструменту, но с приемчиками и особенностями. Jubula - умная тыкалка, инструмент новый, в России пока малоизвестный - поэтому гайд уместен. Инструмент бурлит и быстро развивается, среднее время ответа разработчиков - несколько часов. Так что его стоит рассмотреть, ставя процесс тестированяи в новом проекте.

Примеры приемов.

Адресация элементов на path, а именами, к которым пути привязываются однократно - и меняются однократно. И называть можно по-русски, не извращаясь с переводами.
Есть собственная БД, но падучая, когда много пользователей. Тогда нужен Oracle.
В инструменте сознательно запрещено копирование "интуитивным" способом. Борьба с clipboard. В рефакторинге можно поименовать кусок, выделив в функцию. Есть "Save as New" - это-таки копия. Они злоупотребляли, расхлебывают.

В целом отличная тыкалка из коробки для Swing. Нельзя выстрелить себе в ногу. Интегрирована. Еще и бесплатная. Через командную строку - можно подключить что надо, например, sikuli - у них мостр на OracleForm6, а также - взаимодействуют через API, где надо, а не через UI. Но есть недостатки. UI для начала рвет мозг, первичное привыкание 2 месяца, новые втягиваются пару недель, и - да, втягиваешься. А еще - нет кода, простыней - нет, и к этом надо приспособиться, в том числе психологически. Можно интегрировать непрограммистов, а вот в резюме непонтово.

Сергей Никонюк Avast Software. Использование Open Source инструментов для автоматизации тестирования

Пример реального фреймворка, который они собрали для своих задач тестирования установки новой версии Avast. Проверить надо не только, что она поставилась, но и что вирусы после этого по-прежнему ловятся. Состав фреймворка - Jenkins, Sikuli, RobotFramework, Staf (соединение с удаленными машинами). И был комплексный пример, правда не полной установки - она долго идет.

При рассказе о фреймворке - показано выделение типовых конструкций, из которых строятся тесты - runApp, waitImage, minimizeAllWin...

Андрей Пахомов, Сергей Аксененко EMC. Интеллектуальная система автоматизации тестирования на базе Groovy

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

Задачи тестирования включают эмуляцию реальных сбоев оборудования в распределенной системе с нодами, хабами и прочим. Типа, переключится ли реально на тестовый сервер. Все серьезно. Почему свой язык? Потому что не нашли решения. Задачи: (1) разделение логики сценариев и конфигурации их запуска и (2) создание и изменение сценариев силами QA.

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

DSL на Groovy - способ обеспечить создание и изменение сценариев QA. Почему Groovy? Интерпретатор, интеграция с Java, Сценарии отдельно от проекта, Перегрузка основных элементов языка - чтобы навешивать на эти конструкции, Лаконичность относительно Java, поддержка IDE.

Как создавать DSL

Наследник BaseScript - базовые операторы вне контекста
Объектная модель.

Важно: в момент загрузки скрипта - ничего не делаем, только собираем данные, строим объектную модель и проверяем ее безошибочность тестового сценария. А только потом - выполнение. У них тестовые сценарии могут бегать несколько часов, поэтому проверка до запуска - важна.

DSL для сценариев выступает еще как средство интеграции знаний.

Концепция фильтров. Они не привязываются к объектам тестовой среды, они лишь говорят про свойства объектов. Например, для тестирования отключения портов не указывают конкретный порт, а признаки, отбирающие кандидаты на отключение. Для фильтров Переопределили операторы надо множествами: + объединение, * пересечений, - отрицание.

Проверки. У них система реагирует с задержкой (всякие мониторинги). Темпоральный оператор, Время, Квантор, Фильтр, Событие/состояние. И дальше примерчики - вполне понятные и симпатичные.

expected events in 1.min { every Host.PRODUCTION => Event.10203 }

Илья Кудинов Badoo. Организация автоматического тестирования в схеме непрерывной интеграции

Практика от профессионалов.

Социальная сеть. 180М пользователей. 2 релиза в день, кроме пятниц, там - один. Около 40 задач в день, 25 утром - 15 вечером. 70 разработчиков, 18 тестировщиков. Для меня в этом докладе было ценным описание возможности такой работы - частые релизы с сохранением полного цикла. В деталях, так что понятно какие нужны процессы и сколько это стоит. По сути это расширяет поле возможных решений.

Фазы тестирования. На каждой - свой фокус проверок.

Code review.
Автотестирование по commit
Тестировщик в девелоперском окружении
Тестирование в шоте: продакшн+эта задача
Autоmerge в предпродакшн и автотестирование на нем
Тестирование на препродакшн
Тестирование на продакшн

Git + TeamCity + Jira. Тесты phpunit + selenium для интерфейсов.

Ветки-коммиты по задаче, можно посмотреть разницу. Порядка 40 коммит-хуков Git. Коменты, синтаксис, права. Gitphp - можно писать комменты к строкам изменений - в codereview используем это. Интерфейс сильно допилен. По коммиту - идет автотестирование ветки teamcity. Около 17К тестов, однопоточные - 40 минут. Поэтому у них многопоточная пускалка, 3-4 минуты. Пускалка опирается на статистику времени тестов по предыдущим запускам, балансируя нагрузку. 4-5 тестов долбят один домен.

На продакшн - 2 платформы, Европа и Америка, со сложными отношениями. В разработческом окружении - тоже. В девелоперском окружении код сервера (php) у каждого свой, а база данных для этого - общая.

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

Aida automated Interactive Deploy Assistant. Merge завершенных шотов выполняется автоматически. При проблемах - автоматические уведомления разработчикам всеми средствами: Jira+Jabber... После каждого мержа препродакшн - запуск тестов. Сначала - smoke-тесты, которые проверяют основную работоспособность. Если не проходит - проблемные задачи откатываются. А дальше - запуск автотестов. Если автотесты не проходят, то два варианты: откатываем фичу или разработчик быстро пишет патч, об этом видно. Когда автотесты проходят, тестировщик тестирует на предпродакшн. Мерж новых задач в релиз прекращается за 2 часа до самого релиза, это на финальное тестирование. AIDA - их собственная разработка, о ней была статья на хабре.

Выкладка релиза. После этого некоторое время идет мониторинг логов на продакшн, связанных с новой версией. И они за этим делам следят. До 70% задач попадает на продакшн в день завершения. На продакшн тоже можно делать патчи. Откат релиза сложен, обычно патчат.

Бывает релиз отменяют. Но гораздо проще откатить (выключить) задачу, отменяют релиз редко. Если задача очень сложная, и трудно проверить всю до предпродакшн, то под нее, бывает, создается отдельный релиз.

С тестами. Бывают, что падают случайно, можно перезапустить билд (вручную). Тесты 30-40 прогонов в день и примерно в половине прогонов хоть один тест - упадет. 4-5 тестов долбят один домен. Автоматического нагрузочного тестирования нет, разрабатывают. Отдел мониторинга следит за боевыми серверами.

Фичи делят на очень мелкие задачи. При этом задачи - с обратной совместимостью, выкладываются по мере готовности, и отдельная задача - включить фичу. Тестирование одной фичи может занимать даже несколько дней (долго). Это стараются в разработческом окружении и в шоте. При этом получается, что все задачи сложной фичи сначала уже прошли на продакшн, ничего не сломали, и пришло сразу.

Алексей Иешин, Сергей Черепнев Deutsche Bank. Specification by Example: Investment banking way

Рассказ разработчиков из Deutsche Bank как они использовали спецификации тестов для тестирования приложения работы с рисками рисков и прошли путь от "это не работает, на наших проектах - точно не работает" до пилотного проекта, когда аналитикам получается писать тесты в Gherkin-нотации, это уже не код. Интересно это тем, что подобные приложения традиционно имеют достаточно большую часть алгоритмических, вычислительных постановок и, потому подход к тестированию через поведение кажется не очень уместным.

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

Стадии и способ прохождения.

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

Принцип: делаем максимально просто, до того как начнет мешать, тогда - усложняем.

Jbehave. 1 человек. Far + тесты в текстовом редакторе + maven-запуск. Только - не демонстративно. И с ошибками хреново.
BDD plugin opensource с автокомплитом для Eclipse и IDEA.
Шаг 2. Но - сложно искать и брать себе тестовые данные. Они дописали фреймворк, чтобы данные получались и можно было откатывать.
Шаг 3. Передача знаний + Запускать параллельно. Фреймворк - да, умел, но массовый расчет рисков - он не может многопоточно это делать.
Два артефакта. Черепашка - хранитель знаний о фреймворке, передается новому человеку. И шарик - передача права запуска тестов. Но с ростом команды - сложно становилось отобрать шарик :) Каждый считает свои тесты важным. А еще: подготовка тестов около 15 минут, при том что сам тест около 1 минуты.
Сделать каждому тестовую среду - не выход, кеши и базы данных, много. Каждому непересекающиеся тестовые данные - тяжело, потому что сложно найти массивы репрезентативных данных. Они пришли к тому, чтобы сделать генерацию тестовых данных по предварительно настроенным установкам, при этом уникальные наборы - получались.
Есть схема с архитектурой. Есть ручной запуск для отладки тестов и ручных проверок, и те же тесты запускаются автоматом jenkins, continious integration. И есть мультик, как создается. Потому что нельзя вживую банковскую среду показать нельзя.
Шаг 5. Волшебной страницы не получилось - тест это код, а не спецификация. Mortage driven development. В новом проекте - делают с keyword учетом этого. Это уже конструирование конкретных тестов. И сейчас спеки в целом от аналитиков... (FA)

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

Связка с кодом - через аннотации, и надо использовать те, которые дает JBehave.

По покрытию. У них автотесты сопоставлены с ручными тестами, и люди, занимающиеся ручным тестированием - понимают, что покрыто автоматом.

Наталья Руколь Лаборатория качества. Тестирование юзабилити

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

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

Закон GOMS. Сколько кликов.
Закон Фиттса. Время пропорционально дистанции и обратно пропорционально размеру (только логарифм).
Есть сравнение мак-винда. Юзабилити.
Чем меньше элементов - тем удобнее выбор. 5-7 элементов. Закон Хика.

Нечисловые подходы. Числами - не ограничивается, и тут сложность. "Мне неудобно" - "А мне удобно, извини". Нечисловые методы - тоже стоит оцифровывать. Например, простая анкета: оцените блоки Удобство/Понятность/Сколько вопросов. Интересно, что бывает Удобно, Понятно, но вопросов много.

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

Гайдлайны и checklist - следование им повышает юзабилити, потому как пользователи привыкли.

О важном и неважном. Формула. %пользователей*коэффициент важности * заметность.

важность 1 - user, 2 эксперты, 5 - принимающие решение о покупке лица
заметность 1-3-5 (вау)

Числовые методы - интересно и продуктивно! Изучайте! Математика + психология - это вау.

А в аудитории сразу тупые возражения "нам кажется формулы неверны".

Просто хорошие доклады

Александра Чичелева Performance Lab. Тестирование систем с большим количеством входных данных или как достичь цели и не сойти с ума

Трендовая тема - про подготовку наборов данных. Блиц - реально переполненный зал, 30 чел стоит и стоячие места заканчиваются.

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

Дмитрий Романов Itera Consulting. Как приготовить тестовые данные для Big Data проекта. Пример из практики

Трендовая тема - про подготовку наборов данных. Тестовые самплы для BI-проектов. Берем реальные данные, каждое значение статистически делим по сегментам (максимальное, минимальное, среднее - сегменты, например, 16 штук). Заменяем значение категорией, потом статистический анализ, кластеризация кортежей. Дальше по статистики - распределение в sample, и случайная выборка реальных примеров. 11М в 83К. К сожалению, уровень абстракции изложения не очень помогает применить к своей практике.

Алексей Баранцев Software-Testing.RU. Браузеры в облаках

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

Я на всем докладе не был, но немного записей все равно опубликую.

BrowserShots - самый первый сервис. Потом Adobe свой сервис запустило, потом прикрыли - денег заработать не получилось. Интересно, что BrowserShots - облачный сервис не провайдера, а энтузиастов, которые предоставили свои компы с установленными броузерами в фоновом режиме.

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

TestingBot. У них победнее конфигурации, зато там реальное железо. С него снимается экран.
Nerrvana - тесты на скриптах. Можно даже как непрерывную интеграцию, но не слишком удобно. Лучше просто пробегать по расписанию, например , по вашему сайту. Почему не по урлам? Потому что может быть нужен сценарий.
modern.ie Проверить что приложение совместимо с новыми версиями IE.
webpagetest.org. Тайминг открытия страницы.
Эмуляции нагрузке. Простые сервисы - просто урлы. А если ajax и прочее - нужен сценарий. BlazeMeter.

Алиса Халиуллина Fujitsu. Тестирование патчей: необходимость или излишняя осторожность?

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

Патчи - это которые на основное ПО, на котором стоит твой продукт. Oracle, Java, Office, PDF. При этом известно, что многие патчи крешат отдельные системы. Непредсказуемо. Типа патч безопасности MS отваливает шрифты после 15 пойнтов в Corel. Или патч Java отваливает Eclipse. Она - в подразделении, которое тестирует обновления от MS перед их установкой пользователями.

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

Евгений Чигиринский Microsoft. Методология и практический опыт тестирования быстродействия приложений, сервисов и сайтов с высокой нагрузкой с помощью Visual Studio 2012

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

Татьяна Табакова Usability Lab. Обзор методов юзабилити-тестирования

Заглянул в середине. Тут все круто и по-взрослому. Лаборатория, "испытуемый" - тот кто проходит сценарий, от него трансляция экрана + 4 web-камеры + eye-трекер. Девушка-инструктор за непрозрачным для него стеклом (она его видит, он нет), связь по микрофону...

Интересно, что на SoftwarePeople от той же UsabilityLab был совсем другой доклад про тестирование мобилок - сначала по бумажным макетам, а потом - первого попавшегося в кафешке за чашку кофе или бесплатно.

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

Понятно, что при тестировании под наблюдением эффект больше, зато тут статистика рулит.

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

Вопросы - потом, иначе неверный тайминг.

Мы оцениваем не iq Васи, а ошибки и неудобства системы.

10 вопросов для выяснения оценки системы - Был слайд.

Никита Налютин. Математика для тестировщиков

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

Вчера увидел в недостатках "нужно аналитическое мышление" - его поразило.

Ломоносов "При помощи математики и доброго слова писать тексты значительно лучше, чем при помощи только доброго слова".

Математику ненавидят. Конкурирует со звездными войнами :)

Причины в тестировании - антипатерны

Математика в тестировании - это доказательство правильности
Математика работает только при подробных спецификациях
Математика - это что-то сложное

И, собственно, эти антипатерны он развеивал конкретными примерами и областями применения математики. Для начала - про то, что это сложно и не нужно.

Кнут. Математическое мышление, в противоположность алгоритмическому. Отражение действительности, сведение к простому случаю, обобщение, абстрактные рассуждения. Каплунович, уровни мышления, от Топологического. Говорит, мапиться на уровни CMMI. Обменяю лень на мозг.

Из практических примеров - алгоритм ДеБройна для выбора набора тестов по переходу графа состояний. Про классы эквивалентности для сокращения числа тестов. Про статистический метод сэмплов.

Правда, по-моему слишком неторопливо и академично. Александра Чичелева из Performance Lab о наборе данных блиц делала, гораздо живее. Другое дело, что такой рассказ, быть может, больше народу восприняли. Но я ушел на другие доклады, послушал неплохо Анастасию Романову из Parallels, зато пропустил какую-то мысль про Шелдона Купера.

Марина Широчкина Yandex. Тестирование производительности клиентсайда

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

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

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

Что делать.

Разработка - best practice, отладка. Guideline. Только делать скидку на устаревание - основные книги появились 7 лет назад, и не обновлялись, хотя сам инет ушел вперед. Есть блоги.
Мониторинг

Дмитрий Химион Performance Lab. Автоматизация тестирования ПО на редких платформах

Практика от профессионала. Забежал на перерыве. Забавно, в редкие платформы сейчас попали text-based интерфейсы - те, с которых все когда-то начиналось. Там окно без элементов, просто разноцветный текст с псевдографикой. И они распознают в них элементы диалога. Вопрос из зала - а что не использовали регулярные выражения? Ответ - пробовали, тогда будут 2 проблемы вместо одной.

Остальные доклады

Евгений Ткаченко Innova Systems. Нет бага - нет проблем?!

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

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

Алексей Кривицкий SCRUMguides. Перестаньте спрашивать «КОГДА?» Или как перестать закапывать свои проекты в долговые ямы?

Началось все с оптические иллюзий и других подобных вещей. Потом был переход к книге "Думаем быстро и медленно", Дэниэль Карлман. В мозге есть заяц и черепаха. Заяц пытается быстро сделать вывод, экономя время, очень полезен, но ошибается. А черепаха - тщательно все обдумывает, но работает медленно. С моей точки зрения - еще одна модель про мышление, с не очень понятной осмысленностью, потому что реально ты совместно и попеременно применяешь оба метода мышления. В том числе при оценке задач, к о которой шла речь. Так что рассказ получается сумбурным, я ушел. Говорят, потом был переход к SCRUM'у как способу решения проблем, но не следующий из предыдущего.

Александр Башарин Performance Lab. Как бойко начать проект по тестированию и не сдуться на пол пути

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

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

Андрей Иваровский runteo.ru. Масштабируемость тестового фреймворка

На мой взгляд, достаточно понятный доклад о решениях для масштабируемости разного вида. Уровни параллельности. Ant, TestNG. Конфигурации - системы и броузеры. Это надо заложить заранее. Он закладывает через фабрику, которая выдает конкретный броузер. Функциональная масштабируемость. Легкая адаптация к изменениям функционала без copy-paste. Выводы - думайте о масштабируемости на этапе проектирования.

Андрей Новротский Undev. Опыт выживания на техническом проекте в аутсорсе

Забавный опыт. Тестировщик попал в технический проект. Где линукс, консоль и куча незнакомых вещей. Как он там работал. В докладе - опыт и ссылки, откуда брать информацию opennet.ru, linux journal...

Олег Татарчук Global Logic. Роли, в которые играют тестировщики

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

Анна Скумина Apriorit, Игорь Любин auto-testing.ru. Риски. Философия и практические рекомендации

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

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

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

Решение - если на проекте с требованиями плохо, то тестировщики должны взять их в свои руки - все будут счастливы :)

Риторический вопрос. Почему разработчики перестали проверять свою работу, а привлекают тестировщиков? Я: тут два ответа. Ответ менеджера: потому что дешевле. Ответ разработчика: чукча не читатель, чукча писатель.

Ревью на уровне корпоративной политики. Ревью отличается от аудита тем, что смотрит на содержание и дает идеи по улучшению, а не просто смотрит на формальные требования (но это - личная терминология).

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

История про визит-эффект. Когда упало на компе клиента. Совет кэпа: подготовьте тесты. Оно ж все равно там упадет. А вот про план Б - иметь удаленную готовую машину - это правильно.

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

Сергей Вербенко S-Terra CSP. Каждый тест-менеджер должен посадить дерево или как искать баги в процессе

Методы. 5 почему. Рыбья кость Исикагавы. Дерево текущей реальности, Голдратт. Источником интереса для него было удивление в беседе с Мартыненко - что самый верный способ привести компанию к банкротству - это сделать, чтобы каждое подразделение работало максимально эффективно. Суть - надо работать над эффективностью в том месте, где ограничения, иначе оно бесполезно. И место ограничения должно быть максимально загружено.

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

Василий Кудрявцев ДАТАТЕХ. Ошибки начинающего специалиста по нагрузочному тестированию и как их избежать

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

Пример: если ты в скриптах завязался на id'ы, то тебе возиться с поддержанием. Я: а лучше не завязываться на id'ы или фиксировать их, это ж очевидно. С другой стороны, многие тестировщики заводят свои тестовые заказы, и полагаются, что они должны сохраниться.

Александр Мартюшов Grid Dynamics International. Я занимаюсь Fitnesse'ом каждый день

Детальный рассказ о продукте на практическом опыте. Думаю, интересен для тех, кто хочет его оценить. Только я не представляю, как он соотносится с другими материалами по Fitness.

Юлия Белова 2ГИС. Девять проектов в параллель. Живинка в деле

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

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

Рефлексия, выделение узких мест, работа над ними.

Шаги

Как можно быстрее включиться в процесс, познакомиться с продуктом, добавить себя в командные рассылки, преодолеть барьер первого общения.
Собственная приоретизация проекта и задач. Можно использовать любое, ей хватает Важно/Не важно и Срочно/Не срочно.
Согласовать свои планы с командами, могут быть узкие места
План на день и на неделю, отмечаю что сделано, корректирую.

Очень полезен - часовой обзор по продукту. Тестовое окружение.

Перед тестированием - поговорите с разработчиком 10-15 минут. Что затронуто, что могло сломаться, есть ли потребности в дополнительных настройках.

Задачи - не только протестировать, но и курировать, отслеживать выполнение. Я: и, блин, баг-трекер это сам не решает "а зачем мне это читать", нужна перестройка сознания. Но да, с баг-трекером лучше, чем без него и его внедрение - большой шаг вперед.

Помнить, что Важно и Срочно - они имеют еще и сроки, и надо их учитывать при переключениях.

Типы эффективных переключений

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

Остальное - неэффективно, и практически - не нужно.

Дополнительно - перекрестное опыление команд хорошими практиками.

А еще когда работаешь на многих проектах - интересно и взгляд не замыливается.

Полина Попова Генезис Телекоммуникационные Лаборатории. Способы повышения эффективности в работе тестировщика

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

Владимир Калёнов HELiOS IT-SOLUTIONS. О качестве, требованиях, сервисах и немного об ITSM

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

Анастасия Романова Parallels. Как мы строим работу с аутсорсерами. Опыт заказчика

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

Станислав Комарницкий Grid Dynamics International. Особенности процесса тестирования при внедрении Continuous Delivery на примере одной компании

Подошел ближе к концу. В целом рассказ про то, как они идут и опыт, с этим связанный. И это классическое внедрение сверху, идут год, и еще год идти будут. Грабли - известные, вовлечение и прочее. Рассказ не слишком сфокусирован. А continious delivery внедряется вместе с agile и прочим, что тоже накладывает отпечаток.

Татьяна Закатова Apriorit. 7 шагов к улучшению процесса тестирования в больших проектах

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

Владимир Солодов SuperJob. Система генерации чек-листов для регрессионного тестирования на основе анализа рисков

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

Алексей Чумагин Akvelon. История одного проекта или бег с препятствиями

Я пришел в конце. Практически - sucess story, с примененными приемами, правда вроде без изюма. Главный посыл: если предложат проект, даже если ничего не знаешь - соглашайтесь.

Полина Воробьева Exigen Services. Искусство совмещения позиций: тестирование и бизнес анализ в сложных проектах

Не с начала. Жесткий скрам, при выпуске релиза. В начале спринта тестировщику нечего делать и он недогружен, чем занять? А вдруг аналитик уйдет? И как бы вырастить? В общем идея будет Тестировщики, идите в Аналитики!

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

(нет элементов)

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

— Максим Цепков • 23:50, 29 апреля 2013 • нет комментариев

2013-04-29: SQAdays-13 (весна 2013)