Привет, Хабр!
Меня зовут Николай, и я тестировщик («Привет, Николай!»,- кричат участники собрания анонимных тестировщиков). Как и многие другие обитатели Хабра состою в нескольких тематических чатах и группах по QA, в которые время от времени приходят желающие «войти в IT» люди с вопросами «как найти работу, начинающему тестировщику?» или «с сего начать поиск вакансий?» и т.д.
Этот текст в первую очередь для них.
Меня зовут Владислав Романенко, я Senior iOS QA Engineer в Badoo и Bumble. Мы регулярно внедряем новые фичи в приложения, и автоматизация тестирования — один из способов не пропустить баги. Фактически автотесты входят в жизненный цикл всех частей наших приложений: бэкенда, сервисов, фронтенда и мобильных клиентов. Чем раньше мы обнаружим ошибку, тем дешевле будет её исправить.
Сегодня я расскажу об автоматизации тестирования в iOS, потому что на протяжении всей своей карьеры в Badoo я плотно занимался тестированием наших нативных iOS-приложений, которые написаны на Objective-C и Swift. Хотя кое-где я буду упоминать характерные для iOS инструменты и термины (например, XCTest), общие принципы и подходы универсальны. Так что, даже если в вашем проекте используется совсем другой стек, статья будет вам полезна.
Roadmap начинающего тестировщика мобильных приложений
Проблема, с которой сталкивается любая компания или стартап при релизе мобильного приложения — необходимость проведения тестирования. Желание сэкономить на этом этапе и обманчивое чувство, что всё и так идеально работает, приводят к тому, что 25% пользователей удаляют приложение после однократного использования из-за технических неполадок.
Отказаться от проведения тестирования — это всё равно, что прийти к врачу и спросить: «Зачем сдавать все эти анализы? Может сразу перейдём к лечению?». Чтобы избежать таких косяков и выкатить достойный продукт на маркет, советуем пройтись поэтапно по всем пунктам roadmap и проверить, действительно ли в вашем приложении всё работает. В конце есть несколько незаменимых тулов, которые обязательно должен иметь в своём арсенале любой тестировщик.
Сомнительные подходы к тестированию в Agile-разработке.
У Agile-разработки программного обеспечения много разновидностей, потому дать полноценное определение данному понятию крайне сложно. Недобросовестные Agile-мастера зачастую этим пользуются. Ведь можно продать собственный продукт или обучить клиента, как быть «более agile (гибким)», заработав при этом.
При рассмотрении термина «осмысленное тестирование» он выглядит как довольно странная абстракция, распространяющаяся на всю цепочку работы с программным обеспечением – от постановки задачи на разработку до деплоя. Что же значит слово «осмысленный» в данном контексте?
Если кратко, то создатель софта должен сосредоточиться на тестировании, приносящем пользу конечному продукту и его пользователям. Есть несколько подходов к осмысленному тестированию. Далее я расскажу о них, методиках, которые включены в эти подходы, и том, как реализовать новые знания в своей работе.
Elementary — архитектурный пакет для разработки приложений на Flutter: помогает чётко разделить слои согласно ответственностям и сделать код прозрачнее.
В предыдущих статьях рассказали, как устроен Elementary, чем он полезен, и на примере реального приложения посмотрели, как его использовать. Сегодня разберём, что у Elementary-приложений с тестированием и почему их код тестировать проще.
В iOS-приложении Авито куча UI-тестов — вы это уже наверняка знаете, потому что мы говорим про них постоянно. Это позволяет нам релизиться раз в неделю, причём регрессионное тестирование с ручными проверками мы проводим раз в две недели. Между ними в релиз идёт приложение, которое протестировано только нашими UI- и unit-тестами.
Чтобы поддерживать такие масштабы автотестирования, мы написали тест-раннер Emcee, который умеет скейлиться в ширину по физическим машинкам.
Хабр, привет!
Меня зовут Борис. Я Mobile QA lead в Vivid Money.
Это вступительная статья в цикле статей по iOS-автоматизации, в которых я расскажу о том, как ускорить прохождение UI-тестов.
Данная статья будет полезна iOS-автоматизаторам с опытом, либо разработчикам.
В рамках этой статьи мы разберем такие этапы:
- зачем ускорять время прохождения UI-тестов;
- что такое Test runner, и какие они бывают;
- что нужно для прогона тестов без компиляции проекта;
- делимся опытом, как это помогает нам.
В эпоху цифровой трансформации контроль качества (QA) программного обеспечения играет важную роль в выявлении недостатков в дизайне и обеспечивает функциональность и защищенность продукта.
Каждый новый год — это начало новой главы, поэтому в этой статье я расскажу о нескольких ключевых тенденциях в обеспечении качества ПО, на которые следует обратить внимание в 2022 году.
Все специалисты не без греха: учителя за пределами школы тоже всех поучают и к бытовым задачам относятся слишком ответственно; маркетологи следят за чужой рекламой и скидками и ворчат, когда слоган банальный, а креатив «не цепляет». А в этой статье — про тестировщиков.
С одной стороны, их поведение — баг. Хозяин кафе не ждет, что к нему обратится тестировщик и скажет: «У вас картины криво висят». С другой стороны — это фича. Тестировщику хватает смелости говорить о проблемах и предлагать решения.
После многих лет работы в должности QA Engineer я решил поделиться некоторыми советами по общению с разработчиками. Далее описаны мои наблюдения по этому поводу.
Привет!
Мы расширяем команду IT-специалистов и на этот раз приглашаем QA-инженеров уровня middle/senior пообщаться в новом формате — One Night Offer.
Мы не будем тратить время на на найм «по всем правилами» — с долгими согласованиями и десятком собеседований. Предлагаем уложиться в один вечер. За несколько часов вы успеете всё, от техскрининга до внутреннего интервью с командой — на нём вы собеседуете нас. Лучшие получат оффер в Альфа-Банк.
Когда?
10 февраля с 18:00 (подать заявку нужно до 15:00 9 февраля).
Что важно?
Ваш грейд — middle или senior, джунов позовём в следующий раз.
Опыт работы — не менее года.
Вы умеете проектировать тест-кейсы, применяли практики тест-дизайна и разбираетесь в клиент-серверной архитектуре, знаете SOAP/REST.
Вы хотите расти до full-stack тестировщика и готовы повышать свою экспертизу в крутой команде с отличными условиями.
Узнать подробности и подать заявку можно на сайте.
Меня зовут Семен, я занимаюсь автоматизацией тестирования мобильных приложений в hh.ru, и сегодня я расскажу о том, как писать автотесты под iOS.
Быстрые регрессы, низкий time-to-merket, счастливые пользователи, у которых нет багов — для всего этого нам нужны автотесты. Наше мобильное приложение работает сразу на двух платформах, и мы пишем автотесты для каждой из них.
Привет, Хабр! Немного наболело, хочу поделиться. В серии материалов я освещу ряд аспектов мобильного компьютерного зрения по принципу “от простого к сложному в имплементации”, однако буду фокусироваться на сложных кейсах, которые выходят за грань банального “распознать QR-код с фотографии один раз в сутки на %гиперскейлере%”. Я пишу только о мобильном, полностью автономном подходе, и надеюсь, смогу раскрыть определённую глубину задач мобильного компьютерного зрения, о которой не подозреваешь, принимаясь за работу по распознаванию данных с физических носителей в первый раз.
Первая статья - о том, как правильно протестировать сценарии распознавания штрих-кодов.
Одной из самых дорогих по времени операций на CI-сервере является прогон автотестов. Есть множество способов их ускорения, например, распараллеливание выполнения по нескольким CI-агентам и/или эмуляторам, полная эмуляция внешнего окружения(backend/сервисы Google/вебсокеты), тонкая настройка эмуляторов(Отключение анимации/ Headless-сборки / отключение снепшотов) и так далее. Сегодня поговорим про импакт-анализ или запуск только тех тестов, которые связаны с последними изменениями в коде. Расскажу какие шаги нужны для импакт-анализа и как мы реализовали это в нашем проекте.
Тестирование — не то, чем кажется. Я работаю тестировщицей больше десяти лет и встречала разные мифы о своей работе. В этой статье я разберу самые популярные из них.
Примечание редакции: тема важная, поэтому в качестве иллюстраций для большей читаемости мы добавили любимые мемы про QA.
Как и обещали, возвращаемся с записью первого QA-митапа от Ozon Tech. Поговорили об уровнях изоляции компонентов и комбинаторике. Ещё при регистрации можно было задать вопрос о тестировании, как это устроено у нас — мы получили почти полсотни любопытных вопросов и успели ответить на большинство из них.
Видео и презентации — под катом.
Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:
1. Написать код приложения
3. Поднять его на сервере приложения
Сегодня я расскажу про третий этап: что вообще такое сервер приложения и зачем он нужен.
Меня зовут Катя, я недавно стала QA-лидом в Альфа-Банке, до этого работала в команде. В этом посте я расскажу, как у меня происходил переход из командного тестировщика в позицию QA-лида. Возможно, моя история окажется полезной для тех, кто переходит из статуса "часть команды" в статус лида и пытается понять, что вообще случилось и как дальше жить.
Сейчас я занимаюсь Альфа-Мобайлом, нашим мобильным приложением для физических лиц. Работа в команде состояла из обычного взаимодействия с нашими IOS- и Android-разработчиками, с аналитиком, с бэкенд-разработчиком и с product owner’ом. В моей командной работе были обычные спринты, обычная приемка, обычное написание автотестов к различным компонентам архитектуры, конечно же, дедлайны и еженедельный всеобщий Мобайловский регресс. Помимо работы в команде, есть еще наставничество.
Архитектура довольно нетипичная: помимо обычного front’a и back’a есть еще и middle, и не каждый въезжает сразу, на это тратится много времени. На тот момент, когда со мной поговорил мой руководитель и рассказал, что пора переходить в лиды, у меня было два начинающих падавана. В общем, состоялся разговор о том, что пора расти, пора уже переходить дальше, я ответила, что хоть и очень загружена, но готова.
