Курс Тестирование ПО. Занятие 4. Верификация и валидация | QA START UP
HTML-код
- Опубликовано: 25 сен 2018
- ✅ Подписаться на канал QA START UP - IT Training Center: ruclips.net/user/QASTARTUPIT...
Всем привет, меня зовут Сергей Гливинский, сегодня среда и это означает, что мы изучаем очередную тему нашего курса Тестирование ПО для новичков. Уже 4 урок и тема, которую мы рассмотрим: Верификация и Валидация - логическое продолжение понятий Тестирование и Качество.
Приятного просмотра!
------------------------------------------------------
❗️❗️❗️Мои курсы:
🇺🇦 Курс QA BASE в Украине:
👨🏫 OFFLINE: qastartup.net/qa-base?...
👨💻 ONLINE: qastartup.net/qa-base-online?...
🇺🇸 Курс QA Engineer | SDET в USA:
qastartup.us/qa-profession?ut...
------------------------------------------------------
Ссылки на ресурсы QA START UP - IT Training Center :
✅ qastartup.com.ua
✅ / qastartup
✅ / qastartup
#курсытестировщиков #qastartup #школатестирования
Круто! Спасибо!
По этой теме интересный пример был на Хабре, мне понравился:
"Когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» - программа сработала, с точки зрения «валидации» - нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки." (с)
Доходчиво, респект)
Спасибо. Вся информация по делу, понятно, и подробно. Очень приятно слушать и легко для понимания.
Спасибо за ваши видео! Очень кратко, чётко и по делу👍🏼
Спасибо! Наконец-то я нашла качественный и удобный источник информации. Я очень редко пишу комментарии, но в этот раз я должна Вас поблагодарить. Вы мне очень помогли понять разницу.
Бомбическое объяснение! Спасибо!
Как же все понятно вы обьясняете! Спасибо вам большое)
Дякую за Ваші уроки !!
Спасибо за видео!
Сергей, спасибо огромное за ваш труд! Очень интересно и доступно. А главное не затянуто (что обычно отпугивает новичков).
you prolly dont care at all but does anyone know of a method to get back into an instagram account?
I was dumb lost the account password. I would love any tips you can give me
@Ryder Lochlan instablaster ;)
Почала знайомство з професією тестувальника з Вашого відео) зрозумілі та класні пояснення, важко відірватися від перегляду:) дякую за доступність автору😉😊
Очень круто и понятно.
Лайк не глядя)
Чудові схеми👍👍👍
Спасибо!
На 3:37 баг. Окошко с тобой закрывает концовку определения.
Спасибо, пока всё понятно, если бы и дальше было так просто😃
Спасибо большое. Очень помогли 🤣
Я читала несколько другие определения)
Верификация (Verification) - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.
Валидация (Validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе
верификация - сравнение продукта с требованиями, которые БА написал, а вся команда их изучила (но по сути это же то, что команда и собирается поэтапно делать), то что в Вашем определении. Именно поэтому и говорят еще на счет верификации: Правильно ли мы делаем продукт???, то есть в соответствии спецификации. А вот валидация это уже то что в реале нужно конечным пользователям. Поэтому все что в видео и Вы написали - одно и тоже, только по разному сказано.
хороший курс!
Спасибо за эту тему. Коротко и ясно.
супер!
Пожалуй одно из лучших обьяснений этих понятий!
Лучшее объяснение! Спасибо огромное! Тысяча лайков 👍👍👍👍👍👍👍👍👍👍👍👍 ♾
Завтра сдаю госы, большое спасибо за объяснение С:
спасибо
Коротко и очень доступно)))
Ни фига не понял, но было очень интересно!
Какие есть унструменты контроля процесса Validation ?
МЕГАЖИРНЫЙ ЛАЙК
Самое лучшее и краткое объяснение что я когда либо слышала. Спасибо невероятно круто!!!!!
Все просто і зрозуміло пояснили. Дякую!
Дякую, що внесли ясність в цю тему.
Спасибо.не как не мог запомнить и понять эти понятия
хорошо, если обратная связь для проц верификации существует посредством связи разработчика и ВА, то на кого замыкается проц валидации, если условно нет прямой связи разработчика и заказчика? (только через ВА! а это верификация!)??
жалко нет примера. не понятно, чем отличаются требования от нужд заказчика, сорри (
а как вы прошлые видео смотрели? Сижу на скорости 1.5 улавливаю что происходит. Нужды заказчика - машина, требования - механизм, способный передвигаться. Требования мы выполнили, т.е. предоставили лошадь с полмашиной, а вот про нужды забыли.
@@SaintTrident Здорово у Вас получилось объяснить)
@@mr.tuttifrutti92807
@@SaintTrident в тз и тп должно было быть априори все обозначено, просто мало кто понимает что написание грамотного тз очень расточительно, на этом все экономят. Валидация- явление, вызванное некомпетентностью составителя тз. Как вам такое определение?
Спасибо, Вы очень помогаете этим курсом
Где найти презентации?
Сергей, доброй день. Позвольте задать вопрос : понятия "Требования" и "Нужды заказчика" мне кажется можно все-таки приравнять,при наличие на проекте достаточно квалифицированного BA, ведь требования, по сути, это производная от анализа нужд заказчика. Если требования заказчика грамотно проанализированы и задокументированы то зачем разделение на верификацию и валидацию, мне кажется данное разделение можно упразднить путём написания технического задания максимально отражающего требования непосредственного заказчика. По сути это двойная работа. Конкретно в тестирование имею небольшой опыт, могу ошибаться. Спасибо.
Добрый день, Олег. Все верно, в идеале "Требования" и "Нужды заказчика" должны быть эквивалентны, и то что описано в требованиях, должно полностью отражать реальные потребности заказчика/конечных пользователей. Но в реальной жизни не всегда бывает так, что требования написаны на 100% идеально, даже при наличии высококвалифицированного BA. Бывает даже сам заказчик меняет очень часто требования, уже на этапе разработки и тестирования, при этом и близко не все сообщает BA. Так же представитель заказчика (например Product Owner) не всегда точно знает, что нужно конечным пользователям. В общем есть много нюансов когда мы можем получить Требования которые в полной мере не описывают того, что нужно реально конечным пользователям. В тестировании есть такое понятие как уровни тестирования, еще можно услышать такую фразу как Quality Gates. Так вот, например, Системное тестирование в компании аутсорсера будет направлено как раз на Верификацию продукта, а уже Приемочное тестирование будет проводится на стороне заказчика или конечными пользователями для определения все ли ок с продуктом для его применения в реальной жизни, а это и будет Валидация. Что бы подитожить, Верификация это проверка со стороны просто тестировщиков на стороне разработки (так как мы на 100% не можем проверить то, что могут конечные юзера, в случае сложного продукта), а Валидация - проверка со стороны конечных юзеров, правильный ли продукт они получили. Именно поэтому и разграничивают эти два понятия.
@@sergiiglivinskyi6489 благодарю за развернутый ответ!
Я с Вами согласен. Если требования отличаются от пожеланий Заказчика - значит Бизнес-Аналитик накосячил
@@sergiiglivinskyi6489 Когда Заказчик по ходу "пьесы" меняет исходные данные и набор фичей - это называется многовариантная разработка. Раньше была версия "хотелок" 1.0, где требования и пожелания ПОЛНОСТЬЮ совпадали, то после появления хотелок 2.0 появляется расхождение требований хотелок 1.0 и 2.0. И как эту неувязку тестировать, если по сути это 2 разные ПО (например, хочу, чтобы сайт был синего цвета, а теперь красный). Это косяк Quality Assurance, что хотелки 2.0 застряли "на верхах" и не оказались у всех участников разработки.
Сделайте пожалуйста субтитры к видео, а то приходится пропускать (
3:37m - 3:56m
Ведущий перекрывает часть текста в блоке определения "Валидация"
Глухие или слабослышащие не смогут понять, о чём идёт речь.
На 2:25 минуте зависло видео и дальше не идёт. Это только у меня такая проблема ?
Тоже самое было. Поставь качество 1080р, мне помогло.
Что означает ADB в тестировании?
ADB (Android Debug Bridge) - это инструмент, который позволяет через командную строку общаться с устройством, на котором Вы тестите софт.
море позитива!
Но ведь требования составляются в соответствии с нуждами заказчика.В чем конкретная разница?
BA человек и он может ошибаться, заказчик, который что-то излагает в своих хотелках, тоже мог подразумевать другое, в итоге часто получается ситуация когда требования уже не эквивалентны конечным нуждам юзеров. Хотя конечно, если все друг друга поняли правильно и BA не сделал никаких ошибок, то требования и нужды заказчика это одно и тоже!
Если верификация прошла успешно, почему мы не можем предположить что и валидация пройдет упешно? Если валидацию продукт не проходит в очем ошибка?
потому что-то мы можем реализовать не так как нужно это конечным пользователям, и только валидация даст нам понять все было сделано как нужно или нет, с точки зрения конечного пользователя
смогла запомнить это только так veR(requirements)ification . подача материала супер!!!
То есть верификация относится к тому, КАК делать, а валидация к тому, ЧТО делать.
Если требования определяет непосредственно заказчик, а бизнес аналитик их документирует, то кто определяет нужды заказчика?
Сам заказчик/конечные пользователи это определяют. Нужды это то, что в реальной жизни должно быть пригодно к использованию для решения поставленных задач или заказчиком, или юзерами (зависит от контекста того, кто заказчик)
@@QASTARTUPITTrainingCenter Видимо какая-то тонкая грань между двумя этими понятиям существует, думаю легче будет понять на примере. Спасибо за ответ!
вот тут примеров нехватает
Футболка😸
Пора знать что ударение правильно обеспЕчение..
Странно, что требования к продукту и нужды клиента это разные вещи.
Это не разные вещи, а одно и тоже. НО, из-за того, что бизнес аналитик человек, он может допускать ошибки при написании требований, так же сам заказчик может иметь ввиду одно, а высказывать другое, и еще много факторов. Поэтому и получается, что на выходе требования не равны нуждам заказчика
Sergii Glivinskyi понятно.
А обычно сильно нервничаете сопоставляя одно с другим?
Зрозуміло пояснюється відмінність валідації від верифікації.
Очень странные определения. На основании которых можно сделать вывод что документация от БА отличается от требований заказчика..
Ещё как может отличаться, как минимум из-за человеческого фактора
@@QASTARTUPITTrainingCenter это в том случае, если БА неправильно интерпретировал требования клиента?
@@Irina-fl1ho да, или сам заказчик не уверен как в итоге должно все работать.
И еще как пример - Приложение для докторов, БА и вся тех команда не могут знать всех тонких нюансов медицины, поэтому валидация просто жизненно необходима и ее будут выполнять именно конечные юзера, то есть доктора
3:27 - Верификация - это процесс подтверждениЯ соответствия, а на слайде ошибка.
Про валідацію - те саме. 🙂
Теж хотів на це звернути увагу.
А зачем нужна валидация вообще? Если выстроены гоамотные отношения с заказчиком(тз, тп), то какие несоответствия с хотелками могут быть? Или постановщика задач на мыло.
А зачем вообще тестирование нужно, разработчики все же могут делать без дефектов)))
@@QASTARTUPITTrainingCenter Ну не перегибайте)) Просто непонятно зачем вообще тогда нужны постановщики задач (или как вы их там по-модному называете), если ТЗ не регламентирует четкое взаимодействие с заказчиком. В мое время ТЗ писали долго и мучительно согласовывали, и чем дольше его пишешь - тем меньше в итоге проблем. Ладно ГОСТ на ТЗ никто не соблюдает, но самые большие вопросы вызывает массив онлайн-курсов, в которых везде говорится о ТЗ на систему, подразумевая ТЗ на программу, это вообще вне моего понимания. Несмотря на мои вопросы (они не к вам, они скорее к общим тенденциям), ваши ролики (речь, логика мысли и тд) отличные.
@@SuperWermut Какое сейчас время? Все очень быстро. Не успел выпустить продукт быстро, ты проиграл, потому что это сделали уже другие. И они заработали деньги, а не ты (я про компании и стартапы). Поэтому и работают по Agile, все гибко и быстро и минимум документации (+ друг друга не поняли, хотелки резко поменялись и тд). Поэтому проблемы и возникают. А если будут писать ОЧЕНЬ долго требования, никому этот продукт уже не нужен будет.
@@QASTARTUPITTrainingCenter я работаю в ИТ, но в другом направлении, если у нас кривой договор на услуги с заказчиком - с нас, как с исполнителей, все соки выжмут и мы будем работать себе в убыток. Получается что в тестировании заказчик может кружить исполнителя до бесконечности, если эти работы заранее не регламентированы, не всегда же все адекватные и понимающие. Подскажите, как этот вопрос реализован в Европе (Америке)?
Во время страшного суда
Очень много воды и непонятно ничего
Бред
Спасибо!