Первый день весенней SQA Days 2012 не просто оправдал ожидания — он их превзошел. Я знал, что конференция — очень живая, а тестировщики — активно общаются поэтому на конференции много практических рассказов, из которых можно почерпнуть идеи — и ожидал этого. Но получилось больше. За счет иностранных докладчиков, которые много работают с качеством продукта и сделали хорошие и неожиданные для меня доклады. Конференция реально становится интернациональной, при чем широко — Германия, Нидерланды, Израиль, Япония. Единственное — мне по-прежнему сложно одновременно слушать доклад по английски и записывать его, так что о них будет несколько в телеграфном стиле.

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

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

А сейчас — обзор докладов.

1 Очень понравилось

1.1 Ярон Цубери, Израиль. Как найти побольше багов

Очень хороший доклад. О том, что при недостатках времени ориентироваться надо на риски. Он проясняет и структурирует то, что ты интуитивно делаешь, плюс — показывает, что ты не делаешь, а, наверное, стоило бы. И не сухая теория. Выделите первый этап тестов, полагаясь на здравый смысл (sanity)! 🙂

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

И все в спокойной манере. Этакое объединение научного подхода с современным agile — мерим, оптимизируем, полагаемся на здравый смысл, но имея эти результаты измерений и много зная о процессе.

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

1.2 Сусуму Сасабе, Япония. На пути к глобальному сотрудничеству для улучшения качества программного обеспечения

Совершенно неожиданный доклад, содержание которого невозможно было предсказать по названию.

Докладчик — Susumu Sasabe, Советник Союза Японских Ученых и Инженеров? работает в NEC. 1948 года рождения, в IT — с 1975 года, а до этого работал с телекоммуникациями. При этом живой и современный.

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

А потом он перешел к более интересным материям — к Design of Process Architecture и организации непрерывного процесса улучшений — в софте, а не вообще, но применяя общие методики, TQM. И тут был совершенно неожиданный пинок в сторону западных умозрительных теорий, из которых выросли PMBOK, ISO 9004 QMS (это про качество) и CMMI. Но это я написал — пинок. Реально была вполне корректная схема, которую можно будет увидеть в презентации, из которой этот теоретический уклон был виден. И были показаны его последствия — необходимость обучения (с сертификацией) и консалтинга 🙂 А потом — еще одна схема, 4 квадрата Теория — Практика, Low — High. И в ней TQM был дважды: европейский — в теоретическом квадрате, а японский — в практическом (с малой теорией).

А потом была совсем неожиданная часть, которая, собственно, и составляла тему доклада о глобальном сотрудничестве. Японцы написали свою книгу по качеству в IT на основе применения TQM — SQuBOK. На английском книга пока не опубликована, но для международных конференций японцы ее переводят, в том числе — презентовали на конференциях в Штатах. И сейчас идет процесс распространения. Который, кстати японцы видят тоже весьма интересно — не через принятие общего стандарта, а через создание региональных версий, из которых только потом можно выработать общий стандарт. В ЮВА процесс идет активнее, в частности, на китайском английском книга вроде как уже есть 🙂 И у нас он рассказал…

Вот так.

 1.3 Евгений Ткаченко и Маргарита Шлыкова. Формула успешной автоматизации

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

Первой была история Евгения о том, как Иннова внедряла тестирование в одной IT-компании. Социальная сеть университета. 20 модулей, 3 роли учебных + 4 роли социальных. Число тест кейсов огромно. Начинал он один, 3 года назад. Релизы раз в 3 месяца, регресс 7 дней. Отлавливалось 100+ багов, исправить их не получалось. Но потом начал использовать Selenium, 3 года назад он еще не был так популярен и известен, как сейчас. И потому приходилось проходить многое самому. Тем не менее, за 1 месяц уже сделал самые критичные тесты — права на контент, безопасность. И дальше — развивал.

