В мае вышла новая версия JMeter 3.0. Концептуальных изменений в ней нет, однако поменялся интерфейс, изменились названия некоторых элементов, а также появились новые элементы.
Помимо адаптации к JMeter 3.0, программа обновленного тренинга претерпела и другие изменения. Учтены замечания в отзывах участников, больше времени мы уделили моментам, которые казались ученикам сложными, максимально уплотнив материал лекций. Лекции разбиты на небольшие фрагменты до 20 минут для удобства просмотра и навигации.
Дата начала работы первой группы – 29 июля.
Поэтому если Вы планировали начать осваивать тестирование производительности, не откладывайте это в долгий ящик и запишитесь в текущую группу, чтобы получить новую версию тренинга по старой цене.
В обеспечении качества различают верификацию и валидацию. Верификация отвечает на вопрос, правильно ли мы создаем продукт, а валидация – на вопрос, а то ли мы вообще создаем, что нужно. Некоторые люди проводят водораздел между обеспечением качества и тестированием, исходя именно из этих определений.
С моей точки зрения, использование терминов "верификация" и "валидация" может привести к ложным дихотомиям. Для меня тестирование – это деятельность, связанная с дизайном, и поэтому покрывает довольно широкую область. Я верю, что тесты могут стать неким "общим языком". Я верю, что тесты могут напрямую кодировать спецификации и требования. И я верю, что тесты – это источник знаний об области или продукте. Слишком большой упор на разницу между верификацией и валидацией – это неэффективный и не результативный способ понять, как именно тестирование дополняет обеспечение качества.
С моей точки зрения, неспособность воспринимать тестирование и обеспечение качества, как два различных, дополняющих друг друга процесса – это восприятие, которому явно не хватает некоторого изящества.
На самом деле я согласен, что различия между верификацией и валидацией вполне оправданы. В конце концов, эффективность – это способность делать что-то правильно. Результативность, с другой стороны – это способность выдавать правильный результат. Эффективность сфокусирована на процессе и нацелена на доведение его до конца, а результативность – на продукте (то есть, собственно, на результате этого процесса). Можно сказать и так: эффективность концентрируется в первую очередь на том, чтобы избежать ошибок, а результативность – на успехе вне зависимости от количества промахов, допущенных по пути.
Однако мне кажется, что есть способ различать эффективность и результативность, который куда лучше понимания разницы между верификацией и валидацией. Ведь тестирование прямо-таки требует гибкости и инноваций.
После очередной уборки на сервере выяснили, что у нас осталось несколько неопубликованных докладов со старых онланй-конференций. Те доклады, информация в которых еще не устарела постараемся выложить в ближайшее время.
Представляем доклад Глеба Рыбалко.
Популярность техник тестирования основанных на опыте набирает популярность с каждым годом. Скорее всего, Вы уже не найдете ни одного профессионала по тестированию и обеспечению качества, которому были бы не знакомы термины exploratory & ad hoc. Об этих видах тестирования пишутся книжки. Популярность этого направления уже дошла до того, что такое тестирование было включено в некоторые американские стандарты и предписания. Естественным образом такая ситуация отражается и на клиентах. Все чаще и чаще клиент сам приходит к Вам с инициативой внедрения исследовательского или ad hoc тестирования. И первое, что в таком случае хочется ответить это: «Да, да, конечно. Это нам поможет. Это же последние веяния. Давайте попробуем… «Но всегда ли исследовательское тестирование помогает?
Я дам несколько практических советов, которые помогут использовать данный вид тестирования на практике. Мы поговорим о следующих вещах:
Как определить цели данного вида тестирования на проекте
Как идентифицировать нужных людей, для команды «исследователей»
Какие тестовые артефакты действительно помогают в исследовательском тестировании
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). После завершения врезки вы отправляетесь выполнять полученное задание.
Как и в других ММО, вам придется сражаться с группами персонажей ("мобами") и в случае победы вы сможете подобрать "лут", который может содержать экипировку (броню, ботинки, перчатки, шлемы, и так далее) и другие ценности. Некоторые из них – например, броню и оружие – персонаж может надеть на себя. К тому же у вашего персонажа есть компаньон – контролируемый игрой соратник, который сопровождает вас в ваших приключениях и помогает в боях. Компаньона тоже можно одевать, передавая ему найденные на поле боя вещи.
Переформулирую, пожалуй – зачастую автоматизация кажется очень простой штукой.
Когда вы смотрите на первое демо, или запускаете свой первый автотест, вы чувствуете себя волшебником . Ого-го! Это так круто! Хотел бы я уметь печатать так быстро!
Но хорошая автоматизация сильно отличается от этого вашего первого запуска.
Представьте, что вы гуляете по огороду и видите на ветке спелый фрукт, призывно манящий вас. Вы срываете его, думая, что это же так круто – одно простое движение, и в вашей руке что-то красивое и вкусное.
Однако хорошая автоматизация – это скорее организация этого огорода, позволяющего прокормить небольшой городок.
Канал Youtube Wrike
