SQA Days 15. Обзор докладов про тестировщиков-автоматизаторов

Давно отошла от автоматизации, поэтому обзор докладов по этой теме у меня маленький и не технический, а связанный с людьми:

·         Про обучение автоматизации людей, совершенно незнакомых с программированием, - Вадим Зубович "Sikuli Script как идеальный инструмент для обучения автоматизации"

·         Про то, каким автоматизатором не нужно быть, - Игорь Мирошниченко " Антипаттерны поведения и развития тестировщиков - автоматизаторов".

Вадим Зубович "Sikuli Script - идеальный инструмент для обучения автоматизации"

В своём докладе Вадим поделился опытом организации обучения автоматизации специалистов, которые не знакомы с программированием (тестировщики, бизнес-аналитики, менеджеры по продажам, которые продают, собственно, автоматизированное тестирование и другие).

Какой должна быть программа обучения?

·               Простой

·               Наглядной, визуализирующей результат

·               Должна решать максимально большой спектр задач обучаемого

·               Предполагающая креативность и творчество

·               Максимальная широта применения полученных знаний /Должна помогать решать какие-то задачи

·               В форме соревнования, геймификации

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

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

Автоматизация на Sikuli IDE для начинающих:

1.        Краткое демо с «прикладными» примерами

2.        Краткий обзор IDE с примером простого скрипта

3.        Установка IDE (см. в конце презентации инструкцию)

4.        Изучение базового синтаксиса

5.        Работа с ожиданиями и поиском

6.        Работа с клавиатурой

7.        Работа с условными операторами

8.        Работа с циклами

9.        Изучение тонкой настройки изображений

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

Вадим Зубович - Sikuli Script - идеальный инструмент для обучения автоматизации from QA Club Minsk

Презентацию и видеозапись доклада можно будет найти на сайте конференции.

Игорь Мирошниченко " Антипаттерны поведения и развития тестировщиков - автоматизаторов"

Игорь выделил в поведении тестировщиков автоматизаторов 3 антипатерна (они же "синдромы"): мамотёнка, павлина и крота.

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

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

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

В заключение, Игорь добавил, что не стоит избегать "неправильных подходов" (Record and Play, сравнение ожидаемых результатов с помощью скриншотов), они часто оказываются оптимальными. Вместе с этим нужно постоянно развиваться как личность, понимать, что нет идеальных людей, понимать, что вы работаете в команде и выполняете некую роль, при этом у проекта и лично у вас есть цели и задачи, которые должны быть первостепенны по отношению к вашим внутренним "червячкам".

Антипаттерны поведения и развития тестировщиков - автоматизаторов from SQALab

Презентацию и видеозапись доклада можно будет найти на сайте конференции.

SQA Days 15. Исследование багов: учимся у Шерлока Холмса!

В сегодняшнем обзоре я затрону только один доклад - доклад Инны Смирновой на тему «Исследование багов: учимся у Шерлока Холмса!»

Инна подняла отличную и наболевшую тему для многих тестировщиков и их руководителей. У меня давно уже крутилась в мыслях похожая идея. Всё думала как к ней подступиться, а тут прелестный доклад Инны.

Основываясь на ее докладе, найденном в интернете сайте и собственном опыте, рассказываю.

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

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

·         утверждение самого факта преступления (в приложении равнозначно факту нахождения бага)

·         сбор показаний у свидетелей (в приложении - выявление последствий бага, выяснение, как он проявляется, в чем выражается)

·         поиск улик (взаимосвязей вызвавших ситуацию)

·         расследование (анализ, построение гипотез о корне проблемы и их отсеивание)

·         следственный эксперимент (попытка воспроизведения бага)

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

Дедуктивный метод Шерлока Холмса состоит всего из двух шагов:

1.       На основе всех фактов и улик строится полная картина преступления.

2.       Отталкиваясь от полученной картины преступления, разыскивается единственно соответствующий ей обвиняемый.

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

Поэтому собираем максимум информации о баге:

·         Отклонение от ожидаемого результата

·         Анализ зависимостей с другими функциями, модулями, системами и т.п.

·         На каком окружении воспроизводится 

·         В какой версии воспроизводится

·         Информация из логов (серверных и локальных), из Firebug и других полезных инструментов

·         Способы воспроизведения и места откуда воспроизводится 

·         Продолжение варианта использования