Из интересного. Для начала — он автоматизировал ручные тест-кейсы. Оказалось — тяжело поддерживать. Был использована практика Data-Driven, он сделал пару провайдеров, пошло как часы.

Вторая история — Маршариты из Ланита. Проект .Net WPF, несколько клиентских приложений. Плюс поставка данных от приложений на WinForms. На старте 3 недели регресса. Еженочный билд acceptance-test. Начали с HP Quicktest professional. Но! было многие проблемы. Особенно из-за собственного фреймворка — доступ к сложным контролам: дерево, грид… Разработчикам надо было дописывать. Но нужна была диагностика: проблемы в HP Qt, или в приложении.

В результате они нашгли White (библиотека с открытым исходным кодом, название может быть ошибочно). Пришлось написать достаточно много библиотек, но получилось. Плюс While — это C# и VS — поэтому тесты можно отлаживать, а HP QTP — черный ящик. Было сложно обосновать заказчику, но они справились. Но пришлось делать обвязку. Например, окружение тестов по xml-описанию форм — в том числе отслеживают переименования, тест ломается на этапе компиляции.

Фреймворк, тестовое окружение — обязательно надо проектировать. Есть: BAT-тесты + регресс на час + 15% тест-кейсов, все проходит за 5 часов. После полной автоматизации — выйдут к регрессу за неделю.

 1.4 Николай Алименков, XP Injection. А вы знаете что тестируют ваши тесты?

Визуализация. Разнообразная и всеобъемлющая. Показывающая связь тестов с требованиями, с кодами, с элементами UI. Из-за широкого предмета доклада каждый конкретный предмет представлен телеграфно, но что делать. В любом случае, про инструменты было сказано, что они преимущественно легкие или известные, поэтому поиском и местами небольшой разработкой реализуются. А ключевые слова — даны. Например, для связи с кодом — Selenium, Maven, JACOCO, Junit, Apache Tomcat, Sonar плюс примеры конфигурационных файлов.

 1.5 Алексей Баранцев. Переходя все границы…

Я попал на конец, а зря. Очень интересный доклад про всякие границы с кейсами.

Про зацикленность поля — ставишь ширину -1 и оказывается максимум.

Авианосец. Незаполненное поле в задании для двигателей проинтерпретировали как 0, деление на ноль, креш. Файл с заданием сохранился, и при загрузке он пытался восстановить. И целый час (а то и больше) авианосец болтался неуправляемый — двигатели работали только под компьютерным управлением.

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

Ракеты. Пэтриот. Разрабатывали чтобы сбивать ракеты летающие со скоростью 2М. Работало. Скорость увеличивалась, работало — уже в железе. Потом, в несчастный момент, с увеличением скорости цели малое число сбросилось в ноль. И ракета взорвалась в установке, 160 солдат погибли.

Границы как зеркальный лабиринт. Проходы не отличаются от отражений. Нужно несколько кордонов.

Переходите границы. Пусть не сразу, а по одному.

Границы внутри людей. Они — самые важные.

• «Я тестирую только то, что написано в спецификации» — ну и дурак. Как программа работает за границами спецификации лучше узнать от тестировщика, а не от пользователей.
• «Я тестирую только то, что в плане»
• Функциональная фиксация
• Границы восприятия. Представьте на месте человека в возрасте, со слабой моторикой и прочее.
• Образование. Мы — очень умные, и IT-шные. А пользователи — они с разным образованием. Гуманитарным или финансовым.
• Компания. Это тоже граница.
• Лень. Это — самая серьезная граница.

А в конце — роскошный мультик. Смешарики. Земля круглая. Заяц — он тестировщик.

 2 Хорошие доклады

 2.1 Алексей Лянгузов. Про смену работы тестировщиком

