13 апреля в Екатеринбурге пройдёт конференция DUMP — самая масштабная конференция для разработчиков на Урале. Пятый год подряд будет секция, посвященная тестированию.
В этом году в программе секции «Тестирование»: Арсений Батыров (Badoo) проведёт мастер-класс по автоматизации мобильных приложений, Анастасия Асеева (Альфа-Лаборатория) расскажет про командную ответственность за качество, Мария Глухова (Targem Games) про работу с добровольными помощниками и о том, можно ли сделать это сотрудничество взаимовыгодным, а Иван Румак (СКБ Контур) про тестирование безопасности.
Ниже — обзор и видео докладов прошлого года.
1. Ольга Назина, автор портала Testbase.ru, тренер по тестированию, рассказала, как мастерски решать задачу, с которой каждый из тестировщиков встречается регулярно: как «продать» баг разработчику и нужно ли ему что-то продавать?
2. Андрей Сатарин (Яндекс) поведал о вызовах, которые бросает тестировщикам разработка распределенных систем, о существующих ограничениях и их влиянии на функциональность.
3. Ошибки бывают не только у разработчиков, но и у тестировщиков. Анна Бандура, Виталий Рощупкин, Антон Рычков, Дмитрий Якин из СКБ Контура поделились боевыми историями о том, как они косячили сами, пока искали косяки других.
4. Мария Глухова (Targem Games) открыла завесу тайны над Геймдевом и сравнила тестирование игр и софта. И даже показала, как проверяют баги на примере космического MMO-экшена Star Conflict.
5. Максим Захаров, Елена Зырянова и Илария Тарасова (СКБ Контур) рассказали о том, как по-разному можно добиваться одной и той же цели, и как превратить рутину в рост. О том, как тестирование плавно переходит в аналитику, проектирование и разработку.
При автоматизации тестирования очень часто приходится сталкиваться с вопросом «Что автоматизировать в первую очередь?» Автоматизация не делается ради автоматизации: хочется видеть результат процесса, который давал бы положительный ROI (подробнее о расчете ROI можно прочитать тут).
Почему важно использовать автоматизацию?
Принято считать, что автоматизация тестирования действует как инструмент поддержки ручного тестирования, но на самом деле важно понять, что автоматизация – это наилучший способ не просто сэкономить время, но и повысить эффективность, широту охвата и точность тестирования, ведь повторяющиеся задачи в условиях ручного подхода подвергаются риску человеческих ошибок. Автоматизация не превосходит и не заменяет ручное тестирование, но дополняет его. Подобно управлению тестированием автоматизация также нуждается в разработке стратегии с надлежащим планированием, мониторингом и контролем. Автоматизаторы не только изучают новые способы автоматизации, но и принимают много продуманных решений. Автоматизация при правильной реализации может стать преимуществом для команды, проекта и организации.
Онлайн-тренинг, 2 недели, 4 занятия, начало: 19 марта
Если в системе что-то сломалось, разработчик всегда просит логи. Он видит в них то, что пропускает тестировщик черного ящика. Но почему бы тестировщику самому этого не увидеть? И в наши дни доступ к логам обычно есть, и очень круто, когда тестировщик умеет их читать. Чему мы и будем учиться на курсе — доставать из логов информацию.
За 2 недели вы узнаете о логах все, что вам нужно знать: что это такое, как они выглядят, как их читать, какие улучшения просить. Где искать логи на сервере и на клиенте (web, mobile), чем они отличаются. Зачем тестировщику логи окружения и как выглядит хороший лог автотестов. Все обсудим и пощупаем на практике, чтобы потом сразу начать применять знания в работе.
Кажется (благодаря рекламной политике Youtube), что каждый раз, когда мне хочется посмотреть клип, я должен насладиться какой-нибудь жуткой рекламой вроде «Привет… сейчас я открою вам секрет, как изменить свою жизнь за пять простых шагов». Я терпеть не могу грубую рекламу «Я выучил магический секрет, как стать миллионером, и поделюсь им с сотней людей на своем семинаре… по 10 000 долларов с человека». Надо признать, в душе я слегка корыстен, и в какой-то момент я подумал «хм, а ведь я могу сделать что-то похожее для тестирования». Проблема в том, что бассейн тестирования и так полон акул, и прибавление в семействе никак не помогает сообществу.
Почти ежедневно я беседовал с молодой тестировщицей Гуной, которая хотела стать самым лучшим тестером, которым только возможно быть. Она была потрясающим зарядом энергии и уже проявляла активность в сообществе, будучи в трудном положении – единственным тестировщиком на проекте. Я очень радуюсь, когда многие подобные тестировщики присоединяются к Твиттеру и ищут тест-сообщество там. Разговаривая с Гуной, я подумал, а как стать самым лучшим тестировщиком? Я набрасывал идеи примерно неделю, и список оказался удивительно простым – иногда мне казалось, что стоит добавить что-нибудь еще, но оказывалось, что это уже покрыто каким-то имеющимся пунктом списка.
Вот мои четыре шага к тому, чтобы стать самым лучшим тестировщиком. Они довольно просты – однако сложны в том плане, что не сводятся к «вычеркни это как сделанное и переведи мозг в режим ожидания». Это ценности, которыми нужно дышать ежедневно – они не гарантируют, что вы станете потрясающим тестировщиком прямо сейчас, но обещают, что вы будете тестировать лучше, чем вчера.
10-11 марта, в Минске, сообщество COMAQA.BY проведет большую конференцию выходного дня COMAQASpring 2018, посвященную вопросам ручного и автоматизированного тестирования, DevOps, разработки в контексте автоматизации и менеджмента в тестировании.
11 марта в рамках конференции организаторы подготовили для Вас новый формат участия – день, полностью посвященный мастер-классам.
Каждый мастер-класс проходит в небольшой группе – до 20 участников. Каждый мастер-класс это практика. В процессе Вы вместе со спикером детально прорабатываете тему мастер-класса, разбираете интересующие Вас вопросы и ситуации, возникающие конкретно в Вашем проекте.
На COMAQA Spring 2018 вас ожидают 3 потока мастер-классов:
1 поток: два мастер-класса, направленных на развитие soft-skills в контексте тестирования и не только:
"Mindset Tools approach to testing" от Vivien Ibironke Ibiyemi. Вы будете поражены тем, использование подхода «Mindset tools» может «катапультировать» ваше мышление и направить вас на непрерывный рост, независимо от вашей роли в проекте;
"Деловые переговоры в голливудском стиле" от Романа Сороки в формате деловой игры, где Вы наглядно увидите, из каких этапов состоят переговоры, и научитесь заключать контракты в ролях заказчика и подрядчика.
Обычно на должность руководителя проектов в IT-компании требуются люди с опытом от 1 года. Поэтому часто неопытные менеджеры устраиваются на работу аналитиками, тестировщиками, иногда даже разработчиками.
Если хорошо себя проявить, то со временем вам будут доверять больше управленческих задач. При этом не всегда получается отказаться от старых обязанностей. Приходится совмещать две роли на проекте. Так и я, имея опыт в тестировании и аналитике, дополнительно стала получать задачи руководителя проекта. Со временем я полностью перешла в управление проектами.
В этой статье я делюсь наблюдениями и выводами. Как в одном человеке конфликтуют привычки тестировщика и обязанности руководителя проекта? С какими проблемами приходится сталкиваться? Какую пользу можно извлечь при таком переходе? Если хотите получить ответы на эти вопросы, добро пожаловать под кат.
Работа с тестовыми инструментами обычно начинается с немедленной яростной обратной связи. Со временем программисты добавляют новые фичи, тестировщики – новые тесты, и тесты занимают все больше и больше времени. Чтобы чем-то себя занять, технический персонал работает над чем-нибудь еще, ожидая, пока тесты закончат работу.
Рано или поздно тест-результаты становятся такими медленными, что уже неактуальны – а даже если актуальны, нуждаются в археологах, чтобы разобраться, что в них вообще происходит. Все это можно предотвратить быстрой обратной связью.
Мои советы нацелены на ускорение петли обратной связи: тестируйте меньше, распределяя тесты во времени и пространстве. Для этого придется запускать расширенный набор инструментов, коммерческих или открытых, предоставляющих большее покрытие при более медленном темпе и быстрейшими, наиболее важными тестами, работающими непрерывно.
10-11 марта, в Минске, сообщество COMAQA.BY проведет большую конференцию выходного дня COMAQASpring 2018, посвященную вопросам ручного и автоматизированного тестирования, DevOps, разработки в контексте автоматизации и менеджмента в тестировании.
Спикеры из ведущих IT-компаний Швеции, Германии, Финляндии, России и Беларуси соберутся вместе, чтобы рассказать о своем опыте в тестировании и управлении, поделиться личными практическими “секретами” и наработками.
Организаторы подготовили для вас:
★ 16 докладов в первый день конференции от профессионалов-практиков;
★ видеотрансляцию докладов для тех, кто захочет присоединиться удаленно;
★ 3 потока мастер-классов во второй день конференции;
★ Обед, кофе-паузы и after-party для неформального общения со спикерами и нетворкинга;
★ Сувениры от организаторов и партнеров конференции.
Полную программу и билеты вы найдете на официальном сайте конференции: conference.comaqa.by
Тестировщики! Когда мы обсуждаем ручное тестирование, мы помогаем “тонуть кораблю”.
Это сильное заявление, но оно сформировано на основании долгих лет наблюдения за людьми, которые говорят на тему тестирования неосторожно. Опасность заключается в том, что людей, не специализирующихся на тестировании (и даже некоторых из тех, кто специализируется) вводит в заблуждение формулировка, что какой-то вид тестирования называется “ручным”, а какой-то - “автоматизированным”. Они не понимают, что разработка ПО и тестирование в рамках разработки можно сравнить с тонкой дизайнерской работой, а не фабричным выпуском продукции. Эти люди ослеплены скоростью и надежностью автоматизации, внедренной на производстве. Очень скоро они зацикливаются на идее, что тестирование может быть автоматизировано. Ручное тестирование - плохо, автоматизация - хорошо.
Впоследствии тестировщики, обладающие хорошими способностями к критическому мышлению, и навыками выявления проблем, испытывают сложности в поиске работы. Вместо них нанимают тестировщиков с весьма скромными навыками программирования и не внушающими доверия аналитическими способностями, которые месяцами пишут программы, суть которых сводится к нажатию кнопок компьютером. Целью становится отладка автоматизированных проверок, а не выявление проблем функционала, который важен для пользователя. Сложности, связанные с тем, чтобы “заставить” компьютер взаимодействовать с продуктом, отнимают время, которое могло быть потрачено на изучение продукта и наблюдение за тем, как ведет себя система. В результате имеем продукт, который мог быть тщательно или не очень протестирован, но в котором присутствуют дефекты, снижающие или даже напрочь уничтожающие его ценность.