·         Анализ похожих проблем

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

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

Если применить эти принципы в тестировании, то получится вот такой подход от Шерлока для исследования багов:

1.       Собираем информацию, выделяем существенное и отбрасываем случайное

2.       Генерируем все возможные гипотезы

3.       Сортируем их по степени вероятности

4.       Проверяем поочередно каждую гипотезу:

a.       Придумываем тест для подтверждения гипотезы

b.      Придумываем тест для опровержения гипотезы

5.       При необходимости, возвращаемся к шагу 2 и генерируем новые гипотезы

Однако суровая правда жизни тестировщика гласит:

·         некоторые баги так и не воспроизводятся

·         иногда лучше спросить у программиста и узнать его идеи о корне проблемы

·         если вопроизведение бага занимает более получаса, лучше спросить у руководителя или ПМа нужно ли такое длительное исследование вообще

И отлично Инна подметила, что всё это не будет иметь никакого смысла, если не оформлено в хороший багрепорт! Так что учимся писать понятные всем баги. :)

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

Исследование багов: учимся у Шерлока Холмса! from SQALab

P.S. Холмс говорит, что человеческий мозг имеет ограниченную ёмкость для хранения информации, и обучение бесполезным вещам сократит его способность к изучению полезных.

Поэтому тренируйте и берегите свою память!

SQA Days 15. Обзор докладов из секции функционального тестирования

Во втором обзоре докладов SQA Days-15 рассмотрены следующие:

·         Дмитрий Химион "Тестирование игровой механики в компьютерных играх"

·         Наталья Голодюк "Quality Assurance в условиях тотального A/B тестирования"

·         Сергей Остапенков «Обеспечение качества: практические советы»

Дмитрий Химион "Тестирование игровой механики в компьютерных играх"

Cпасибо Дмитрию за введение новичков в курс дела. Его доклад о самых-пресамых азах тестирования компьютерных игр - терминология, несколько небольших примеров и характеристика навыков тестировщика игр.

Очень жаль, что только 40 минут, или вот если бы... Рина Ужевко дополнила SQA Days-15 своим опытом и докладом, то мир игр стал бы ещё более осязаем.

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

Терминология.

Игра - это последовательность интересных выборов. (с) Сид Мейер, гейм-диайнер.

Игра состоит из контента и игровой механики.

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

 

Компоненты игры и их взаимодействие

Игровая механика - это набор правил, по которым работает, игра и математическая модель, которая стоит за этими правилами.
Дизайн уровней (level design) - это создание игровых уровней из элементов оформления и связанного с ними игрового процесса на основе существующих игровых механик.

Обратная связь (feedback) – это реакция игры на действия игрока, передаваемые игроку в визуальной, звуковой или иной форме.

Gameplay – это процесс взаимодействия игрока с игрой посредством игровых правил и возможностей.

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

Кто же может стать тестировщиком игр?

По мнению Димы тестировщик должен обладать следующим набором характеристик:

·         Здравый ум.

·         Большой игровой опыт.

·         Умение считать.

·         Аналитический склад ума.

·         Быть от части гейм-дизайнером.

Видео и слайды презентации можно будет найти на соответствующей страничке конференции.

Наталья Голодюк «Quality Assurance в условиях тотального A/B тестирования»

A/B тестирование (оно же мультивариантное тестирование) применяется, как это ни банально, в мультивариантном ПО – ПО, в котором одна и та же фича сначала реализуется разными способами с целью исследования рынка, а затем после сбора статистики выбирается лучший вариант (тот, что приносит больше продаж, или более удобен для пользователя и т.п.). Пользователи могут распределяться между вариантами реализации случайным образом либо по некоторому заданному правилу.

Рекомендации по тестированию на самом деле довольно привычные:

·               Само собой проверять реализацию требований и корректность выполнения логики каждого из вариантов

·               Проверять процентное распределение пользователей по вариантам реализации

·               Проверить, что пользователь не может увидеть в рамках одной сессии сразу несколько вариантов реализации

·               Проверить, что собирается верная статистика по каждому из вариантов

·               Автоматизировать стоит уже итоговый вариант

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

Много информации по этой теме есть на Wiki.

Видео и слайды презентации можно будет найти на соответствующей страничке конференции.

Сергей Остапенков «Обеспечение качества: практические советы»

