Comments 11
В моем понимании, стратегия тестирования – это набор практик и целей тестирования, применяемых на проекте. Стратегия помогает понять, где и как лучше использовать тестирование в жизненном цикле разработки ПО.
Простите конечно, но как набор практик и целей помогает понять как лучше тестировать проект? Если бы Вы этот поток слов не обозначили как "Ваше понимание" меня бы, наверное, так не передернуло при прочтении.
Используемый набор практик и целей тестирования поможет понять как лучше тестировать продукт, к примеру, если опираться на метрики качества разрабатываемого ПО, на основе собранных данных можно скорректировать стратегию.
Мда, лучше не стало. Вы просто генерируете цепочку однажды услышанных понятий одним большим паравозиком? Я не ради зацепить, просто вдумайтесь в свой текст, причины и следствия, что используется для чего и зачем. Ну, бред же!
Наверно я не правильно выразился, но я имел ввиду, что существующие процессы в стратегии тестирования могут быть изменены, если мы смотрим на качество продукта, к примеру, основываясь на собранных метриках, и если оно нас не устраивает - мы меняем процессы в стратегии(уровни, виды тестирования, практики и др.) смотрим опять на метрики - стало лучше/хуже, еще раз меняем процессы и так, пока не придем к оптимальным, удовлетворяющим нас значениям. Таким образом мы можем понять, что было у нас не так в стратегии = понимание как лучше тестировать.
Эээ, опять путают Agile и Scrum (подозреваю, что плохо понятый Scrum, так как формально в Scrum не может быть роли QA-инженер).
Ну и остальное в статье - того же уровня, пересказ средних курсов по тестированию.
При чем тут стратегия тестирования - не понятно.
Здравствуйте, я работаю ручным тестировщик менее полугода, и все это время читал и думал, что e2e(сквозное или интеграционное) тестирование это не одно и тоже, что регрессионное тестирование. Либо вы имели ввиду, что в вашем случае при регреессе вы неизбежно стучитесь в сторонний сервис и тем самым у вас е2е тест в регрессе. Объясните пожалуйста.
Здравствуйте, e2e в нашем случае, это не только проверка интеграции со сторонними сервисами, но и тестирование функционала от начала до конца (пользовательские сценарии). К примеру, пользователь авторизовался, оформил подписку, проверил, что она активирована. Такие автоматизированные сценарии (будь то api или ui) удобно запускать при регрессе, когда нам надо проверить, что новый код не поломал существующий, возможно затронутый функционал.
Очень идеальный сценарий) вы действительно следуете всем пунктам?
Спасибо за статью!
Пишем стратегию тестирования для Agile/Scrum-проекта