Код тестов должен разрабатываться согласно таким же высоким стандартам, как и код продукта, но про это зачастую забывают. Это серьезно меня беспокоит, и стоит значительных временных и финансовых затрат благодаря своим последствиям. У меня много вопросов к плохому коду автотестов, и сейчас вы узнаете про это все!
Копипаста
Дупликация кода – это его рак. Особенно он свирепствует в тест-автоматизации, потому что шаги тестов зачастую повторяются. Но это не причина дублировать код! Используйте лучшие практики при создании кода, или готовьтесь к тому, что я забракую ваш код на код-ревью!
Жесткое кодирование конфигурационных данных
Автотесты должны быть способны запускаться в любом окружении без проблем. Не кодируйте намертво ссылки, логины, пароли и другие специфичные для конфигурации штуки! Считывайте их как ввод или файлы конфигурации. Нет ничего более раздражающего, чем переключить окружения и обнаружить – сюрприз! – что тесты не запускаются, хотя все значения в нем верны.
Тестировщик всегда работает в условиях нехватки времени: проверок много, а времени на них - мало. В такой ситуации важно повышать свою эффективность, используя различные вспомогательные инструменты. Хорошее знание инструментария тестировщика помогает тестировать быстро и внимательно. К сожалению, времени на изучение этих инструментов обычно не хватает - ведь платят нам совсем не за это. Чтобы помочь вам работать эффективнее, мы выбрали несколько наиболее популярных инструментов, и сделали по ним небольшие курсы.
Первый из них посвящен командной оболочке Bash, которая есть во всех популярных unix-системах. С ее помощью можно создавать, искать и менять файлы, отслеживать процессы, логиниться на удаленные машины и делать еще сотни задач, с которыми тестировщик сталкивается каждый день.
На этом курсе вы научитесь:
Работать с файлами и папками;
Искать внутри файлов, директорий и дерева процессов;
Выделять и обрабатывать запущенные в системе программы;
Записывать любую информацию в файлы;
Настраивать удобную и информативную консоль для работы.
Другой наш курс посвящен не менее популярной утилите - системе контроля версий Git.
С помощью этой системы можно хранить большое количество различных версий кода, разрабатывать новый функционал без помехи работающему, проверять только новые изменения. Современный тестировщик сталкивается с такими задачами каждый день — и он должен уметь работать с Git эффективно. Тем более, что Git используется буквально в каждой второй компании.
На этом курсе вы научитесь:
Получать информацию о репозитории;
Сравнивать файлы;
Переключаться между различными ветками;
Откатывать изменения;
Настраивать внешний вид консоли;
Решать конфликты кода;
Создавать аккаунты на самых популярных сервисах и работать с ними.
Наконец, третий курс будет наиболее полезен мобильным тестировщикам Android.
В нем мы рассматриваем утилиту Android Debug Bridge. Она дает тестировщику доступ к огромному количеству отладочных команд, с помощью которых можно получить и обработать значительно больше данных, чем вручную.
На этом курсе вы научитесь:
Запускать и тушить эмуляторы;
Подключаться к устройствам по USB и Wi-Fi;
Посылать на устройства и принимать любые данные;
Менять настройки девайса прямо с компьютера;
Запускать рандомизированное тестирование.
Все эти курсы достаточно короткие, и занимают всего две недели. В них вы не найдете описаний истории утилит и прочей воды - только конкретные команды, которые вы будете использовать в работе каждый день. Помимо теоретического материала мы добавили множество домашних заданий, чтобы вы могли закрепить свои знания и отработать их в условиях, приближенных к реальности.
В дальнейшем мы планируем создание подобных курсов и по другим темам, поэтому если у вас есть какие-то предложения – пишите нам!
А если вы хотите записаться на курс - переходите по ссылкам ниже, каждый из этих курсов стартует уже 5 сентября.
Хотите качественно подготовить продукт к релизу? В данной статье команда компании A1QA расскажет, как при грамотном планировании автоматизация тестирования поможет значительно сократить количество ручных проверок, ускорить процесс выхода на рынок и увеличить прибыль в меньший промежуток времени.
Нередко внедрение автоматизации начинается с поиска профессиональной команды, которая подбирает инструменты, разрабатывает решение. Это шаг верный, но не он должен быть первым.
С самого начала нужно решить, для чего же стоит внедрять автоматизацию и в каком объеме.
Грамотно разработанная стратегия позволит вам прочувствовать все преимущества автоматизации тестирования, а именно:
Получение более быстрых результатов тестирования;
Эффективное распределение ресурсов, направленных на тестирование;
Оптимизация затрат на обеспечение качества продукта и тестирование;
Безошибочное тестирование: качественный тест не допустит ошибки, которую может допустить человек;
Возможность более тесной интеграции тестирования с существующими процессами разработки продукта.
НА КАКИЕ ФАКТОРЫ ОБРАТИТЬ ВНИМАНИЕ ПРИ ПРИНЯТИИ РЕШЕНИЯ О ВНЕДРЕНИИ АВТОМАТИЗАЦИИ?
Бывает так, что пользоваться приложением нет сил. Оно не понимает вас, и с ним тяжело и неудобно работать (как в случае с небезызвестным сервисом для поиска кадров). Такое взаимодействие раздражает, и после 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.
Привет! Меня зовут Артём, и я занимаюсь автоматизацией тестирования. Антипаттерны в разработке — довольно популярная тема. Но ведь в тестировании тоже есть свои "плохие советы", и они довольно забавно пересекаются с разработкой. Недавно мне на глаза попалась ироничная статья про антипаттерны в тестировании. Вашему вниманию!
Мы стараемся как можно скорее доказать, что неправы, потому что только таким образом можем развиваться. Ричард Фейнман
Есть много способов усложнить жизнь командам автоматизации тестирования. Если вы разработчик или системный архитектор, и недолюбливаете кого-то из тестировщиков, то эта статья — для вас. Вы найдете в ней сокровенное знание, вдохновившись которым, вы научитесь делать интерфейс любого приложения практически непригодным для тестирования.
Ну, а если вы добрая душа и уважительно относитесь к чужому труду, то можете рассматривать эту статью как набор антипаттернов.
Пожалуй, ни в одной компании не найдется двух идентичных и взаимозаменяемых сотрудников. Одни превосходно разбираются в техниках тест-дизайна и ювелирно пишут тестовую документацию, другие — мастера различных видов и типов тестирования. В процессе работы над проектами сотрудники, как правило, дополняют друг друга, что благотворно сказывается на конечном продукте.
Вся наша работа по обеспечению качества выстроена на основе глубокой экспертизы прикладной области. Для одних команд — это страхование, для других — финансовые инструменты, интернет-банкинг или биржевая торговля, для третьих — широкий сектор государственных проектов.
Секрет в том, что тестировщики должны не просто разбираться в прикладной области, а должны знать ее специфику и наиболее типичные ошибки, более того – должны понимать своих пользователей.
Именно поэтому мы так много времени и сил уделяем обучению и погружению наших сотрудников.
Из-за ускорения разработки, задачи обеспечения качества на проектах становятся более разноплановыми и сложными. Ручное функциональное тестирование, автоматизированное интеграционное тестирование, нагрузочное тестирование и проверка на регресс - все эти виды тестирования обязательны и требуют особенных навыков, а главное - инструментальной поддержки.