Доклад Сергея я слушала в рамках встречи-подготовки к конференции, которую мы организовывали в QA Club Minsk, поэтому на конференции не ходила на выступление. Знаю, что презентация – это полноценный набор самостоятельных практических идей по улучшению качества. Всем, кто заинтересовался советую изучать досконально саму презентацию. Там всё, что надо.

Видео и слайды презентации можно будет найти на соответствующей страничке конференции.

SQA Days 15. Обзор докладов по тестированию мобильных приложений, кроссплатформенному и кроссбраузерному тестированию

Лично мне SQA Days #15 очень понравилась: профессиональная атмосфера, полезное содержание докладов, отличная фан-зона (особенно громкая виртуальная реальность, заставляющая дрожать коленки)!

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

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

• Наташа Брич "Непереносимая переносимость кроссплатформенных приложений на примере десктоп приложений"
• Юлия Горлова "Лайхаки ручного тестирования на мобилках"
• Таисия Рыбак "Как оптимизировать тестирование мобильных приложений"
• Алёна Пономаренко "Ошибки при проверке внутренних платежей Android-iOS и их решение"
• Максим Белявский "Подготовка апдейта мобильного приложения "Одноклассники"
• Дмитрий Штепура "Кроссбраузерное тестирование с популяризацией HTML5 и CSS3. Internet Explorer, не такой как все"

Наташа Брич "Непереносимая переносимость кроссплатформенных приложений на примере десктоп приложений"

Наташа рассмотрела несколько задач тестирования и как они выполняются на ее проекте. Ключевые моменты доклада я собрала в таблицу.

Задача тестирования	Что включает в себя	Где проводить тесты? Как сэкономить время?
Инсталяционное тестирование	Проверку ресурсов Запуск инсталляционного пакета Тестирование мастера установки Список файлов Проверка прав доступа к файловой системе Регистрация расширений (windows) Деинсталляция приложения ...	Время не экономится. Проводится весь набор тестов на всех платформах
Тестирование интерфейса	Проверяется расположение всех элементов	Проводится на всех ОС. Время экономится за счет совмещения с функциональным тестированием.
Функциональное тестирование	1. В первую очередь тестируется основная платформа1: a) Прогоняют все use cases b) Проводят негативные проверки на невалидный ввод данных c) Воспроизводят старые ошибки 2. Формируется список багов  (список1) найденных на платформе1. 3. Проверяют платформу2: a) На платформе2 проверяют непрошедшие тесты, т.е. воспроизведениние багов из списка1. b) Прогоняют все use cases (кроме тех, что проверены в пункте 3.a). c) Проводят негативные проверки на невалидный ввод данных (кроме тех, что проверены в пункте 3.a) d) Воспроизводят старые ошибки (кроме тех, что проверены в пункте 3.a) 4. Формируется еще один список багов (список2), найденных только уже на платформе2 (по шагам 3.b, 3.c, 3.d). 5. На платформе1 проверяется наличие багов, найденных на платформе2 (т.е. из списка2)	На первой ОС проводится полное тестирование. Время экономится на второй и последующих ОС, где в первую очередь проверяются непрошедшие ранее тесты.
Регрессионное тестирование	проведение смоук перепроверку багов с высшей критичностью и приоритетом	Проводится перед релизом на всех заявленных ОС.

Видео и слайды презентации можно будет найти на соответствующей страничке конференции.

Юлия Горлова "Лайхаки ручного тестирования на мобилках"

Отличный легкий доклад и отличный докладчик! Юля дала простые и хорошие советы по нескольким темам.

Администрирование девайсов:

·               В парк выбирайте:

o      не менее двух устройств на каждую существенно отличающуюся версию операционки.

o      плюс девайсы, на которых были замечены какие-то специфические проблемы

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

·               Каждый тестировщик, когда собирается идти домой,ставит все телефоны, с которыми он работает, на зарядку, т.о. гарантируют рабочее состояние каждого из телефонов.

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

·               Ведите электронную таблицу, в которой перечислены все ваши устройства и их технические характеристики (название модели, размер экрана, количество памяти, процессор, установленная ОС, идентификатор телефона и т.п.). Здесь помечают, если телефон взяли в другой отдел.

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

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

Управление билдами:

·               Т.к. пользователи любят нативный дизайн, то для каждой из платформ разрабатывается свое приложение, а не одно единственное кроссплатформенное.

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

