SQA Days — 17. Краткий обзор посещенных докладов.

Привет, друзья.
В этой статье я хочу поделиться впечатлениями от посещения конференции SQA days 17, которая проводилась в «Президент-отель» в г. Минске 29-30 мая 2015 года.

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

В этом году я решила попробовать свои силы в качестве докладчика. Для конференции я подготовила доклад в тематике «управление командой». Он заинтересовал программный комитет конференции, —  и я получила возможность вам его представить. Доклад был построен на опросе менеджеров и тестировщиков на тему взаимодействия в команде тестирования.
Хочу выразить особую благодарность Сергею Атрощенкову, Сергею Нестеренко и Веронике Савченко, которые задействовали все свои возможности для того, чтобы привлечь внимание к этому опросу, и разместили его на своих сайтах:
barbaricqa.com, qahelp.net и qaclub.by

Организация
Места для выступления были разделены на 3 секции: 2 аудитории на 200 человек и 1 аудитория на 500 человек.
Доклады в секциях расформировали по
времени выступления: 40 минутные и блиц-доклады по 20 минут.

Всем участникам конференции выдавался бедж, сумка с логотипом SQAdays и сборник с аннотациями . В сборнике для каждого доклада отводилось свободное место, где можно было делать заметки по докладу.

Во время проведения докладов в холлах всегда были пирожки или печеньки с водой и чаями для перекусов. Хорошо было продумано время на обед в 3 смены. Во время обедов также проводились доклады , — и можно было выбрать, в какое время сделать себе перекус.
Кормили нас в ресторане «Националь», который находился прямо в отеле: гарниры, мясо в сыре, салаты, овощи, хлеб, апельсиновый сок или морс. В целом хорошая белорусская кухня. Кушали стоя. Видимо, такая задумка была.

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

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

Вообще тестировщики — это очень общительные и веселые ребята. На конференции мне удалось убедиться в этом еще раз.

А на следующий день на том месте, где продавали книги, на столе лежали слегка потрепанные, но целые ( и даже с автографами авторов) книги на тему тестирования: как тестируют Гугл, приницпы тестирования веб-безопасноити, книги Демарко и Листера на тему успешных проектов и команд, книга Брукса «Мифический человеко-месяц» и многие другие. Как рассказывали организаторы — это подарок от Владислава Орликова. Книги, которые он когда-то читал,- и они хранились у него в коллекции. Те, кто пришел на доклады сутра, имел больший выбор и мог бесплатно забрать себе одну из понравившихся книг. Это было очень здорово!
Я ничего не взяла, потому что самые интересные для себя из этих книг я уже прочитала. Но к концу дня почти все книги нашли своих хозяев!

Доклады

Конференция длилась 2 дня.
На мой взгляд, любая конференция — это способ получить определенную дозу мотивации и новых идей. А после все это воплощать на основном месте работы и заряжать других  атмосферой творчества и вдохновения на новые свершения.
В своем обзоре я хочу обратить внимание на те моменты, которые показались наиболее интересными лично для меня. На некоторые доклады я даже сделала небольшой майндмап для лучшего запоминания: т.е. идеи, которые я вынесла для себя из докладов.
Начнем по дням 29 мая 2015.
В этот день мне запомнились доклады
«Автоматизация тестирования: доступна каждому или удел избранных» Игоря Хрола. Wargaming.
Доклад мне очень понравился. И вот что я взяла из него для себя.
Здесь доносилась идея, что в процесс автоматизации нужно вовлекать ручных тестировщиков, чтобы они уже на этапе создания тестов делали хотя бы шаблоны скриптов, которые будут потом дорабатываться автотестерами. Это повышало уровень ручных тестировщиков. А Автоматизаторам не нужно было вникать в подробности тест-кейса и создавать его с нуля. Таким образом, автоматизаторы  дорабатывали готовые сценарии.
Он рассказал, что они поменяли язык скриптов с  Java на Phyton.
А также очень посоветовал ручным тестировщикам  проходить занятия на codeacademy.com, для того, чтобы выучить основы языка автоматизации и двигаться дальше в своем развитии в автоматизации.

Также он рекомендовал изолированние тестирование связанных между собой продуктов. Для этого ставить заглушки на куски кода.

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

Avtomat-testir-Igor-hrol

Понравился доклад Олега Коледы «Качественное тестовое задание? Без проблем» Artox Lab.  Стало понятно, что при наборе сотрудников в компании делают упор на любознательность и тщательный подход к поиску багов: обширный анализ как внешнего интерфейса, так и пользование инструментами вроде Firebug, и заглядывание в исходный код страницы.
Тут все зависит от уровня тестировщика, которого хотят взять. Но есть еще один момент, на мой  взгляд,  — не всегда хороший человек, придя на собеседование, сможет показать свои аналитические и другие качества на 100%. Иногда это раскрывается в процессе работы. Поэтому, мне кажется, важно учитывать еще способность человека к быстрой адаптации, а не только надеятся на уже имеющиеся знания и то, что человек сможет проявить себя на интервью с 1-го раза по максимуму.

Запомнился доклад Юрия Малого «Monthly Operations review». Comodo.
Особо запомнилась «Communication matrix» — это одна из метрик, по которой определяют взаимодействие руководителей между отделами. В этой матрице 1 раз в месяц каждый менеджер отмечает, сколько раз он общался с каждым из других менеджеров в области своей работы. По частоте общений можно было понять, где проседает коммуникация.

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

monthly-review

