Когда вы отчитываетесь о тестировании, используя метрики, это может привести к незапланированным последствиям. Какие метрики мы регулярно используем для отчетов, и какую информацию почерпнут из них заинтересованные лица? Давайте детально рассмотрим несколько реальных примеров.
95% тестов прошло, 1% упал, 4% не прогонялись
Метрики "прошло/упало" очень популярны в традиционных отчетах о прогрессе тестирования. Представьте на минутку, что вы продакт-оунер, и ваше слово – решающее в вопросе, выпускать ли продукт в релиз.
Четыре месяца назад мы запустили курс “Автоматизатор мобильных приложений” о том, как построить фреймворк тестирования мобильных приложений на Android и iOS с нуля без значительного опыта в мобильной автоматизации. На тот момент в нем было всего пять уроков. В них описывались создание и конфигурация фреймворка тестирования на JUnit и Appium, а также базовые моменты настройки окружения. Для начала этого объема было достаточно, но у курса был явно больший потенциал.
И действительно, он оказался востребованным, а в своих отзывах и личном общении ученики сообщили нам множество идей для развития. Поэтому мы стали расширять курс в соответствии с их запросами.
В первую очередь мы получили очень много просьб о создании урока по Continuous Integration, поэтому мы занялись им сразу же во время первого запуска. К концу курса мы создали урок об интеграции нашего фреймворка с Jenkins — популярным инструментом CI. Как оказалось, многим ученикам не хватало именно этих знаний для того, чтобы применить навыки тренинга в реальной жизни — и теперь они смогли их получить.
Затем мы поработали над слишком объемным уроком по iOS. Он был в полтора раза больше остальных уроков, а закрытость системы Apple добавила сложностей в конфигурации. Ученики тратили много времени на то, чтобы настроить фреймворк — и часто не успевали перейти к написанию кода. Поэтому мы разделили этот урок на два, чтобы дать ученикам больше времени на работу. В результате количество успешно сданных домашних работ выросло, и ученики остались довольны.
Многие спрашивали нас о тестировании Mobile Web — ведь зачастую у мобильного приложения есть и веб-версия. Мы сделали отдельный урок, в котором рассказываем, как подключить к нашему фреймворку Selenium WebDriver, как переключаться между ним и Appium, а также описываем некоторые специфические моменты работы с веб-приложениями на мобильных устройствах.
Наконец, очень много вопросов поступало от новичков, которые интересуются темой автоматизации мобильного тестирования. Изначально курс создавался для опытных автоматизаторов, ведь для написания фреймворка требуются специфические навыки. Но при более детальном рассмотрении выяснилось, что этот тренинг не требует значительных знаний в области автоматизации или программирования — достаточно объяснить несколько базовых концепций, чтобы ученики смогли ими руководствоваться. Поэтому мы выпустили специальный урок, где подробно рассматриваем все моменты, необходимые для работы с JUnit, Java и Appium. Теперь на курс могут записываться и люди без опыта автоматизации вовсе — что, конечно, значительно расширяет его аудиторию.
Как видите, мы постоянно ищем новые возможности для развития курса, и часто обращаемся за идеями к нашим ученикам.
Посмотреть программу курса “Автоматизатор мобильных приложений” и записаться на него можно по ссылке. Очередная улучшенная и расширенная по результатам отзывов версия курса стартует уже 31 октября.
Погуглите "как писать тест-план" – и вы увидите множество шаблонов, обязательных атрибутов и обучающих статей. Создать тест-план можно множеством способов, а учесть в нем надо множество факторов, и очень легко еще больше запутаться в вопросе. В итоге люди вставляют в тест-план информацию просто для того, чтобы максимально обезопаситься: ведь лучше включить ее туда, чем нет, не так ли? Она же может быть важна для кого-то правда же? Но когда план написан, ревью пройдено, он отредактирован, финализирован и отправлен заинтересованным лицам – зачастую оказывается, что практически никто его и не читал.
Очень раздражает, когда тратишь кучу времени на длинную подробную тест-документацию, которую в результате никто не читает и не использует. Проблема в том, что у менеджмента зачастую нет времени на чтение гигантских документов – менеджмент хочет знать только самое важное.
Джеймс Уиттакер писал о "Десятиминутном тест-плане" несколько лет назад, описывая задачу, которую он ставил перед своей командой. Цель задания состояла в том, чтобы добиться полезной тест-документации как можно быстрее. Давайте посмотрим на это с другой точки зрения, но с похожей целью. В этот раз минимизируем не время, а масштаб. Как же сократить тест-план до одной странички?
В нашем блоге, равно как и внутри компании, большую часть времени мы обсуждаем одну тему: тестирование и его организацию. Мы часто пишем, как применять те или иные подходы к анализу качества продукта, много времени уделяем автоматизации тестов, постоянно следим за различными конференциями — в общем, все время пытаемся понять, как улучшить нашу работу и принести больше пользы конечным пользователям. Нам интересно писать про эти задачи, а статистика посещений материалов показывает, что и читать их тоже бывает полезно.
Исходная ситуация: крупный клиент со сложным ПО, тестированием которого занимается команда в 20+ специалистов. Клиент хочет, чтобы каждый месяц мы отчитывались о состоянии его продукта и проделанной нами работе. В общем, стандартная для рынка ситуация. Но в какой-то момент заказчик решил изменить формат отчетности. Вместо одного свободного, нас попросили разбить его на сложные категории, позволяющие сразу восьми разным департаментам понять, какая работа, важная именно для них, была проделана за отчетный период. В итоге мы имеем не один отчет, а сразу восемь, на подготовку которых уходит от 25 до 40 часов. Так стандартная для рынка ситуация превратилась в ночной кошмар.
Наше решение: вспомнить, что автоматизировать можно не только тест-кейсы, но и бизнес-процессы. В июле отчет, на который обычно уходило несколько дней и, примерно, 100 кружек кофе для разъяренных менеджеров и тестировщиков, мы подготовили за 10 минут. И решили, что впредь на всех крупных проектах бизнес-процесс «клиент — тестирование — отчетность» должен быть автоматизирован. Хотите узнать, какой эффект оказывает отказ от бесконечных таблиц, справок, сводных табелей на процесс тестирования и отношения с клиентами? Тогда следуйте за нами. Но начнем мы с короткого рассказа-утопии…
Размышляя о новом наборе автотестов, вы наверняка начнете с вопроса, что именно вы собираетесь автоматизировать. Неважно, требует ли автоматизации ваш менеджер, или за нее боретесь вы – прежде чем выбирать инструмент, вам нужно разработать стратегию тестового покрытия.
На решение, что конкретно автоматизировать, влияет множество факторов. Если вы пытаетесь определить масштаб автоматизации изолированно, вы, возможно, наделаете ошибок. Ниже – ряд советов, которые помогут вам мыслить шире и вовлечь в такое обсуждение широкую аудиторию.
5-6 октября COMAQA при поддержке компании DPI.Solutions, EPAM Systems и сообщества CoreHard.by провело большую осеннюю конференцию.
19 приглашенных докладчиков из Германии, России, Украины и Беларуси поделились своими теоретическими знаниями, многолетней практикой, авторским подходом донесения информации до слушателя. 5 мастер- классов, 23 доклада и множество других образовательно-развлекательных активностей - рубрика “конференция в цифрах” :)
Мы решили продолжить традицию и один из двух дней конференции посвятить мастер-классам.
Участники в рамках мастер классов и workshop-ов могли получить/ систематизировать знания, закрепить навыки и получить ответы на интересующие вопросы, связанные с архитектурой автоматизации тестирования, быстрым стартом Web UI автоматизации и контролем качества на проекте.
Основная цель – обмен опытом и помощь в решении стратегических задач в тестировании. На конференции появляются ответы на вопросы, о которых вы никогда не задумываетесь в повседневной жизни.
Доклады – исключительно практические, «бери и делай», без воды и рекламы:
– Тестирование безопасности; – Тестирование конфигурации; – Тестирование блокчейна; – Инструменты, фреймворки и библиотеки для тестировщиков;
Спикеры конференции:
– Алексей Баранцев – консультант, тренер, главный редактор software-testing.ru, автор и редактор selenium2.ru и один из разработчиков Selenium WebDriver; – Rhian Lewis – эксперт по блокчейн-проектам и их тестированию; – Jim Holmes – владелец Guidepost Systems и Executive Consultant в Pillar Technology; – Виталий Фридман – фронтенд-гуру, создатель и главный редактор Smashing Magazine; – Артём Ерошенко (QametaSoftware) – известный эксперт по автоматизации тестирования и инструментам; – Алексей Лавренюк и другие эксперты по тестированию.
Все спикеры, подробности докладов и регистрация – на сайте конференциии.
Скидка 1000 рублей на персональные билеты по промокоду SoftwareTestingPromo.
Две недели назад на нашем форуме Василий Касимов инициировал опрос про зарплаты в области тестирования.
Всего суммарно в опросе участвовали более двух тысяч человек.
Ниже вы найдете зарплатные диаграммы по городам за 2018 и 2017 годы (обзор 2017 года можно посмотреть по ссылке). По горизонтали шкала зарплат, по вертикали количество проголосовавших, получающих зарплату в этом диапазоне. Цветом выделен опыт работы (расшифровка справа на картинке).
Мы отдельно собрали результаты по трем странам: Россия, Украина, Беларусь.
В отчете по России мы выделили отдельно статистику по Москве, Санкт-Петербургу и остальной части России.
В Украине отдельно выделили Киев, в Беларуси - Минск.
Совсем скоро стартует очередной запуск тренинга Первый Онлайн Институт Тестировщиков, который рассчитан на специалистов по тестированию, как начинающих, так и с опытом до 1-2 лет. Перед вами - один из эпизодов курса на тему JOIN занятия SQL для тестировщиков.
Буданов Роман, тренер ПОИНТ, автор вебинара "SQL для тестировщика": В эпизоде вебинара продемонстрирован SQL запрос к 3 таблицам.
На конкретном примере тренер разбирает составляющие запроса. JOIN запросы нужны, чтобы быстро находить интересующие вас тестовые данные (пользователей с необходимыми товарами в корзине/правами доступа/ФИО). Какой бы продукт вы не тестировали – будьте готовы к тому, что вся информация хранится в БД. Даже у вашей кофеварки, скорее всего, втайне от вас имеется своя база) Но в БД необходимые именно вам данные могут храниться сразу в нескольких таблицах. И очень удобно, здорово и полезно (для психического здоровья-в первую очередь!) уметь писать запросы на поиск данных по нескольким таблицам сразу.