·               Билды устанавлиют через QR коды, ведущие на инсталяк билда. Это экономит время.

Сбалансированное тестирование:

·               В этой секции были сделаны примеры конкретно для приложения 2ГИС, но в целом это довольно общие вещи:

·               Фичу нужно тестировать параллельно на двух платформах.

·               Для Android планировать тесты на расход батареи.

·               Для Android из-за миллиона экранов пришлось что то придумывать (в 2ГИС разработали стандартные темы).

·               Android. Проверки всех сборок одного и того же билда, созданные под разных вендоров, включают проверки на запуск и различия (метки вендоров и WebAPI-ключи).

·               На iPad делают сессии свободного тестирования, в которых проверяют вёрстку и особенно при поворотах экранов.

·               iOS. Когда истекают сроки, то сначала отправляют билд в AppStore, а потом проводят регрессионные тесты. Если найдется баг, то перезаливают. Мы делаем также. Очень рабочая схема.

·               iOS. Если очень-очень нужно выпустить вчера, то пишут письмо в AppStore и чаще всего на подобного рода письма откликаются положительно.

Бета-тестирование:

На Android ребята опробовали схему официальную схему бета-тестирования через Google comunities и Google Play. По сути, тем кто зарегистирировался в гуглгруппе стало доступно скачивание более новой версии. И эти ребята смогли написать в 2ГИС спецефические проблемы, обнаруженные на своих девайсах.

Текущая поддержка:

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

·               Ну а также встраивать формы обратной связи в само приложение. При этом письма в отдел поддержки должны приходить сразу со всей технической и отладочной информацией о девайсе (модель, ОС, экран, процессор, текущий тип связи и т.п.)

Видео и слайды презентации можно будет найти на соответствующей страничке конференции.

Таисия Рыбак "Как оптимизировать тестирование мобильных приложений"

Таисия - представитель Hewlett-Packard и посему рассказывала о новом облачном решении от HP для тестирования мобильных приложений на реальных девайсах - HP UFT MOBILE (HP Unified Functional Testing Mobile). Собственно, само решение - это сервис, предоставляющий доступ к парку девайсов.

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

Ценителям решений от HP, не знакомым еще с этим инструментом, будет полезно подобное введение.

Видео и слайды презентации можно будет найти на соответствующей страничке конференции.

 

Алёна Пономаренко "Ошибки при проверке внутренних платежей Android-iOS и их решение"

Доклад - этакая база для тех, кто начинает тестировать платежи (in-app purchases) на Android и iOS. Алёна в докладе отвечает на такие вопросы как:

·               как создать тестовый аккаунт?

·               списываются ли деньги?

·               как проверить что покупка совершена успешно?

·               что делать, если, вроде всё правильно делаешь, но система выдаёт странного характера ошибки типа "такого пользователя не существует"?

Отныне всем, кто хочет начать тестирование iOS приложений буду рекомендовать посмотреть две презентации - свою "Тестирование iOS приложений. С чего начать?" и Алёнину про in-apps purchases.

 

Максим Белявский "Подготовка апдейта мобильного приложения "Одноклассники"

О чём рассказ, в принципе, понятно из заглавия. У "Одноклассников" есть, чем поделиться.

Особенно запомнилось:

·               Тестируют прототипы. Я считаю, что наличие этого этапа отображает зрелость компании и её процессов. Молодцы.

·               История реальная история про юзабилити тестирование и использование техники eye-tracking  (когда за глазами испытуемого следят).

·               Особенности выкладки приложений в магазины: iOS / WinPhone - выкладка сразу всем пользователям, а на Android используют возможность постепенной выкладки - нескольким процентам пользоватлей.

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

Мне кажется это крутой схемой (особенно для iOS), т.к. таким способом можно пытаться убивать двух зайцев - сначала работать над обновлением, а потом, пока неделю приложение находится в очереди на ревью, работать над исправлением багов и по только что выпущенному функционалу и по тем багам, на которые забили, упс... :) по тем, которые "забыли" в дебрях трекера из-за более приоритетных задач.

Видео и слайды презентации можно будет найти на соответствующей страничке конференции.

 

Дмитрий Штепура "Кроссбраузерное тестирование с популяризацией HTML5 и CSS3. Internet Explorer, не такой как все"

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

Видео и слайды презентации можно будет найти на соответствующей страничке конференции.