27-28 марта прошла конференция разработчиков, посвященная вопросам разработки, управления проектами и тестирования.
Публикуем подборку докладов, которые пригодятся тестировщикам.
Доклады на русском языке:
“Badoo Development. Развитие процессов тестирования в Badoo за три года” – доклад Ильи Кудинова о проблемах в тестировании в Badoo и о том, как эти проблемы решать.
“Digital Security. Расширяем инструментарий — тулзы пентестеров в разработке и тестировании” – доклад Сергея Белова о дополнении и улучшении инструментов, используемых тестировщиками.
“2ГИС. Автоматизация тестовой инфраструктуры в 2ГИС” – доклад Антона Галицына о проблемах с инфраструктурой, о внедрении “OpenStack”, о достоверности результатов автотестов.
“Borland. Как тестировать приложение, предназначенное для тестирования приложений?” – Инструменты для создания автотестов и инструменты для нагрузочного тестирования сами являются достаточно сложными программами, которые требуют тщательного тестирования. Тимур Шевляков рассказывает о том, как они тестируют инструмент нагрузочного тестирования SilkPerformer, какие нестандартные задачи при этом возникают и как они их решают.
Доклады на английском языке:
“The Story of Appium” – доклад Dan Cuellar, в котором автор делится своим опытом тестирования с использованием фреймворка “Appium”.
“Spotify Model Based Testing” – доклад Kristian Karl, в котором автор расскажет о плюсах и минусах “Тестирования на основе модели”.
“HPE Software Deliver fast, on time and with high quality” – доклад Karim Fanadka, в котором автор рассказывает о внедрении новых технологий и методов для упрощения и совершенствования своей работы.
Новый онлайн-тренинг Ольги Киселевой, 1 месяц занятий, 3,5 часа теории + много практики + постоянные консультации тренера в скайп-чате
с 11 июля до 8 августа
Эта херня работает некорректно
Знакомое описание бага?
В разговоре такая фраза уместна, в баг-трекере — нет. Через месяц все забудут, что это за херня была, и как именно она не работала.
На курсе мы будем учиться писать баг-репорты так, чтобы их понял разработчик, вернувшийся после лоботомии. А при виде слов «некорректно», «неправильно»... к концу курса должен начать дергаться глаз.
Зачем. Описывать баг-репорты так, чтобы их понял даже вернувшийся после лоботомии разработчик.
Проблемы оформления задач:
— Нашел, завел, она не воспроизводится.
— Разработчик говорит "не воспроизводится".Подходишь, показываешь — воспроизвелось!
— Коллеги дергают с вопросами "А что ты хочешь видеть в результате? Что такое корректная работа?"
Если оформить задачу плохо — ее не исправят. Если не найти «корень зла», ее не смогут повторить и не будут исправлять. Мы будем учиться писать баг-репорты доступно и понятно.
К концу курса у вас должен дергаться глаз каждый раз при виде слова "корректно" в описании бага.
Тестовый проект
Мы создали отдельную систему и внедрили туда ошибки, интересные с точки зрения локализации, описания или поиска. Каждый финт ушами в лекции можно потыкать вживую. При этом ошибки внедрены реальные, просто собранные с других проектов.
Какие инструменты облачного тестинга используют в Яндексе? Как устроено тестирование в Badoo? Что представляет собой система автоматизированного frontend-тестирования в Wrike?
Пару недель назад Wrike Tech club собрал около 150 специалистов по тестированию, чтобы обсудить в питерском офисе компании насущные, вечные и, на первый взгляд, почти неразрешимые проблемы QA в больших (и не очень) проектах.
Ниже видео и презентациями со встречи:
Илья Кудинов (Badoo), «Развитие процессов тестирования в Badoo за три года или как мы думали, что всё хорошо, а оказалось, что можно лучше»
Wrike QA Automated Team «Как устроено автоматическое frontend-тестирование на wrike.com»
После очередной уборки на сервере выяснили, что у нас осталось несколько неопубликованных докладов со старых онланй-конференций. Те доклады, информация в которых еще не устарела постараемся выложить в ближайшее время.
Сегодня представляем доклад Станислав Косарева
Каждый менеджер должен уметь делегировать задачи, иначе он не менеджер. Остается только 1 вопрос: как или каким образом доверять своим подчиненным? Откуда уверенность, что все сделано правильно, откуда стойкое ощущение того, что все хорошо? Наверное, потому, что ты, как менеджер, постоянно перепроверяешь то, что делают твои ребята. Класс! Тогда другой вопрос. Каким образом ты модернизируешь свою работу? Если перепроверяешь – то тратишь время, а значит, не успеваешь даже подумать о чем-то новом, о том, что может перевернуть твою работу с ног на голову…
В своём докладе я расскажу о том, как делегировать задачи по тестированию без перепроверок, экономя своё время и не переживая за результаты тестирования.
Как я уже говорил, тестировать игры трудно, и я также упоминал, что создал игру для собеседования тестировщиков. Думаете, я много внимания уделяю умению мыслить как игрок? Именно так. Это связано с тем, что, исходя из моего опыта, люди, мыслящие как игроки – это самые лучшие тестировщики. Об этом я и хочу поговорить.
Начну с того, что я не имею в виду игроков как таковых – я говорю о тех, кто, играя в игры, размышляет о них не только на уровне базовой механики.
В общем-то, тестирование игр не особо отличается по сложности от тестирования других приложений. Сложности иногда возникают при попытке определить, как протестировать их наилучшим образом, учитывая типичное для игр богатство интерфейсов и способов взаимодействия. Что еще тяжелее, так это локализация специфических (и довольно странных) багов, с которыми в них сталкиваешься. Недавно я обнаружил именно такой баг, тестируя популярную игру.
В свободное время я иногда работаю на игровые компании. Недавно я столкнулся с довольно-таки любопытным багом, тестируя игру Star Wars: The Old Republic. Баг я нашел чисто случайно – я не искал его прицельно, и даже не пытался найти что-то на него похожее. Когда баг был найден, было абсолютно неясно, что же конкретно тут происходит. Правда, знакомая история? Однако тут были свои нюансы.
Если вы не в курсе, то Star Wars: The Old Republic (SWTOR) – это массовая многопользовательская онлайн-игра (MMO), в которой вы создаете себе персонажа и исследуете вселенную Звездных Войн, выполняя квесты. Квесты, как правило, выглядят как видео-врезки, в течение которых ваш персонаж болтает с нейтральными персонажами (NPC). После завершения врезки вы отправляетесь выполнять полученное задание.
Как и в других ММО, вам придется сражаться с группами персонажей ("мобами") и в случае победы вы сможете подобрать "лут", который может содержать экипировку (броню, ботинки, перчатки, шлемы, и так далее) и другие ценности. Некоторые из них – например, броню и оружие – персонаж может надеть на себя. К тому же у вашего персонажа есть компаньон – контролируемый игрой соратник, который сопровождает вас в ваших приключениях и помогает в боях. Компаньона тоже можно одевать, передавая ему найденные на поле боя вещи.
Переформулирую, пожалуй – зачастую автоматизация кажется очень простой штукой.
Когда вы смотрите на первое демо, или запускаете свой первый автотест, вы чувствуете себя волшебником . Ого-го! Это так круто! Хотел бы я уметь печатать так быстро!
Но хорошая автоматизация сильно отличается от этого вашего первого запуска.
Представьте, что вы гуляете по огороду и видите на ветке спелый фрукт, призывно манящий вас. Вы срываете его, думая, что это же так круто – одно простое движение, и в вашей руке что-то красивое и вкусное.
Однако хорошая автоматизация – это скорее организация этого огорода, позволяющего прокормить небольшой городок.
Примечание переводчика: автор статьи, по сути, описывает высокоуровневые чек-листы, и на сердце руку положа, в системах управления кейсами вроде TestRail они обычно так и выглядят. При этом, говоря о достоинствах подробных кейсов, он как-то совершенно упускает регрессионное тестирование. А ведь именно его часто дают новичкам, именно по нему новые люди знакомятся с продуктом, и это довольно сложно исполнить, когда кейс звучит как "пойди туда, не знаю куда" для свежего взгляда. Передаю слово автору.
В ручном тестировании очень важно контролировать, что уже проверено, а что еще нет.
Нужно отслеживать, как именно мы тестируем, и быть в состоянии передать эту информацию команде, а то, как мы тестируем, демонстрируют наши тест-кейсы.
Я видел разные форматы кейсов:
Общие описания, как должно работать,
Пошаговые инструкции,
Ad-hoc тесты без инструкций.
Аргументация у этих подходов тоже различается:
Концентрироваться надо на функциональности, а не на специфических шагах тестирования.
Тесты должны быть просты и понятны даже уборщице Маше.
Исследовательское тестирование лучше всего находит баги, и не надо ограничивать себя тест-кейсами.
Три этих подхода различаются уровнями детализированности. Насколько детальными должны быть наши ручные кейсы?
07 июня в штаб-квартире «Лаборатории Касперского» на Водном Стадионе, пройдет первая из серии встреч CoLaboratory, посвященная тестированию. На этой встрече будет обсуждаться тестирование приложений на мобильных платформах. Особенно интересно данное мероприятие будет тем, кто по работе ежедневно сталкивается с ручным тестированием и тестированием на мобильных платформах.
Программа мероприятия:
13:00 Открытие регистрации участников
13:45 Открытие конференции, приветственное слово, Павел Романов
14:00 Специфика тестирования мобильных приложений, Анна Карпенко
15:00 Эволюция средств мобильного тестирования в ЛК, Иван Цепелев
16:00 Перерыв
17:00 Device specific проблемы устройств под Android, Дмитрий Мячин
18:00 Про in-product marketing (IPM), Дмитрий Бондаренко
19:00 Exploratory testing, Никита Воронов
Описание докладов:
Специфика тестирования мобильных приложений, Анна Карпенко
— В докладе я расскажу об особенностях тестирования мобильных приложений, об их отличиях и нюансах по сравнению с десктопными и веб-приложениями, а также об общих сценариях. В докладе будут затронуты функциональные, в основном негативные сценарии, необходимые при проверке любого мобильного приложения.
Эволюция средств мобильного тестирования в ЛК, Иван Цепелев
— Начнём с истории развития одного продукта KIS, еще от времен KMS до наших дней. Потом будет переход к основе: обзор имеющихся на данный момент приложений Лаборатории для различных мобильных платформ. Далее перейдём к частному примеру использования технологий логирования на примере Android. Немного примеров об использовании фильтров и вопросов о том, для кого заводятся баги. Например: баг который поймет только разработчик – плохо или хорошо?
Device specific проблемы устройств под Android, Дмитрий Мячин
– В своём докладе я расскажу о проблемах, которые могут возникать на конкретных версиях Android, даже на конкретных минорных обновлениях. О проблемах, характерных для конкретных прошивок конкретных моделей устройств. Постараюсь рассказать о подводных камнях, с которыми столкнулись мы сами и будет сталкиваться каждый, кто начнёт разработку и тестирование тех технологий, которыми уже давно занимаемся мы. Потому что проблемы могут встречаться в совершенно неожиданных местах.
Про in-product marketing (IPM), Дмитрий Бондаренко
— Доклад посвящен тестированию маркетингового функционала новостей на примере IPM (In-Product Marketing). Цель доклада – рассказать о проблемах, возникших при тестировании этого функционала, и способах их решения. В докладе будут затронуты наиболее актуальные проблемы, которые могут возникнуть при тестировании функционала, состоящего из множества частей.
Exploratory testing, Никита Воронов
В чем отличие валидации от верификации? Чем риск отличается от бага и как построить risk-based testing? Почему тестирование «вне команды» приносит свои плоды? Почему устройств всегда не хватает? Я постараюсь ответить на эти вопросы и не только.
ЗНАЕТЕ ЛИ ВЫ, что Аплана в числе первых компаний в России стала предоставлять услуги заказного тестирования?
На сегодняшний день Аплана – одна из наиболее быстрорастущих технологических компаний Европы. Мы входим в тройку лидеров на рынке аутсорсингов услуг в сфере тестирования и в связи с расширением бизнеса ищем новые таланты.
Если ты только закончил ВУЗ и интересуешься карьерой в тестировании, то Аплана – выбор для тебя!
Для выпускников технических ВУЗов с базовыми знаниями в программировании наша компания предлагает пройти специализированные курсы, которые позволят познакомиться с нагрузочным тестированием и автоматизацией. После успешно сданных экзаменов ты сможешь начать работать у нас в качестве стажера с возможностью уже через 3 месяца претендовать на должность специалиста.
ПОЧЕМУ МЫ?
Мы работаем с крупными Заказчиками, поэтому задачи,которые стоят перед нашими сотрудниками, позволяют им быстро и эффективно развиваться в сфере тестирования.
Сейчас у нас открыты вакансии как для новичков, так и экспертов в тестировании. Актуальные вакансии – на нашем сайте.
В рамках компании функционирует Корпоративный Университет Аплана.
Система внутренних курсов позволяет новичкам быстро включаться в новые интересные задачи и на экспертном уровне разбираться в самых сложных направлениях тестирования.
Мы делаем все для того, чтобы нашим сотрудникам было интересно работать.
Регулярные корпоративные мероприятия сплачивают команду и позволяют в интерактивном режиме обмениваться знаниями и опытом.
Мы гарантируем:
быстрый профессиональный рост
стабильный заработок
дружный коллектив
Свои резюме присылайте на ящик
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
с указанием интересующей вакансии в теме письма.
Канал Youtube Wrike
07 июня в штаб-квартире «Лаборатории Касперского» на Водном Стадионе, пройдет первая из серии встреч CoLaboratory, посвященная тестированию. На этой встрече будет обсуждаться тестирование приложений на мобильных платформах. Особенно интересно данное мероприятие будет тем, кто по работе ежедневно сталкивается с ручным тестированием и тестированием на мобильных платформах.