Бывает так, что пользоваться приложением нет сил. Оно не понимает вас, и с ним тяжело и неудобно работать (как в случае с небезызвестным сервисом для поиска кадров). Такое взаимодействие раздражает, и после 5-10 минут мучений пользователь закрывает приложение и удаляет все его следы раз и навсегда. Впоследствии люди, опасаясь новых разочарований, стараются не использовать и прочие продукты данного разработчика, не открывают веб или мобильную версии сайта.
Восстановить доверие пользователей – самый тяжелый и неблагодарный труд. Тут понадобится немало хитростей: рассылки с извинениями, проведение рекламных акций и конкурсов, раздача подарков. Уже по краткому описанию становится понятно, насколько это затратное дело.
Во избежание подобного было придумано тестирование продуктов на удобство использования еще на стадии разработки прототипов. Некоторые с опаской смотрят на юзабилити, и совершенно напрасно. Такой монстр рынка, как Apple, уже давно получает профит от юзабилити тестирования. У этой компании даже есть отдельная единица в штате – антрополог, он помогает тестировщикам приблизиться к своей целевой аудитории. Результаты юзабилити тестирования этой компании налицо: по статистике продукты Apple остаются самыми продаваемыми и популярными.
Неделю назад мы рассказали про новый тренинг компании Лаборатория Качества «Первый Онлайн ИНститут Тестировщиков», который начинается уже 1 сентября.
Этот курс рассчитан на специалистов по тестированию, как начинающих, так и с опытом до 1-2 лет.
Посмотреть программу и описание курса можно здесь, а мы ответим на вопросы читателей, которые получили после первого анонса этого тренинга.
Чем этот курс отличается от всех остальных?
Да, большинство курсов начального уровня по тестированию содержит примерно одинаковый набор тем. Но обычно курс ведет один тренер. Он может не быть экспертом во всех областях тестирования, поэтому некоторые темы рассматривает очень поверхностно.
В нашем курсе задействовано 11 тренеров, за каждый модуль отвечает специалист в своей теме. Вашим обучением займутся практики, ежедневно решающие задачи, о которых они расскажут на занятиях.
Agile в целом заменил модель водопада в качестве «правильной» методологии разработки ПО. Это действительно хороший процесс, если он правильно поставлен, но люди все портят, когда неправильно к нему подходят. О, как мощно он может пойти наперекосяк. У меня много претензий к плохим практикам Agile, и сейчас вы все о них узнаете!
Нарушение правил
Agile очень похож на настольную игру «Монополия». Правила у нее длинные и сложные, но они нацелены на то, чтобы сделать игру эффективной. Однако по какой-то причине все настаивают на изобретение своих собственных правил для игры вместо того, чтобы следовать официальным инструкциям. К примеру, игроки не выставляют собственность на аукцион, перейдя на соответствующую клетку, и отказываются ее покупать, или строят дома, не достигнув монополии. В результате игра продолжается бесконечно и теряет свою привлекательность. Что касается Agile, каждая организация, видимо, стремится пойти своим особенным путем, и это практически всегда выходит им боком. Правила не предназначены для того, чтобы их нарушали. А если их нарушают, последствия не заставят себя ждать.
Из-за ускорения разработки, задачи обеспечения качества на проектах становятся более разноплановыми и сложными. Ручное функциональное тестирование, автоматизированное интеграционное тестирование, нагрузочное тестирование и проверка на регресс - все эти виды тестирования обязательны и требуют особенных навыков, а главное - инструментальной поддержки.
Традиционные баг-трекеры не решают всех этих задач, поэтому для любой команды стоит вопрос об использовании дополнительного инструментария. Например, такого который позволит создавать и обсуждать тестовую документацию, фиксировать результаты тестирования, объединять отчеты ручного и автоматизированного тестирования на одном дашборде, распределять работу между тестировщиками и сообщать разработчикам всю необходимую информацию - контекст для воспроизведения дефектов.
Исторически сложилось, что тестировщики используют бесплатные решения типа TestLink или платные Zephyr, TestRail. В случае с бесплатными, основной сложностью является установка, администрирование и низкое качество интерфейса. Желающих создавать и развивать продукты бесплатно в долгосрочной перспективе - почти нет. Поэтому часто такие продукты реализуют совсем минимум не очень удобной функциональности и годятся лишь для решения простых задач. Платные продукты не обладают этими слабостями, поскольку над ними работают продуктовые команды, работают ради пользователей. Однако, здесь наблюдается проблема другого рода. Например, Zephyr и TestRail рассчитаны на простые задачи и являются лишь дополнениями к баг-трекеру, причем интеграция требует настройки. Функциональность подобных продуктов представляется как полумеры, и не позволяют организовать эффективный тестировочный процесс.
Тестирование неразрывно связано с системными требованиями, с процессом выпуска релизов и сборок продукта. Требования постоянно меняются, поэтому нужно обновлять и тестовую документацию, поддерживать их в целостном состоянии. Эффективно эти задачи решаются только системами класса Application Lifecycle Management (ALM), которые традиционно производят только западные компании и продают очень дорого.
Российская разработка Devprom ALM уникальным образом объединяет лучшие стороны бесплатных продуктов и платных профессиональных инструментов уровня ALM. Базовая функциональность по управлению задачами команды по Scrum или Kanban предоставляется бесплатно и без ограничений, реализуя полноценный баг-трекер, совмещенный с базой знаний проекта. Дополнительный модуль тестирования органично развивает базовую функциональность и предоставляет возможности по тестированию уровня ALM-систем, по аналогии с такими продуктами как HP ALM, HP QC, IBM Rational, Microsoft TFS. При этом стоимость лицензии на одного тестировщика не велика и окупается многократно уже за несколько дней использования продукта.
Devprom ALM - это веб-приложение, в котором удобно и быстро создаются дефекты в результаты заполнения тестовых отчетов. Тестировщику не нужно в описании дефекта перечислять все шаги того, как он пришел к ошибке, поскольку все эти шаги уже описаны в тестовой документации, по которой выполняется тестирование. Дефект связан с конкретным тестовым отчетом и разработчик одним кликом сразу переходит в тот контекст тестирования, в котором тестировщиком была обнаружена ошибка в ПО. Весь процесс тестирования органично вписан в процесс разработки ПО, соответствующий стадии продукта или тонко настроенный под особенности вашей работы, будь то заказное тестирование, контроль качества при выпуске сложного продукта или работа в кроссфункциональной команде.
В отличие от продуктов, производимых партнерами Atlassian (таких как Zephyr), вы не оплачиваете лишних лицензий. Например, в вашей команде два тестировщика и 10 разработчиков. Функциональность управления задачами в проектах достается всем бесплатно, а купить нужно только 2 лицензии на модуль управления тестированием и не платить при этом за разработчиков, аналитиков или представителей заказчика - это очень выгодно!
Познакомиться подробнее с описанием возможностей Devprom ALM вы можете на сайте продукта: http://myalm.ru. Создайте свой экземпляр в нашем облаке и получите бесплатный 30-дневный оценочный период, чтобы лучше познакомиться с возможностями Devprom ALM. Наша команда бесплатно проводит демонстрацию возможностей системы - напишите нам запрос по адресу
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
и мы согласуем удобные дату и время проведения демо нашей платформы.
В докладе автор расскажет, как был организован запуск автоматических тестов (appium/javascript) в gitlab CI для нативного Android приложения на каждый Merge Request. Опишет, как можно встроить автотесты в существующий процесс сборки, как правильно настроить запуск тестов в docker image (тесты бегут в TestObject облаке), как произошла интеграция с клаудом и какие результаты это принесло. Tech stack: Gitlab CI, kubernetes, android, appium, javascript, testobject.
Привет! Меня зовут Артём, и я занимаюсь автоматизацией тестирования. Антипаттерны в разработке — довольно популярная тема. Но ведь в тестировании тоже есть свои "плохие советы", и они довольно забавно пересекаются с разработкой. Недавно мне на глаза попалась ироничная статья про антипаттерны в тестировании. Вашему вниманию!
Мы стараемся как можно скорее доказать, что неправы, потому что только таким образом можем развиваться. Ричард Фейнман
Есть много способов усложнить жизнь командам автоматизации тестирования. Если вы разработчик или системный архитектор, и недолюбливаете кого-то из тестировщиков, то эта статья — для вас. Вы найдете в ней сокровенное знание, вдохновившись которым, вы научитесь делать интерфейс любого приложения практически непригодным для тестирования.
Ну, а если вы добрая душа и уважительно относитесь к чужому труду, то можете рассматривать эту статью как набор антипаттернов.
Пожалуй, ни в одной компании не найдется двух идентичных и взаимозаменяемых сотрудников. Одни превосходно разбираются в техниках тест-дизайна и ювелирно пишут тестовую документацию, другие — мастера различных видов и типов тестирования. В процессе работы над проектами сотрудники, как правило, дополняют друг друга, что благотворно сказывается на конечном продукте.
Вся наша работа по обеспечению качества выстроена на основе глубокой экспертизы прикладной области. Для одних команд — это страхование, для других — финансовые инструменты, интернет-банкинг или биржевая торговля, для третьих — широкий сектор государственных проектов.
Секрет в том, что тестировщики должны не просто разбираться в прикладной области, а должны знать ее специфику и наиболее типичные ошибки, более того – должны понимать своих пользователей.
Именно поэтому мы так много времени и сил уделяем обучению и погружению наших сотрудников.
Такие термины, как тестирование производительности, нагрузочное и стресс-тестирование часто используются как синонимы. Однако замер скорости работы сервиса и измерение возможной нагрузки на него – это не одно и то же, а подтверждение способности сервиса справиться с нормальным уровнем нагрузки не означает, что он так же среагирует на очень высокую. Как же создавать высокоэффективные тесты производительности, не налепив распространенных ошибок?
Вначале определитесь, чего вы ожидаете от сервиса, и что именно вы хотите проверить. Ваше приложение – "заяц", обязанный максимально быстро отвечать на вопросы? А может, это "черепаха", которая выигрывает гонку благодаря постоянно поддерживаемой скорости?
В реальной жизни веб-сервисы имеют как качества зайца, так и качества черепахи, и эти качества должны быть сбалансированы. Они проверяются по-разному в зависимости от природы вашего теста. Без глубокого понимания сервиса, его применения пользователями, пользовательской базы и целей теста вы потратите много времени, гоняясь за несуществующими проблемами, в то время как реальные риски утекут у вас сквозь пальцы.
Начиная свой путь в отрасли тестирования, задаешься вопросами: с чего начать? как развиваться? какие знания необходимы для получения работы? как стать признанным специалистом в своей компании и востребованным на рынке труда? Компания "Лаборатория Качества" подготовила курс, который поможет ответить на все эти вопросы.
Программа создана для специалистов по тестированию, как совсем начинающих, так и с опытом до 1-2 лет.
Через 8 недель курса вы:
Будете хорошо ориентироваться в терминологии тестирования
Сможете успешно проводить тестирование (исследовательское и скриптовое)
Будете обладать ключевыми навыками тестирования интеграции (с использованием SoapUI) и баз данных (SQL)
Научитесь разрабатывать базовые автоматизированные тесты для функционального (Selenium) веб-тестирования
Сможете автоматизировать стандартные операции, такие как сравнение файлов, анализ логов, подготовка тестовых данных и т.д.
Ознакомитесь с особенностями тестирования веб-продуктов и мобильных приложений и требуемым для этого инструментарием
Сможете с пользой для проекта тестировать требования и другую пользовательскую документацию
Научитесь оптимальному баг-трекингу, форматам составления тестовых артефактов, ознакомитесь с самыми популярными инструментами ведения чек-листов, тест-кейсов и баг-трекинговыми системами
Внимание: спеццена на первый запуск курса!!!!
Особенности курса:
Максимальная практичность Мы учим только тому, что действительно необходимо в тестировании, и закрепляем навыки на конкретных домашних заданиях. Никаких тестирований карандашей - только такие задания, которые вам действительно пригодятся.
Экспертный состав За различные вебинары отвечают отдельные эксперты в своей теме. Таким образом, вашим обучением займутся только опытные практики, ежедневно решающие задачи, о которых расскажут на своих вебинарах. Никакой бесполезной теории - только то, что действительно необходимо грамотным тестировщикам.
Детальная обратная связь Если вы что-то не поняли, или некорректно выполнили ДЗ, или не согласны - тренер будет индивидуально работать с вами до успеха. Никаких "бросить в воду и ждать, пока научится плавать" - мы будем с вами до тех пор, пока вы не поплывёте.
Краткая программа курса и тренеры конкретных модулей
Введение в тестирование (Наталья Руколь) Баг-трекинг (Анастасия Смирнова) 5 техник исследовательского тестирования (Нина Агеева) Введение в проектирование тестов (Ирина Старцева) Тест-анализ и тестовая комбинаторика (Ирина Старцева) Тест-дизайн и документирование тестов (Анастасия Смирнова) Тестирование требований к программному обеспечению (Виктория Соковикова) SQL для тестировщика (Роман Буданов) Тестирование веб-продуктов (Анна Хворостьянова) Тестирование веб-сервисов (Артем Шмыга) Тестирование юзабилити (Виктория Соковикова) Основы тестирования мобильных приложений (Виктория Юркевич) Эмуляторы, симуляторы и фермы для мобильного тестирования (Виктория Юркевич) Автоматизация тестирования. Инструменты автоматизации (Александра Гудкина) Автоматизация тестирования. Создание автотестов (Александра Гудкина) Организация процесса тестирования (Наталья Руколь) Карьера и развитие (Елена Крестина)
При изучении любой дисциплины самое сложное/главное понять основы, базовые принципы, на пальцах, на школьных примерах, затем, на этот металлический каркас можно навесить тонны бетонной практики, получившийся железобетонный монолит станет гарантией практически не ограниченного технического роста специалиста. Звучит самоочевидно, не правда ли ..? И тем не менее, субъективный опыт автора в проведении собеседований, а это около ~500 специалистов из стран СНГ, Индии, США в Автоматизации тестирования и сопоставимые цифры в С \ С++ мире, говорит, что даже Senior разработчики в большинстве не понимают «физического смысла» ООП, не могут озвучить базовую формулировку одного из «столпов» - инкапсуляции, хотя знают как на 3 языках, 20 способами реализовать интерфейс, класс и объект, а вот вырасти дальше уже не могут, и вынужденно в течении 20 лет топчутся на месте. Вот это досадное карьерное недоразумение мы и постараемся исправить. IMHO тема будет интересна/полезна самому широкому кругу слушателей, от молодых специалистов в Ручном тестировании до Архитекторов в Автоматизации.
Из-за ускорения разработки, задачи обеспечения качества на проектах становятся более разноплановыми и сложными. Ручное функциональное тестирование, автоматизированное интеграционное тестирование, нагрузочное тестирование и проверка на регресс - все эти виды тестирования обязательны и требуют особенных навыков, а главное - инструментальной поддержки.
