Философия разработки через реализацию поведения ставит во главу угла автоматизацию: спеки поведения должна превратиться в автоматизированные тесты. Однако BDD вполне может включать в себя и ручное тестирование. У ручного тестирования есть свое место и свои задачи, даже в BDD. Помните, поведенческие сценарии – это в первую очередь поведенческие спецификации, и их ценность выходит за рамки тестирования/автоматизации. Любой сценарий можно прогнать как ручной тест. Следовательно, встают вопросы, в каких случаях пользоваться ручным подходом, и как с ним управляться.
Appium - популярный инструмент для автоматизации мобильных приложений. Его достаточно просто установить и запустить. Но часто у пользователей возникают проблемы с запуском приложения через графический интерфейс Appium, ведь надо правильно установить все необходимые capabilities для приложения, а их список - огромен.
В этом видео показывается, как можно при помощи ADB достать данные из приложения и запустить его на эмуляторе.
Код-ревью очень важное явление в процессе разработки ПО. Ставшее популярным, благодаря сообществу разработчиков ПО с открытым исходным кодом, оно сейчас является стандартом для любой команды девелоперов. Если оно выполняется правильно, то польза заключается не только в уменьшении количества багов и лучшем качестве кода, но и в обучающем эффекте для программиста.
И хотя код-ревью и запросы на включение кода (pull requests) хорошо известны разработчикам, эти понятия все еще остаются не до конца понятны тестировщикам. В большинстве scrum команд, в которых мне приходилось работать, инженеры-тестировщики по умолчанию не принимали участия в процессе просмотра запросов на изменение кода. Самое время изменить подобное мышление тестировщиков (и команд!). В этой статье я бы хотел рассмотреть код-ревью с позиции тестировщика и обозначить его преимущества для тестировщиков и scrum команд.
Наблюдать, как некоторые тестировщики сомневаются в себе, практически вызывает боль. Двое из каждого десятка сомневаются, если быть точным.
Я преподавал воркшопы нескольким сотням тестировщиков только в этом году. По какой-то причине эти 20% тестировщиков не находят багов вообще в течение первой двадцатиминутной тестовой сессии. А это обычно сессия, которая проводится на крайне забагованном приложении, специально выбранном для поиска багов.
Основная идея чемпионата - соревнование по поиску дефектов в программном обеспечении. В этом соревновании побеждает тот, кто за час сможет найти больше критичных багов, а так же знает тест - дизайн и обладает практическими навыками поиска неисправностей.
Тестовое приложение делаем специально для чемпионата, в нем будут спрятаны заранее придуманные баги, которые вам предстоит найти :)
Участвуй, прокачай свои навыки и получи шанс выиграть крутые призы! Победитель заберет самый крутой шлем виртуальной реальности HTC VIVE! (А так же будут футболки и памятные статуэтки/медальки - но это не точно )) )
Тестирование миграции данных – неклассическая задача инженеров по тестированию ПО, но с повсеместным распространением «больших данных» она встречается все чаще.
В данной статье команда A1QA расскажет на примере реального проекта, как подойти к тестированию миграции данных, какие подводные камни могут встретиться на пути, как оптимизировать выполнение проверок и завершить тестирование не просто в срок, а даже раньше.
Итак, начнем.
Миграция данных – перенос данных на новый ресурс/окружение.
Казалось бы, что может быть проще, чем перенести данные из системы А в систему Б? Но на деле часто оказывается, что системы А и Б имеют разную архитектуру и функциональность. Данные различия, в свою очередь, вызывают потерю данных, перенос нерабочих компонентов, нарушение прав доступа.
Чтобы избежать этих проблем, на проект привлекаются инженеры по тестированию программного обеспечения. Гибкость ума, умение разработать и реализовать грамотный план тестирования – навыки, которые позволяют тестировщикам обеспечить полный и безошибочный перенос всех данных, что и было сделано на проекте, описанном ниже.
Трудно ли автоматизировать мобильные приложения с нуля?
Нужно разобраться в инструментах, выбрать из них подходящие, подобрать правильные версии утилит, настроить их работу, а потом ещё и написать код.
Кажется сложным? Вы не одиноки — эта сложность останавливает многих. Порог вхождения в мобильную автоматизацию довольно высок, ведь инструменты только развиваются, а информации о них не так много. Но решать задачу надо, иначе качество вашего приложения не будет достаточным.
На мастер-классе в Екатеринбурге Арсений Батыров рассказывал, как развернуть автоматизацию мобильного приложения на Android с нуля. Ученики установили и настроили все нужные утилиты, запустили эмуляторы и написали первые тесты. На сложную логику времени не хватило, зато каждый смог настроить свою машину, подключить девайс и написать рабочий тест. Продолжить автоматизировать можно будет самостоятельно: всё-таки разбираться в рабочем процесс гораздо проще, чем начинать с нуля.
Трудно представить современную жизнь без мобильных устройств и, соответственно, без мобильных приложений. Неотъемлемой частью разработки таких приложений является их тестирование. Грамотный подход к организации тестирования мобильного приложения позволит правильно оценить время на проверку и создать удобный и качественный продукт.
Цена ошибок при тестировании очень высока. Для коммерческих приложений она может выражаться в снижении числа пользователей и возможных клиентов, а также в ухудшении репутации компании-разработчика. Для приложений, участвующих в производственных процессах или социальных сферах, – в недовольстве пользователей и в потере прибыли.
Поэтому мы рассмотрим основные аспекты, на которые требуется обращать внимание при тестировании мобильных приложений.
Промокод для получения 10% скидки на участие в конференции - s-t.ru
Уважаемые коллеги! Рады сообщить, что программа 23-й международной конференции тестировщиков программного обеспечения сформирована.
Уже сейчас вы можете выбрать интересующие вас доклады путем выбора поля "Я пойду" и затем сформировать путевой лист, нажав на ссылку "Скачать программу в PDF". Все выбранные доклады будут в этом файле.
Программа конференции покрывает широчайший спектр вопросов, связанных с обеспечением качества ПО. Представлены доклады от представителей крупных компаний из различных городов и стран. Ознакомиться с программой.
Приглашенные докладчики
Целевая аудитория
Тестировщики, тест-аналитики, разработчики тестов, руководители департаментов тестирования, разработчики ПО, менеджеры продуктов/проектов, менеджеры по качеству, менеджеры по развитию, руководители, которые хотят более глубоко понять работу своей команды.
Дата и место проведения
Конференция пройдет 25-26 мая 2018г. по адресу: Беларусь, Минск, проспект Дзержинского, 1E отель Ренессанс Минск (Схема проезда).
Приглашаем принять участие
Для участников предоставляются скидки от наших информационных партнеров и для групп участников, а также скидка для участников конференции Analyst Days-8, которая пройдет 27-28 апреля 2018 г. в Санкт-Петербурге.
Сертификация для тестировщиков
В рамках SQA Days-23 имеется возможность пройти сертификацию:
- ISTQB® Certified Tester Foundation Level - ISTQB® Certified Tester Advanced Level - iSQI® Certified Mobile App Testing - TMMi® – Professional
В конце первого дня конференции мы поедем отдыхать и развлекаться в ресторан "Чайхона Базар" (г. Минск, пр. Победителей, д.7). Восток – дело не только тонкое, но и неповторимо-вкусное. Помимо вкусностей и ароматного кальяна (для желающих), вас ждет отличная музыкальная программа.
Доставка участников будет осуществляться автобусами от места проведения конференции.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
В моей компании мы внедрили автоматизированную визуальную регрессию в нашу стратегию тестирования для трех продуктов. Мы выбирали разные фреймворки для внедрения, и мы используем автоматизированное визуальное регрессивное тестирование с немного разными целями в каждой команде. В этой статье я делюсь концепцией автоматизированной визуальной регрессии и привожу конкретные примеры ее использования.
Что такое визуальная регрессия?
Внешний вид веб-приложения обычно определяется каскадной таблицей стилей (CSS). Ваш продукт может использовать другую разновидность CSS – например, SCSS, SASS, LESS. Все они описывают формат и развертку вашего пользовательского веб-интерфейса.
Когда вы вносите изменения в продукт, вы, скорее всего, меняете его внешний вид. Вы можете намеренно работать над задачей дизайна – к примеру, исправлять отображение модального диалогового окна – или же разрабатывать часть функциональности, которая проходит через пользовательский интерфейс, что означает, что вам придется менять содержание экрана – к примеру, добавлять поле логина к банковской учетной записи. В обоих случаях вам, возможно, нужно внести изменения в таблицу стилей.
