Процесс внутреннего тестирования, я бы сказала, относительно стандартный – проверка реализованной функциональности, регресс, аксептанс, релиз.
Если немного подробнее…
В уже устоявшихся продуктах обычно процесс такой:
Когда определен скоуп итерации и появляется требование/user story, проработанное системным аналитиком, проводится его реврью и далее в параллель с разработкой фичи пишутся тест кейсы. Как только фича готова (частично или полностью), она передается разработкой в тестирование вместе с написанными интеграционными и/или E2E автотестами. Далее проходит приемка автотестов и проверка новой функциональности, а так же регресса вызванного этими изменениями. В этот же период может проходить дописывание E2E автотестов на основе ручных тест кейсов. При достижении критериев готовности фича выводится из под фича флага, и проводится еще один раунд релизного регресса (в основном автоматизированного). При достижении критериев готовности к релизу, собирается RC, на котором проводиться финальное аксептанс тестирование, и этот билд уже попадет в релизный канал в сторе.
Раскатка билдов в IRO и бета каналы проходит в параллель со внутренним тестирование. Первые билды могу попасть в тестовые каналы на самых ранних этапах, дополнительно давая возможность получить первый фидбек по новой фиче, до того как она доделана окончательно. RC билд так же сперва попадает в бета канал, а по окончании аксептанса переходит в релизный канал.
Как уже писал Виктор, раскатка релизного билда происходит поэтапно с отслеживанием и анализом метрик качества (Crashes, ANRs, отзывы, аналитика по проходимости сценариев).
В случае же новых пилотных продуктов…
Тут может быть менее строгий процесс. Может варьироваться объем и глубина проводимых проверок, может отсутствовать детальное написание тест кейсов и автоматизация… Однако выполнение оговоренных в начале проекта критериев качества – обязательно для релиза в продакшион.
Ручное тестирование так же является частью процесса выпуска релиза, не всё ведь возможно да и целесообразно автоматизировать…
При реализации новой функциональности, на первом этапе проверок всегда пишутся и прогоняются ручные E2E сценарии, которые в дальнейшем могут стать базой для E2E автотестов регрессионного набора.
На этапе стабилизации присутствуют как ручные тесты, так и автоматизированные тесты. Объем выполняемого регресса зависит от объема изменений, вызванных имплементацией нового функционала или исправлением багов. При частых релизах изменения делаются не масштабные, и их зачатую можно локализовать в рамках какой-то функциональной области продукта, тем самым максимально сократить необходимый объем проверок.
Финальный этап приемки RC почти во всех проектах автоматизировать по максимуму, т.к. это проверка основных сценариев продукта, а следовательно наиболее часто использующийся набор тестов.
Мы стараемся достичь оптимального уровня, некоторого баланса между затратами и выигрышам, которые приносит автоматизация. Нельзя ведь забывать, что затраты – это не только время на создание автотеста и окружения, но и дальнейшая его поддержка в рабочем состоянии. Основные выигрыши же будут только от тех тестов, которые регулярно используются, а не гонятются один раз в год. Поэтому не все ручные сценарии становятся автотестами. Важен баланс.
Так что… увы… нет, у нас нет волшебной кнопки «Проверь билд и выложи в продакшион», человеческий фактов всё ещё важен и ценен. :)
IRO и бета тестирование проходят в параллель со внутренним тестированием, помогая выявлять различные специфические сценарии или проблемы на специфических устройствах, а так же дают возможность оценить массовость крэшей и ANR-ов, которые в нашем окружении могут воспроизводиться лишь единично.
А ещё нам нужны джедаи мобильного тестирования! :)
Ищем тестировщиков с врожденной любознательностью, приобретенным скиллом шустрых пальцев или же с достаточным количество опыта и маны, чтобы заставить телефоны самим проходить тесты.
Присоединяйтесь к команде увлеченных своим делом специалистов. Это возможность осуществить вашу мечту — весь день вдумчиво тыкать в телефон и получать за это деньги.
Разработка и тестирование проводится как на реальных устройствах, так и на ферме.
Ферма — у нас своя, как раз на базе OpenSTF.
Примеры интеграции:
ферму используют ручные тестировщики и разработчики, как инструмент, позволяющий иметь доступные под рукой устройства в режиме 24/7 (что стало особенно критично в текущих условиях вынужденной удаленной работы).
автотесты используют ферму через разработанный в компании jenkins-плагин.
благодаря мониторингу использования устройств можно максимально оптимизировать пул устройств доступных для тестирования.
Если немного подробнее…
В уже устоявшихся продуктах обычно процесс такой:
Когда определен скоуп итерации и появляется требование/user story, проработанное системным аналитиком, проводится его реврью и далее в параллель с разработкой фичи пишутся тест кейсы. Как только фича готова (частично или полностью), она передается разработкой в тестирование вместе с написанными интеграционными и/или E2E автотестами. Далее проходит приемка автотестов и проверка новой функциональности, а так же регресса вызванного этими изменениями. В этот же период может проходить дописывание E2E автотестов на основе ручных тест кейсов. При достижении критериев готовности фича выводится из под фича флага, и проводится еще один раунд релизного регресса (в основном автоматизированного). При достижении критериев готовности к релизу, собирается RC, на котором проводиться финальное аксептанс тестирование, и этот билд уже попадет в релизный канал в сторе.
Раскатка билдов в IRO и бета каналы проходит в параллель со внутренним тестирование. Первые билды могу попасть в тестовые каналы на самых ранних этапах, дополнительно давая возможность получить первый фидбек по новой фиче, до того как она доделана окончательно. RC билд так же сперва попадает в бета канал, а по окончании аксептанса переходит в релизный канал.
Как уже писал Виктор, раскатка релизного билда происходит поэтапно с отслеживанием и анализом метрик качества (Crashes, ANRs, отзывы, аналитика по проходимости сценариев).
В случае же новых пилотных продуктов…
Тут может быть менее строгий процесс. Может варьироваться объем и глубина проводимых проверок, может отсутствовать детальное написание тест кейсов и автоматизация… Однако выполнение оговоренных в начале проекта критериев качества – обязательно для релиза в продакшион.
При реализации новой функциональности, на первом этапе проверок всегда пишутся и прогоняются ручные E2E сценарии, которые в дальнейшем могут стать базой для E2E автотестов регрессионного набора.
На этапе стабилизации присутствуют как ручные тесты, так и автоматизированные тесты. Объем выполняемого регресса зависит от объема изменений, вызванных имплементацией нового функционала или исправлением багов. При частых релизах изменения делаются не масштабные, и их зачатую можно локализовать в рамках какой-то функциональной области продукта, тем самым максимально сократить необходимый объем проверок.
Финальный этап приемки RC почти во всех проектах автоматизировать по максимуму, т.к. это проверка основных сценариев продукта, а следовательно наиболее часто использующийся набор тестов.
Мы стараемся достичь оптимального уровня, некоторого баланса между затратами и выигрышам, которые приносит автоматизация. Нельзя ведь забывать, что затраты – это не только время на создание автотеста и окружения, но и дальнейшая его поддержка в рабочем состоянии. Основные выигрыши же будут только от тех тестов, которые регулярно используются, а не гонятются один раз в год. Поэтому не все ручные сценарии становятся автотестами. Важен баланс.
Так что… увы… нет, у нас нет волшебной кнопки «Проверь билд и выложи в продакшион», человеческий фактов всё ещё важен и ценен. :)
IRO и бета тестирование проходят в параллель со внутренним тестированием, помогая выявлять различные специфические сценарии или проблемы на специфических устройствах, а так же дают возможность оценить массовость крэшей и ANR-ов, которые в нашем окружении могут воспроизводиться лишь единично.
Ищем тестировщиков с врожденной любознательностью, приобретенным скиллом шустрых пальцев или же с достаточным количество опыта и маны, чтобы заставить телефоны самим проходить тесты.
Присоединяйтесь к команде увлеченных своим делом специалистов. Это возможность осуществить вашу мечту — весь день вдумчиво тыкать в телефон и получать за это деньги.
Если заинтересовало, откликайтесь на открытую вакансию.
Ферма — у нас своя, как раз на базе OpenSTF.
Примеры интеграции: