Size: a a a

QA — русскоговорящее сообщество

2021 January 16

А

Александр in QA — русскоговорящее сообщество
Дмитрий Кононов
Дело в том, что есть около 25 сценариев закупки (включая все документы по закупке и расчетов с поставщиком) с различными условиями. Думаю, как это расписать в наиболее удобном виде, если раздельно, создание заказа 1, создание заказа 2, то так неудобно составлять тестовый набор для регресса
Примерно похожее есть. Реализовано как сценарий. Но данные соответственно готовится заранее.
Некоторые кейсы постоянно повторяются типа (загрузить условно накладную в систему для дальнейших действий с ней)
Но делалось для того, что бы человек не знающий цепочек взаимодействий мог прогнать хотя бы позитивные сценарии.
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Александр
Примерно похожее есть. Реализовано как сценарий. Но данные соответственно готовится заранее.
Некоторые кейсы постоянно повторяются типа (загрузить условно накладную в систему для дальнейших действий с ней)
Но делалось для того, что бы человек не знающий цепочек взаимодействий мог прогнать хотя бы позитивные сценарии.
Спасибо, об этом я не подумал. В зависимости от условий могут формироваться или не формироваться определенные документы и могут создаваться одни и те же. С точки зрения нового человека вы для меня прояснили
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Александр
Примерно похожее есть. Реализовано как сценарий. Но данные соответственно готовится заранее.
Некоторые кейсы постоянно повторяются типа (загрузить условно накладную в систему для дальнейших действий с ней)
Но делалось для того, что бы человек не знающий цепочек взаимодействий мог прогнать хотя бы позитивные сценарии.
А у вас какая система?
источник

А

Александр in QA — русскоговорящее сообщество
Дмитрий Кононов
А у вас какая система?
Принцип похож на 1с товары и склад, но собственной разработки плюс взаимодействует с другими внешними гос.сервисами типа Меркурий, диадок и еже с ними.
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Думаю организовать так, в первую очередь взять критические сценарии закупки, расписать их тест-кейсами, затем написать остальные, в них добавить из критических те кейсы, которые повторяются, и так сценарий за сценарием, копируя кейсы из существующих сценариев там где это нужно.
источник

А

Александр in QA — русскоговорящее сообщество
Дмитрий Кононов
Думаю организовать так, в первую очередь взять критические сценарии закупки, расписать их тест-кейсами, затем написать остальные, в них добавить из критических те кейсы, которые повторяются, и так сценарий за сценарием, копируя кейсы из существующих сценариев там где это нужно.
Имеет место быть и наверное не помешает 2 документа с 1 ид или документ без товара или 2 документа с одинаковым товаром и т.д. какварианты комбинаторики. Но это мое мнение я если честно проекта не видел и сложно советовать. Мало ли бизнес хочет по другому или тз разработано где четко описанно что и как.
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Александр
Примерно похожее есть. Реализовано как сценарий. Но данные соответственно готовится заранее.
Некоторые кейсы постоянно повторяются типа (загрузить условно накладную в систему для дальнейших действий с ней)
Но делалось для того, что бы человек не знающий цепочек взаимодействий мог прогнать хотя бы позитивные сценарии.
Вопрос вот только остался, если цепочка берет начало в одном функциональном блоке, а заканчивается в другом, то к какому из блоков отнести цепочку в TestRail?
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Александр
Имеет место быть и наверное не помешает 2 документа с 1 ид или документ без товара или 2 документа с одинаковым товаром и т.д. какварианты комбинаторики. Но это мое мнение я если честно проекта не видел и сложно советовать. Мало ли бизнес хочет по другому или тз разработано где четко описанно что и как.
Ну это да, для увеличения тестового покрытия добавить своих тест-кейсов, в том числе отдельные проверки и негативные тесты
источник

А

Александр in QA — русскоговорящее сообщество
Дмитрий Кононов
Вопрос вот только остался, если цепочка берет начало в одном функциональном блоке, а заканчивается в другом, то к какому из блоков отнести цепочку в TestRail?
Тут я не смогу помочь к сожалению у меня нет опыта работы с testrail.
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Александр
Тут я не смогу помочь к сожалению у меня нет опыта работы с testrail.
Да не важно, в принципе, какая это TMS, главное как это оформить, с одной стороны понятно, что если баг в счете, то это к финансам, если в заказе, то в логистике, но куда именно отнести в TMS непонятно, думал, что если цепочка начинается в логистике, то и относить к логистике, но весь процесс (сценарий) содержит и финансы (счета, оплаты, проводки)
источник

А

Александр in QA — русскоговорящее сообщество
А разработчики разные команды на разные модули?
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Александр
А разработчики разные команды на разные модули?
Да
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Ну как подрядчик - один, но разные команды на разные модули
источник

А

Александр in QA — русскоговорящее сообщество
Копипастить проверки на каждую ветку ток что в голову пришло. Если руководство даст добро конечно, оговорить, что проверки будут проходить одна но для удобства и экономии времени разработки баги относить к разным командам с пометкой где ошибка.
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Александр
Копипастить проверки на каждую ветку ток что в голову пришло. Если руководство даст добро конечно, оговорить, что проверки будут проходить одна но для удобства и экономии времени разработки баги относить к разным командам с пометкой где ошибка.
Если копипастить проверки по двум модулям, при составлении тестового прогона для регресса придется исключать, так как они будут повторяться
источник

А

Александр in QA — русскоговорящее сообщество
Дмитрий Кононов
Если копипастить проверки по двум модулям, при составлении тестового прогона для регресса придется исключать, так как они будут повторяться
Исключать придется конечно и в отчёте не учитывать. А если кейсы с финансами относить к одной ветки а логистика к другой но начало будет как бы одно? А если использовать не кейсы а тест план?
источник

А

Александр in QA — русскоговорящее сообщество
Дмитрий Кононов
Если копипастить проверки по двум модулям, при составлении тестового прогона для регресса придется исключать, так как они будут повторяться
Типа
1. Загрузить документ в систему
2. Нажать отправить и дождаться получения документа.
3. Проверить сумму и товары и т.д.
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Александр
Исключать придется конечно и в отчёте не учитывать. А если кейсы с финансами относить к одной ветки а логистика к другой но начало будет как бы одно? А если использовать не кейсы а тест план?
Как вариант, можно сделать так , в логистике создать начало сценария и все тест-кейсы, назвать сценарий 1, в финансах написать продолжение и назвать сценарий 1, в предусловии в финансовом тест-кейсе, который первый написать в предусловии "создан сценарий 1 в логистике (образно)"
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
так будет удобнее собирать тестовые прогоны, в том числе и для новых членов команды
источник

ДК

Дмитрий Кононов... in QA — русскоговорящее сообщество
Для обучения
источник