Кто-нибудь применяет DRY / KISS / SOLID принципы к требованиям / тестам?
Требования с тест-кейсами должны быть связаны 1-к-1? одно требование - один тест кейс?
Или хотя бы одно требование - много тест-кейсов?
Но никак обратно, когда есть один тест-кейс, слинкованный сразу с многими требованиями?
На самом деле, это зависит от 2 вещей:
Если 1 элемент описан 100500 требований типа "
то кейс типа “зайти на скрин, проверить наличие кнопки” автоматом зацепит требования 1, 2, а, возможно, и ещё какое-нить. Можно, разумеется, написать по кейсу на каждое требование, но поддержка таких кейсов и их прохождение превратятся в ад.
С другой стороны, если требования описаны вменяемо, типа “хочу красную кнопку размером 120Х80”, то нормализация структуры требование - кейс через 1-ко-многим в большинстве случаев достижимо и значительно упрощает поддержку кейсов.
когда требования в виде “хочу кнопку”, это прям не верится, что так бывает.
я не много работаю в тестировании, но всегда задача была тестировать бизнес-процессы, в котором таких вот кнопок миллион штук. а если тестируемый продукт живой, читай меняющийся, то при неизменных требованиях тесты в какой-то момент совершенно внезапно становятся невалидными. и вот у меня вопрос: в таких условиях вообще имеет смысл соблюдать какие-то принципы?
Имеет смысл требовать поддержку изменений в требованиях, если они у вас формально ведутся. На крайняк, никто не мешает вносить эти изменения самостоятельно по факту change requests от заказчика.
мы бы рады были не соблюдать “какие-то принципы”, если бы не аудиторы и медтех продукт.
формально ведуться на полном серьёзе, но вот часто так, что лучше бы не велись… особенно стремно, когда требования пишутся условно 10 лет разными людьми в разном стиле…и их много… и все с чем то связаны (то с другими требованиями, то с тестами, то еще с чем).
testomat.io управление авто тестами