Никто не любит наступать на одни и те же грабли. Чтобы избегать их на этапе анализа и тестирования требований, мы завели общую шпаргалку. Она включает в себя те вопросы, которые в идеале должны быть выявлены и зафиксированы до разработки. Мы используем её как чек-лист, с помощью которого стараемся глубже вникнуть в логику мобильного приложения и разобраться, какие потенциальные проблемы могут возникнуть у пользователя.

Статья ориентирована на тестировщиков, которых просят провести ревью ТЗ и найти в нём несоответствия, и на аналитиков, которым разработчики после прочтения ТЗ часто задают вопросы формата: «А что должно быть, если …?».

Мы уже публиковали свои внутренние документы с ожиданиями от инженеров и менеджеров продукта в плейбуке на Гитхабе. Пришло время поделиться ещё одним — кодексом тимлида.

Привет, Хабр!

В прошлой статье мы разобрались:

- Что такое ui-тесты и для чего они нужны;

- Как настроить окружение для тестов;

- Как находить ui-элементы в проекте и проставлять им accessibilityidentifier.

В этой статье мы разберем:

- Как обращаться и инициализировать ui-элементы в ваших тестах;

- Как взаимодействовать с ui-элементами приложения;

- Как писать ассерты для проверки в автотесте ожидаемого результата.

Первое, что видит пользователь - UI приложения. И в мобильной разработке больше всего вызовов связано именно с его построением, а большую часть времени разработчик тратит на чизкейк верстку и логику презентационного слоя. В мире существует множество подходов к решению этих задач. Часть того, что мы расскажем, скорее всего уже используется в индустрии. Но мы попытались собрать воедино некоторые из них, и уверены, что это станет вам полезно.

На старте проекта мы захотели прийти к такому процессу разработки фич, чтобы вносить как можно меньше изменений в код при максимальном соответствии с пожеланиями дизайнеров, а также иметь под рукой широкий спектр инструментов и абстракций для борьбы с бойлерплейтом.

Эта статья будет полезна тем, кто хочет тратить меньше времени на рутинные процессы верстки и повторяющуюся логику обработки состояний экранов.

Всем привет!

Меня зовут Борис. Я AQA iOS-engineer в Vivid Money.

Это вступительная статья, в цикле статей по iOS-автоматизации, в которых хочется рассказать о пользе ui-тестов на проекте, их эффективном использовании и написании.

Данная статья будет полезна начинающим iOS-автоматизаторам, либо разработчикам, которые решили изучить XCUITest и покрыть свой проект ui-тестами.

Итак, 7 шагов от чайника к тестировщику.

Эти вечные сомнительные доводы «это не баг, это фича» или «если это и баг, то незначительный, пусть остается».

Да как же остается, если система колом встает!?

То им это не нравится, то тут не работает! Да нафига было вообще в этом окне контекстное меню вызывать и вставлять нечитабельные символы!? Как они вообще до этого додумались!? Бред же, в боевом режиме так ни один пользователь не сделает!

Не буду править, пусть остается!

Пара вводных слов
Всем доброго времени суток, меня зовут Туманов Дима. Сейчас я работаю в компании Rambler&Co и отвечаю за тестирование на проектах Афиши. В рамках данной статьи я развею несколько мифов об IT и тестировании в частности. Кроме того, приведу примеры из жизни как “не зная ничего” стать Junior QA Engineer в крупной компании.

Начало пути
Проработав почти два года в одной “мирной” госкорпорации в должности “ненастоящего инженера”, я осознал, что развитие остановилось. Я мог сидеть на одном месте и почти ничего не делать. В конечном итоге мои знания бы совсем отстали от реальной действительности и я бы стал невостребованным на рынке. В этот момент я принял решение о смене места и сути своей работы.