Антон Заморский

Тест-кейс стоит добавить в регресс если он: Не относится к "новому" функционалу; Не является узко-специфичным (редким) случаем; Не является очень трудоемким, по сравнению с общей массой тест-кейсов; Не обладает очень низким приоритетом по сравнению с остальными. Решение о включении кейса в регрессионную модель принимает непосредственно САМ ФУНКЦИОНАЛЬНЫЙ ТЕСТИРОВЩИК. Для Демонстрации экрана Skype for bussines Для чата телега и сеймтайм для звонков телега и зум Плановые релизы PSB-Retail выполняются один раз в месяц во вторник. Release manager - структурирует все этапы релизного цикла, осуществляет поиск и оптимизирует процессы, замедляющие релиз. Обеспечивает процесс выпуска обновления мобильного приложения. Внедряет практики, направленные на сокращение срока регрессионного и модульного тестирования. Не допускает попадания задач, не соответствующих требованиям качества. Информирует команды разработки о несоответствии функционала требованиям, принимает участие в устранении замечаний. Release captain - ответственный QA отвечающий за контроль готовности и доставки релиз-кандидата до заинтересованных лиц, за состав тест-плана для регрессионного тестирования и контроль прохождения регресса. Release engineer - разработчик iOS и Android, отвечающий за проведение feature freeze, формирование отчета fortify (напоминать об отчете СИБу), его загрузки и дальнейшее согласование с СИБ, предоставление релиз-кандидата заинтересованным лицам, распределение найденных на регрессе багов, сопровождение выкладки приложения в системы распространения, последующий саппорт билда в проде (в том числе следит за крэшами), проведение hotfix при необходимости. Feature driver - любой участник скрам команды, заинтересованный и ответственный за реализацию фичи в PSB-Mobile и доставки ее в продакшн. Release scope planning - определение списка задач (feature) команд, которые должны попасть в следующий релиз. Release scope freeze - актуализация списка задача (feature) команд, проверка задач на соответствие критериям приемки, отключение недоработанного функционала. Feature freeze - выделение релизной ветки и сборка релиз-кандидата. Regression testing - процесс исследования программного обеспечения на предмет работоспособности старого функционала (новый ф-л не сломал старый), этап регрессионного тестирования начинается с получения первого релиз-кандидата. Automated testing - часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения, направленный на проверку основного функционала мобильного приложения. Процесс запуска тестов регулируется конвейером в Gitlab CI (merge request\ по расписанию ночью\ по тэгу версии). Передача кейсов на автоматизацию производится согласно "регламенту работ по автоматизации". Smoke testing - автоматизированный список тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции (верхнеуровневая проверка основного функционала мобильного приложения). При присвоении тест кейсу статуса "Smoke" необходимо срочно автоматизировать его. Процесс запуска тестов регулируется конвейером в Gitlab CI (merge request\ по расписанию ночью\ по тэгу версии). Со списком Smoke test можно ознакомиться здесь. Distribution - публикация приложения через Google Play/App Store/AppGallery на 100% пользователей. С более подробной информацией по выкладке приложения можно ознакомиться здесь. Уровни доступа - уровни дистанционного доступа клиента к функцционалу банка, зависят от подтверждения личности. Операционный - Максимальный доступно всё Информационный - заключивший договор Упрощенный - минимальный, но авторизированный на госуслугах Начальный - минимальный недоступно ничего При оформлении банковского продукта пользователь получает начальный уровень доступа. При желании переходит на информационный уровень, заключая договор. При оформление ДКО переходит на операционный. Причины откаты до информационного уровня: Клиент попал в стоп - лист. Клиент приходит в офис и расторгает ДКО (договор комплексного confluen

Веб Разаботка происходит на фича ветках. Со вторника на среду происходит срез - функционал переходит из среды DEV на TEST Порядок срезов: первый вторник: DEV - TEST второй вторник: DEV - TEST третий вторник: DEV - TEST и происходит Feature Freeze четвертый вторник: TEST - PROD DEV также вручную срезается на retail-tst.payment.ru для того чтобы с тестовых устройств была возможность из внешней сети попасть на DEV среду. retail-tst.payment.ru Это бэкэнд DEV с фронтэндом TEST и отдельным API зайти можно клиентами DEV можно без VPN Если код был залит на DEV с первого до второго вторника, то можно тестить на DEV до второго вторника, потом тетстить на TEST. Если код был залит на DEV со второго вторника до третьего вторника, то можно тестить на DEV со второго вторника до третьего, потом тетстить на TEST. Если код был залит на DEV с третьего вторника до четвертого вторника, то можно тестить на DEV с третьего вторника до четвертого, потом тетстить на TEST. Frontend и Backend - монолитная часть релизится в одни и теже дни со вторника на среду. Feature Freeze - нужен, чтобы на тестовой среде код оставался стабильным, и после него делали только мелкие баг-фиксы. Чтобы мы могли в течение последней недели перед релизом протестировать код без изменений. После Feature freeze допускаются роллбэки, баг-фиксы или срочные задачи, какие-то небольшие хот-фиксы. Делать ролл-бэк лучше всего в первый же день после Feature-freeze, чтобы было время протестировать ничего ли ролл бэк не сломал, чтобы код на TEST был стабильным максимально долгое время. До Feature Freeze нужно выбрать в какой среде протестить свою задачу. Если задача была выполнена разработчиком после второго вторника, то задачу нужно тестировать на DEV и после Feature Freeze в третий вторник на TEST. После Feature Freeze обязательно повторно протестировать свою задачу на TEST, потому что после первого тестирования мог быть залит функционал, который мог повлиять на фичу, тестируемую первоначально. После Feature Freeze есть неделя на то, чтобы проверить свои задачи и провести регресс по тому, что могло затронуться. Релизы - один раз в месяц во вторник. Если разработчик за два часа до среза обновил сборку то мы ему не даём этого сделать и договариваемся с разработчиком. Regress-тестирование Регресс ручной только на мобилках, на WEB весь регресс автоматизирован на API. Регресс по мобилкам начинается дня через 3-4 дня после релиза бэка, так как времени мало, часто получается так что тестировщику не хватает времени. Нужно не стесняться говорить что не успеваешь что-то протестировать. Не идем на поводу у бизнеса. Не закрываем задачу не протестировав! Не овертаймим чтобы кое-как успеть! Постепенно от спринта к спринту учиться более точно планировать. очень сильно влияет на задачу в этом релизе подсвечивать риски продукту что мы можем не успеть Feature toggle - создают разработчики на Frontend и Backend, чтобы какая-то функция могла быть выключена и не показываться определенному кругу пользователей. Решение о том, что нужно спрятать фичу под фича тогл принимается до фича фриза. Работу фича тогла проверить нужно обязательно по трём кейсам: -отсутствие тогла -выклчюеный тогл -включен тогл Протокол тестирования фича тогла обязателен. Переключатели функции В фильтрах можно настроить для кого включается фича тогл, можно сделать фильтр по группах клиентов процент доступности - процент от группы Если новая операция и не хотим чтобы она была доступна, то можно отключить саму операцию В любой задаче в Jira есть номер задачи - с этим номером должна называться ветка разработчика в которой он работает над этой фичей. Если есть задача у неё нет метки фича тогл, если у нее статус отличается от "закрыта", "готова к тестированию" или "протестирована", то она попадает в красный фильтр разработчик как только залил код на дев, обязан проставить версию релиза метк афича тогл комментарий знать где посмотреть даты релизов "релизы и срезы" в какой момент фича фризы срезы релизы где брать инфу как тестить задачи в зависимости от того когда залили код на дев перед фич retail-tst.pay

identity.getpostman.com/...5.0