Ссылки на на используемые и дополнительные материалы вот тут Telegram-канал QA | Про тестирование t.me/QA_quality_assurance Контакты: Telegram-канал QA | Про тестирование t.me/QA_quality_assurance Telegram-чат Chat QA | Про тестирование t.me/chatQA Инстаграм про QA и IT - instagram.com/qa_and_it/ Личный инстаграм - instagram.com/run_ocr_bogdan Ютуб-канал - th-cam.com/users/BogdanOvsiyuk Instagram instagram.com/run_ocr_bogdan LinkedIn hwww.linkedin.com/in/bogdanovsiyuk/ Дизайн обложек для видео и оформление канала - t.me/RYBAAAKOV
Богдан, подскажите, пожалуйста, как именно в V-модели соотносятся стадии разработки и тестирования? На втором слайде к этой методологии первые два этапа SDLC можно условно объединить в один - требования. Я бы напротив к этому этапу соотнесла что-то из статических техник типа формальной инспекции или peer review (как в книге у Куликова). В моем понимании так: собрали требования - следуем принципу о раннем тестировании и приступаем их анализировать. А, согласно слайду, мы видим напротив "приемочное" тестирование. Не понимаю почему схема именно так выглядит 😬
вот что у Куликова сказано про V-образную модель: V-образная модель (V-model23) является логическим развитием водопад- ной. Можно заметить (рисунок 2.1.b), что в общем случае как водопадная, так и v- образная модели жизненного цикла ПО могут содержать один и тот же набор ста- дий, но принципиальное отличие заключается в том, как эта информация исполь- зуется в процессе реализации проекта. Очень упрощённо можно сказать, что при использовании v-образной модели на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «на подъёме». Тестирование здесь появляется уже на са- мых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить множество потенциальных проблем до того, как они станут проблемами реальными. Жаль что сюда картинку схемы нельзя добавить😀
@@qaitchannel это я про требования) Вот как раз на всех этих схемах данной V- методологии они изображают по одной ветке этапы SDLC и на другой все соответствующие этапы тестирования, которые по сути идут уже после разработки кода. При этом данную модель характеризуют как включающую ранее тестирование. А получается мы только заранее продумываем что будем делать после разработки кода? Это и путает😅 Например на этапе сбора требований я ожидаю напротив в этой схеме увидеть статические техники тестирования, чтобы понимать как то самое ранее тестирование имплементировано. По этим схемам не понятно где же ранее тестирование то, если приступим мы к нему, как код будет готов)) п.с. надеюсь сегодня у меня лучше получилось свою мысль донести)😅
Ссылки на на используемые и дополнительные материалы вот тут Telegram-канал QA | Про тестирование t.me/QA_quality_assurance
Контакты:
Telegram-канал QA | Про тестирование t.me/QA_quality_assurance
Telegram-чат Chat QA | Про тестирование t.me/chatQA
Инстаграм про QA и IT - instagram.com/qa_and_it/
Личный инстаграм - instagram.com/run_ocr_bogdan
Ютуб-канал - th-cam.com/users/BogdanOvsiyuk
Instagram instagram.com/run_ocr_bogdan
LinkedIn hwww.linkedin.com/in/bogdanovsiyuk/
Дизайн обложек для видео и оформление канала - t.me/RYBAAAKOV
Наконец-то доходчиво объяснили и главное на примерах показали все. Полезное видео, буду пересматривать. Приятный голос😅😊
спасибо большое!
Богдан, подскажите, пожалуйста, как именно в V-модели соотносятся стадии разработки и тестирования? На втором слайде к этой методологии первые два этапа SDLC можно условно объединить в один - требования. Я бы напротив к этому этапу соотнесла что-то из статических техник типа формальной инспекции или peer review (как в книге у Куликова). В моем понимании так: собрали требования - следуем принципу о раннем тестировании и приступаем их анализировать.
А, согласно слайду, мы видим напротив "приемочное" тестирование. Не понимаю почему схема именно так выглядит 😬
Привет! Не совсем понял, ты хочешь функциональные и бизнес требования объединить в один пункт? Для чего?
вот что у Куликова сказано про V-образную модель:
V-образная модель (V-model23) является логическим развитием водопад- ной. Можно заметить (рисунок 2.1.b), что в общем случае как водопадная, так и v- образная модели жизненного цикла ПО могут содержать один и тот же набор ста- дий, но принципиальное отличие заключается в том, как эта информация исполь- зуется в процессе реализации проекта.
Очень упрощённо можно сказать, что при использовании v-образной модели на каждой стадии «на спуске» нужно думать о том, что и как будет происходить на соответствующей стадии «на подъёме». Тестирование здесь появляется уже на са- мых ранних стадиях развития проекта, что позволяет минимизировать риски, а также обнаружить и устранить множество потенциальных проблем до того, как они станут проблемами реальными.
Жаль что сюда картинку схемы нельзя добавить😀
@@qaitchannel так, это проедем) в час ночи было тяжело свои мысли адекватно в кучку собрать))😬
@@qaitchannel это я про требования)
Вот как раз на всех этих схемах данной V- методологии они изображают по одной ветке этапы SDLC и на другой все соответствующие этапы тестирования, которые по сути идут уже после разработки кода. При этом данную модель характеризуют как включающую ранее тестирование. А получается мы только заранее продумываем что будем делать после разработки кода? Это и путает😅 Например на этапе сбора требований я ожидаю напротив в этой схеме увидеть статические техники тестирования, чтобы понимать как то самое ранее тестирование имплементировано. По этим схемам не понятно где же ранее тестирование то, если приступим мы к нему, как код будет готов))
п.с. надеюсь сегодня у меня лучше получилось свою мысль донести)😅
cool
спасибо!
cool
спасибо!