Внеплановый доклад. Алексей работал в Sun, долго, ему нравилось. Когда их купил Oracle — компания реально изменилась. Oracle он не выбирал, и через некоторое время — решил сменить работу. Опыт оказался неожиданным: после публикации резюме ему пришло столько предложений, что возник вопрос о самоопределении, чтобы взвешенно подойти к выбору работы. Я, правда, слушал небольшой кусочек — доклад был параллельно с Цубери.

 2.2 Татьяна Зинченко. Проект без правил или Команда моей мечты

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

 2.3 Виктория Птицына и команда рассылки Software-Testing.RU. База знаний

Доклад был совместный, выступающие из команды рассылки Software-Testing.RU рассказывали, как у них организован процесс ведения базы знаний. Которые сами не зарождаются, а требуют внимания. Для нас (CUSTIS) на таком уровне это во многом уже пройденный этап, стоят другие задачи. Но для тех, кто начинает, доклад будет очень полезен. И перечисленными способами и инструментами со своими плюсами и минусами, и, самое главное — достаточно подробным рассмотрением проблем, связанных с человеческими особенностями, которые весьма влияют на процесс работы с базой знаний.

 2.4 Таисия Сибгатуллина, HP. Управление проектами по разработке в стиле Agile или Waterfall, чья доска круче?

Я был не с начала, поэтому про waterfall и agile — как-то не уловил. Скорее, это мемы. Например, в середине проскользнуло: ежедневный статус проекта — agile.

Но вообще доклад — хороший. HP вообще начал делать хорошие доклады — вместо скучной презентации своих инструментов он рассказывает о реальных проектах. При этом инструменты присутствуют на screenshot’ах и в рассказе, но это уже не реклама, а часть окружения. При этом ты заодно узнаешь о функционале и развитии, проскакивают фразы типа «этого не было, сейчас делаем продукт позволил», но они не носят рекламного характера совершенно.

А проект — Банковское ядро. 2 года, с нашей стороны 30 разработчиков и 65 тестеров: 25-30 IT, остальные из бизнеса. Плюс индийская сторона. Интеграция: 45 в первой очереди, до 120 во второй. Вполне достойно. Работы вели 4 аналитика — лидеры тест-групп по 5-6 человек, которые взаимодействовали еще с бизнес-тестерами по своему сегменту. IT- тестеров . (по 15 человек). Но в эти 65 — они с бизнес-пользователями, так что реально тестеров — около 25-30, так что команда 5-6 человек.

2.5 Марина Дидковская, Видео Интернет Технологии. Тестирование спецификаций

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

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

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

Еще важно — когда спрашиваешь

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

2.6 Юлия Муфель, NIX Solutions. Полезные фишки тестировщика или о чем никогда не стоит забывать

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

2.7 Ольга Киселева, HFLabs. Agile. Улучшаем традиции

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

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

А в конце — очень замечательная сентенция. Вот вы сейчас узнаете много не нового, вернетесь, расскажете и скажете «давайте применим» и думаете — все с радостью побегут… Так вот, скорее не побегут, а скажут «зачем, и так работает». Я: вещь понятная, но обламывается об нее куча народу, когда сам придумал, а народ не врубается. Так что будьте готовы к трудному продвижению.

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

3.1 Марсел Янки, Micro Focus, Нидерланды. Непрерывное тестирование для улучшения качества кода

Моежт быть, я неверно понял, но по-моему это было об инструменте и не больше. Хотя я быстро ушел на параллельный доклад.

3.2 Штефан Гёрике, iSQI GmbH, Германия. Путь к совершенствованию

Увы, это был доклад о сертификации тестеров. В том числе Agile-тестеров.

3.3 Татьяна Голубева, SoftServe. User Interface Тестирование – все ли так просто?

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

3.4 Дмитрий Романов, Itera Consulting Ukraine. Тестирование в BI проектах

Доклад был правильным, но очевидным. О том, что тестировать BI-приложения сложно по причине больших объемов данных, многобразия сред работы приложения и отсутствия инструментария. С рассмотрением шагов, которые надо тестировать — интеграция, преобразование на входе, агрегация…