Салют, кто это читает.Тут будет немного про бизнес процессы и немного про бытовыху qa engineer
Процесс тестирования программного продукта, непременно начинается с тестирования требований(Утопия?)где происходит проверка того, что требования являются полными, правильными и понятными. Затем следует этап тестирования проектирования, на котором проверяется, что проектирование соответствует требованиям и не имеет недостатков(А вообще реализуемо в контексте продукта?)
Далее следует этап написания тестовых сценариев, где определяются сценарии тестирования для проверки функциональности продукта. На этом этапе важно убедиться, что тесты полностью покрывают требования и проектирование.(Рекомендуется задать все аспекты тестируемого модуля/фичи, так как даже если от реализации откажутся, вы будете уверены, что все участки требований покрыты ТК и находятся в фокусе QA)
После этого происходит этап выполнения тестов, на котором производится непосредственное тестирование продукта на соответствие требованиям и проектированию. Здесь важно записывать результаты тестов и отслеживать ошибки, чтобы затем исправить их.(На этом этапе большая часть времени уйдет на коммуникации с разработчиком/PO/Analysis и желательно это время так же закладывать при планировании estimating time, а учитывая, что все участники так же заняты, скорость ответов кратко говоря ожидает желать лучшего..Проще собрать пул вопросов и создать встречу с заинтересованными лицами, озвучив их, вы получите объективную картину, так как все участники смогут конкретизировать свои запросы относительно каждого участка продукта)
После выполнения тестов происходит этап анализа результатов, где производится оценка того, насколько продукт соответствует требованиям и проектированию. Если обнаружены ошибки, то они исправляются, а затем производится повторное тестирование.(Очень важный скилл для QA при передаче багов/комментариев/правок - уметь комплексно и заблаговременно озвучить все свои желания разработчику, причем необходимо передать саммари по всем ошибкам данной фичи, или данного участка, ведь флоу будет примерно следующий: отдал баг на разработку-разработчик анализирует, пытается повторить, если не получается воспроизвести-идет к qa/analysis, когда удается воспроизвести-ищет ошибку в коде или сразу правит код-отдает на тестирование.И этот флоу достаточно утопичный, так как во время всех этих процессов может произойти череда непредвиденных обстоятельств.И это только один баг.А теперь представьте, что вы будете находить дефекты, и каждый раз этот флоу будет повторяться)
Наконец, последний этап - это этап утверждения качества продукта, где происходит проверка того, что продукт готов к выпуску. Здесь проверяются различные аспекты, такие как функциональность, производительность, безопасность и т.д.
Важно отметить, что процесс тестирования не является линейным и может быть подвержен изменениям в зависимости от ситуации. Тем не менее, построение процесса тестирования начиная с тестирования требований помогает обеспечить качество продукта и своевременное обнаружение ошибок.
Заключение.
Действительно, порой в работе очень сложно идти привычным эталонным путем тестирования, мы получаем срочные задачи, десятки созвонов, которые тратят время и силы, и найти время для тестирования требований сложно.Кажется, что это не скоро и у нас хватит ресурсов на все, но что если потратить эти 2 часа на обычный анализ?И начать задавать вопросы не в конце спринта, когда шкала стресса и тревожности у всей команды в красной отметке, а когда у всех есть достаточно времени для обсуждения, изменения и уточнения деталей?
Уверен, что в процессе проверки продукта Вы скажете себе спасибо, когда загляните в требования, а они будут выглядеть как инструкция к чайнику