Комментарии 12
Зачем тестировщики мержат в девелоп?
А с конфликтами как справляются?
У меня был опыт с подобным подходом. При возникновении конфликта отправляешь обратно на доработку.
На стадии становления процессов было пару инцидентов, когда в девелоп попадало то, что еще не протестировано. С тех пор решили, чтобы мимо qa ничего не прошло дать право на мердж только им (на самом деле еще лиды могут, если вдруг все тестировщики вымерли). Сейчас это так и осталось, никому не мешает, а тестировщик лишний раз убеждается, что все проверки прошли.
С конфликтами справляемся, так же как уже ответили, отдаем разработчикам, они разруливают конфликты и тогда мерджим
Первое, что хочется спросить, количество вашей команды, и сколько в ней тестировщиков. Судя по описанию, у вас целый отдел.)
Второе, а где храните чек-листы? И как у вас прослеживается выполнение хода тестирования? Как бы тестеры не относились к TMS'кам, но в них есть некая гарантия, что ты ничего не пропустишь в процессе тестирования.
Третье. Согласен, что исследовательское тестирование - это крутой подход, но этот вид тестирования требует спецов хорошей квалификации. Новичкам все же необходимо более подробное описание кейсов.
Четвертое. 400 UI'ных автотестов вы запускаете в многопоточке? Эмуляторами пользуетесь или фермой?
Пойдем по порядку :)
В каждой команде в hh есть по одному, в очень редких случаях по два тестировщика, отдельного отдела у нас есть. Тестировщик обязательная часть команды
Чек-листы у нас только для регрессов, и так как большая часть регресса автоматизирована, то регресс не долгий. Как следствие, никаких систем для хранения чек-листов не нужно, и не проверяем ход регресса. Ответственность за проведенный регресс своего функционала на конкретном тестировщике, пока проблем с таким подходом не было
Да, согласен, исследовательское тестирование требует хорошего опыта, отчасти поэтому мы не берем специалистов с небольшим опытом ручного тестирования. Плюс у всех новичков закреплен ментор на первое время, который помогает освоиться в продукте даже опытному человеку
В android мы запускаем тесты в параллель на эмуляторах, параллелим через marathon . На каждый прогон мы выделяем по 20 эмуляторов. В iOS мы пользуемся стандартными методами икскода, на одной машине поднимается 3 симулятора, используем две машины (все тесты разделены на два тест плана).
Прогоны тестов на каждую из платформ занимают не более часа
А с чем связан выбор нативных фреймворков, а не Java + Appium, к примеру?
Поизучав и то, и то, пришли для себя к выводу, что нативные тесты для нас будут удобнее, более подробно можно почитать в нашем цикле статей про автотесты, конкретно про выбор фреймворка написано тут
Здравствуйте, такими тестами мы проверяем не удобство использования, а наиболее частные пользовательские сценарии, чтобы гарантировать в них отсутствие багов. Благодаря этому сильно сокращаем время регресса
На сайте у нас с учетом API тестов более 7000 тестов (это еще не учитывая что один тест может запускаться с разными данными). Более подробно как устроено все у нас на сайте мы еще расскажем
Большое спасибо за статью, с удовольствием прочитала.
1. Хотела уточнить: в команде нет ручных тестировщиков, только автоматизаторы?
2. Как решается проблема "баг это или доработка", если нет чётко прописанных требований?
Например, разработчик понял одним образом, а тестирование считает, что должно работать иначе, дизайнер/ аналитик дали резолюцию, каким образом заводится проблема, как баг или доработка?
3. И вот это не поняла "Это такой вид тестирования, который не требует написания тест-кейсов, но подразумевает, что каждый последующий тест выбирается на основании предыдущих." Как понять "на основании предыдущих"?
Спасибо)
В командах по одному QA, каждый QA занимается и ручным тестированием и автоматизацией на обе платформы
Всегда в первую очередь обсуждение, почему один считает так, а другой иначе, если компромисс не находится, то идем к дизайнерам или продактам, за их мнением, как они себе видят фичу. Но стараемся все тщательно обсудить на этапе проработки. Если понимаем что проблема есть, то с каким типом будет заведена задача уже не важно (доработка или баг)
Я взял определение из учебников по тестированию :) Как мы (да и думаю многие) для себя это трактуем: вот условно есть кейс (возьму из своей области - приложение для поиска работы)
"Проверить заполнение образования в резюме":
Мы пошли выполнять этот кейс и открыв форму увидели, что там можно выбрать уровень образования (высшее\среднее) и добавить учебное заведение. Допустим выбираем высшее и заполняем заведение. Кейс закончили.
Но в голове (или на листочке) мы держим, что там можно было выбрать еще и среднее образование и посмотреть, а как в таком случае поведет себя приложение. Вот таким образом на основании предыдущего кейса мы придумали следующий
Обеспечение качества мобильной разработки в hh.ru