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

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

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

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

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

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

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

Докладчик - 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. На английском книга пока не опубликована, но для международных конференций японцы ее переводят, в том числе - презентовали на конференциях в Штатах. И сейчас идет процесс распространения. Который, кстати японцы видят тоже весьма интересно - не через принятие общего стандарта, а через создание региональных версий, из которых только потом можно выработать общий стандарт. В ЮВА процесс идет активнее, в частности, на китайском английском книга вроде как уже есть :) И у нас он рассказал...

Вот так.

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

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

Первой была история Евгения о том, как Иннова внедряла тестирование в одной 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 часов. После полной автоматизации - выйдут к регрессу за неделю.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таисия Сибгатуллина, 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 человек.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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