Доклад Андрея Павлова «Правдивая история о тестировании SQL Server Change Data Capture» запомнился скорее с точки зрения вернуться к докладу, если понадобиться тестировать этот функционал. Сам докладчик рассказывал очень компетентно и уверенно, правда, немного быстро. А технические вещи на скорости понять не всегда легко, поэтому заинтересованным скорее всего нужно будет пересматривать доклад и видео, чтобы собрать картину целиком.

Еще один запомнившийся  доклад   Макса Богуславского «Отдел автоматизации своими руками» Banki.ru
Из всего доклада я уловила одну важную идею( хотя она прозвучала в виде шутки): если ты не можешь получить обратную связь от клиентов — просто отключай потиху им функциональные модули. И смотри — если начнут жаловаться, — значит этим функционалом они пользуются =))

otd-avtomat-test-maks-bogusl

 

А доклад «Двое из ларца — одинковы с лица? Или тестирование методом компарирования» Алексея Миронова  на тему тестировния c помощью Selenium+Page Object запомнился тем, что сразу после доклада Алексей сделал предолжение руки и сердца своей девушке, которая тоже была в зале на конференции. Такие дела =)

День 2-й, 30 мая

Сутра день началася с очень классного доклада от Наталии Узенцовой «Как вводить нового тестировщика в команду». Как хорошо, что я пришла пораньше и сходила на этот доклад. Людей было не много, но количество лайков на sqadays.com в соотношении с количеством людей, которые его посетили говорит само за себя (лайков много). Доклад очень понравился.
Наталья подала очень много хороших идей не только для введения тестировщика в команду, но, на мой взгляд, и показала, что правильная предварительная подготовка предотвращает плохие показатели (правило 6П Брайна Трейси).  Если человеку в самом начале предоставить условия для хорошего роста, то и расти он будет с пользой для проекта и компании в будущем.
Идеи, которые я взяла для себя:
—  На долгом проекте подготовить вводный туториал в виде видео и практических заданий, чтобы человек мог быстро ознакомится с азами проекта и попрактиковаться.
— Не сваливать на него регрессию, которую самим надоело тестить. Ведь он новичок,  — и понятно, что еще не все понимает, чтобы качественно протестировать.
— Первые 3 месяца работы встречаться с человеком 1 на 1 чаще и корректировать его путь в компании. Не оставлять человека одного.
— Менеджеру — составить список для себя , что я ожидаю, чтобы этот человек умел после прохождения испытательного срока, и сопоставлять ожидания и реальность: например, умеет четко расписывать баги,  на него никто не жалуется…
— Помнить, что не только он должен понравится нам, но и мы, как компания, должны понравится этому человеку.

uzencova-vvodit-testir-v-komandu

 

Интересен был доклад Алены Дашкевич «Улучшить KPI в 2 раза? Сделано!» Доклад был очень насыщенным и покрыл, на мой взгляд, огромное количество вопросов работы в тестовой команде в одном коротком выступлении. Как по мне — так этот доклад можно брать просто как чек-лист и проецировать на свой проект: что мы еще не сделали. Хорошая идея прозвучала по поводу общего чата по проекту — люди могут в одном месте задавать профессиональные спец. вопросы и получат ответ от команды. На проекте Алены до 150 человек — и это, как показала ее практика не очень напрягает, потому что в день туда пишут 3-4 поста с вопросами: был ли такой баг, например. Это помогает не постить дупликаты или не тратить время на поиск в джире.
Другие идеи:
— Анализировать причины пропущенных багов
— Чаще проводить демо-сессии с заказчиком
— Вовлекать заказчика в принятие решение по найденым багам
— Внутренний анализ багов: время жизни бага, какого качества баги, кто какие баги находит, кто больше багов находит, статистика 1 месяц
— Отношение багов к стори поинтам от заказчика ( т.е. эффективность стори поинтов — не совсем поняла этот график?? — позже уточню)
— Проводить мозговой штурм
— Выделять время на эксперименты
— Простые решения самые эффективные

Доклад Германа Варгина «Как заслужить доверие заказчика при передаче проекта новой команде тестирования?» запомнился мыслью, что доверие заказчика сложно заслужить, но очень просто потерять. Поэтому нужно постоянно работать на поддержание этого доверия, например,  в важных вопросах добавлять в копию заказчика и косвенно делать его участинком процесса тестирования.

«Маленькое кладбище багов» Екатерина Засухина
Хороший доклад. Запомнилось правило двойного нажатия. Об этом не знала. Оказывается, что часто на кнопку нажимают 2 раза. И вот после 2-го раза могут быть очень неожиданные результаты.  Напомнила, что не следует слепо верить тому, что тебе сказал разработчик — нужно самому проверять.
Особенно понравился ответ Екатерины на вопрос «Что делать, если баг не хотят фиксить». Ответ был следующий:
Попытаться убедить человека. Если не получается, то попытаться убедить руководство. Если не получается,  то убедит первый провал на продакшене =)
После этого ответа я прониклась глубоким уважением к опыту и компетентности докладчика.

Из доклада Яна Алексеенко «Интервью: пособие к применению» я вынесла для себя 3 основных качества хорошего тестировщика:
1) Уточнять требования к продукту ( Задает вопросы — как это должно работать для того, чтобы сделать покрытие максимально полным).
2) Оценивать риски
3) Предлагать улучшения по продукту

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

P.S.  Хотите что-то уточнить или улучшить? Я всегда рада вашей обратной связи  =)

С уважением, Анастасия Симанович

Добавить комментарий

Ваш e-mail не будет опубликован.