Здравствуйте, такими тестами мы проверяем не удобство использования, а наиболее частные пользовательские сценарии, чтобы гарантировать в них отсутствие багов. Благодаря этому сильно сокращаем время регресса
На сайте у нас с учетом API тестов более 7000 тестов (это еще не учитывая что один тест может запускаться с разными данными). Более подробно как устроено все у нас на сайте мы еще расскажем
В командах по одному QA, каждый QA занимается и ручным тестированием и автоматизацией на обе платформы
Всегда в первую очередь обсуждение, почему один считает так, а другой иначе, если компромисс не находится, то идем к дизайнерам или продактам, за их мнением, как они себе видят фичу. Но стараемся все тщательно обсудить на этапе проработки. Если понимаем что проблема есть, то с каким типом будет заведена задача уже не важно (доработка или баг)
Я взял определение из учебников по тестированию :) Как мы (да и думаю многие) для себя это трактуем: вот условно есть кейс (возьму из своей области - приложение для поиска работы)
"Проверить заполнение образования в резюме":
Мы пошли выполнять этот кейс и открыв форму увидели, что там можно выбрать уровень образования (высшее\среднее) и добавить учебное заведение. Допустим выбираем высшее и заполняем заведение. Кейс закончили.
Но в голове (или на листочке) мы держим, что там можно было выбрать еще и среднее образование и посмотреть, а как в таком случае поведет себя приложение. Вот таким образом на основании предыдущего кейса мы придумали следующий
Поизучав и то, и то, пришли для себя к выводу, что нативные тесты для нас будут удобнее, более подробно можно почитать в нашем цикле статей про автотесты, конкретно про выбор фреймворка написано тут
В каждой команде в hh есть по одному, в очень редких случаях по два тестировщика, отдельного отдела у нас есть. Тестировщик обязательная часть команды
Чек-листы у нас только для регрессов, и так как большая часть регресса автоматизирована, то регресс не долгий. Как следствие, никаких систем для хранения чек-листов не нужно, и не проверяем ход регресса. Ответственность за проведенный регресс своего функционала на конкретном тестировщике, пока проблем с таким подходом не было
Да, согласен, исследовательское тестирование требует хорошего опыта, отчасти поэтому мы не берем специалистов с небольшим опытом ручного тестирования. Плюс у всех новичков закреплен ментор на первое время, который помогает освоиться в продукте даже опытному человеку
В android мы запускаем тесты в параллель на эмуляторах, параллелим через marathon . На каждый прогон мы выделяем по 20 эмуляторов. В iOS мы пользуемся стандартными методами икскода, на одной машине поднимается 3 симулятора, используем две машины (все тесты разделены на два тест плана).
Прогоны тестов на каждую из платформ занимают не более часа
На стадии становления процессов было пару инцидентов, когда в девелоп попадало то, что еще не протестировано. С тех пор решили, чтобы мимо qa ничего не прошло дать право на мердж только им (на самом деле еще лиды могут, если вдруг все тестировщики вымерли). Сейчас это так и осталось, никому не мешает, а тестировщик лишний раз убеждается, что все проверки прошли.
С конфликтами справляемся, так же как уже ответили, отдаем разработчикам, они разруливают конфликты и тогда мерджим
Здравствуйте, такими тестами мы проверяем не удобство использования, а наиболее частные пользовательские сценарии, чтобы гарантировать в них отсутствие багов. Благодаря этому сильно сокращаем время регресса
На сайте у нас с учетом API тестов более 7000 тестов (это еще не учитывая что один тест может запускаться с разными данными). Более подробно как устроено все у нас на сайте мы еще расскажем
Спасибо)
В командах по одному QA, каждый QA занимается и ручным тестированием и автоматизацией на обе платформы
Всегда в первую очередь обсуждение, почему один считает так, а другой иначе, если компромисс не находится, то идем к дизайнерам или продактам, за их мнением, как они себе видят фичу. Но стараемся все тщательно обсудить на этапе проработки. Если понимаем что проблема есть, то с каким типом будет заведена задача уже не важно (доработка или баг)
Я взял определение из учебников по тестированию :) Как мы (да и думаю многие) для себя это трактуем: вот условно есть кейс (возьму из своей области - приложение для поиска работы)
"Проверить заполнение образования в резюме":
Мы пошли выполнять этот кейс и открыв форму увидели, что там можно выбрать уровень образования (высшее\среднее) и добавить учебное заведение. Допустим выбираем высшее и заполняем заведение. Кейс закончили.
Но в голове (или на листочке) мы держим, что там можно было выбрать еще и среднее образование и посмотреть, а как в таком случае поведет себя приложение. Вот таким образом на основании предыдущего кейса мы придумали следующий
Поизучав и то, и то, пришли для себя к выводу, что нативные тесты для нас будут удобнее, более подробно можно почитать в нашем цикле статей про автотесты, конкретно про выбор фреймворка написано тут
Пойдем по порядку :)
В каждой команде в hh есть по одному, в очень редких случаях по два тестировщика, отдельного отдела у нас есть. Тестировщик обязательная часть команды
Чек-листы у нас только для регрессов, и так как большая часть регресса автоматизирована, то регресс не долгий. Как следствие, никаких систем для хранения чек-листов не нужно, и не проверяем ход регресса. Ответственность за проведенный регресс своего функционала на конкретном тестировщике, пока проблем с таким подходом не было
Да, согласен, исследовательское тестирование требует хорошего опыта, отчасти поэтому мы не берем специалистов с небольшим опытом ручного тестирования. Плюс у всех новичков закреплен ментор на первое время, который помогает освоиться в продукте даже опытному человеку
В android мы запускаем тесты в параллель на эмуляторах, параллелим через marathon . На каждый прогон мы выделяем по 20 эмуляторов. В iOS мы пользуемся стандартными методами икскода, на одной машине поднимается 3 симулятора, используем две машины (все тесты разделены на два тест плана).
Прогоны тестов на каждую из платформ занимают не более часа
На стадии становления процессов было пару инцидентов, когда в девелоп попадало то, что еще не протестировано. С тех пор решили, чтобы мимо qa ничего не прошло дать право на мердж только им (на самом деле еще лиды могут, если вдруг все тестировщики вымерли). Сейчас это так и осталось, никому не мешает, а тестировщик лишний раз убеждается, что все проверки прошли.
С конфликтами справляемся, так же как уже ответили, отдаем разработчикам, они разруливают конфликты и тогда мерджим