Comments 7
Так как качество и требования тесно связаны, то логично предположить, что тест кейсы можно сгенерировать из требований
Как-то всё поверхностно и сильно обобщающе. Как какой-то фокус-покус, но обещаний успех. Требования бывают функциональными и нефукциональными. И те и другие под один знаменатель трудно подвести. А есть и другие, как технология, среда разработки итд. Посмотрите на разработку Boing 737 Max. Там этих тестов было не мало. Но весь проект был изначально неправильно начат и приведён в действие.
А в последнее время качеству вообще мало кто уделяет внимание. Нет, на словах - все за. И как-бы и тесты вроде делаются, после каждого деплоя всё встаёт. Стабильную архитектуру никто в агильных проектах не сможет сделать в спринтах, а по другому никто вообще не собирается с этим начинать....
Спасибо за коммент.
Почему же фокус? Это один из этапов разработки, который надо осознать и начать внедрять, погружаясь в тему.
Нефункциональные требования так же можно анализировать, записывать в виде сценариев и автоматизировать при помощи разных программ и инструментов. Только это надо делать. И процесс этот долгий.
Насчет, архитектуры и то, что ее не возможно в agile командах внедрять. Не соглашусь. У нас в компании, к примеру, архитектуре, инфраструктуре, уделяется особое внимание. Эти задачи планируются, все прорабатывается. Мы работаем по SAFe(R). Все зависит от культуры, процессов, регламентов, методологий, площадок принятых в компании.
User Story должны быть описаны по принципам INVEST.
Пишем User Story, которые можно разрабатывать отдельно
Пишем User Story, о рамках которых можно договориться
Пишем User Story, которые ценны заказчику
Пишем User Story, которые можно оценить
Пишем User Story, которые можно решить за одну итерацию
Пишем User Story, которые тестируемы.
вы пишите
А теперь, когда удалось расписать несколько User Story, давайте...
ну и скажите, что это не похоже на рисование совы (если не в курсе, просто гуглить).
А такие выражения в обьяснении как
Все зависит от культуры, процессов, регламентов, методологий, площадок принятых в компании.ничего не значащие фразы. Не в обиду Вам. И с SAFe я сталкиваюсь каждый день. И могу как одно время из внутри, так и как сторонний наблюдатель сказать — в боллее сложных проектах, чем простое улучшение какой-нибудь уже существующей интернет стрaницы — это не работает. От слова совсем.
И после каждого деплоя или база данных встаёт, или автоматические процессы, которые сферху идут встают или бизнесс-логика, или по времени не синхронизированы все компоненты или состовляющие. И после такого крэша начинается ремонт того, что были сделано в благих намерениях.
А самое, что меня умиляет — это типа в Jira можно и процессы как в визио рисовать и модели создавать и есть уже куча всяких генераторов, которые переводят Excel-таблицы в Jira-таблицы. Проблема в том, что люди, которые это должны вроде делать — они это и раньше не умели. И сейчас не будут, а если и будут, то как в басне Крылова «квартет».
"Проблема" с пользовательскими сценариями, на мой взгляд тестировщика, в том, что они рассматривают атомарные последовательности действий. А ошибки случаются, как правило, на стыке сценариев.
И если мы попытаемся учесть все возможные взаимодействия всех сценариев у нас опять случается "комбинаторный взрыв". Т.е. нужно вводить еще одно измерение в котором сценарии будут иметь свойство совместимости друг с другом, чтобы можно было как-то систематически учитывать, как сценарии могут влиять друг на друга. А это уже совсем другой подход. На уровне сигналов, входов и выходов. Тут нужна системная аналитика технического инженера и/или архитектора. И опять у нас конфликт. С одной стороны "мы же не ракеты строим", а с другой стремление к полному покрытию.
Как встроить качество в процессы производства ПО? (Часть 3)