Курс Тестирование ПО. Занятие 4. Верификация и валидация | QA START UP

✅ Подписаться на канал QA START UP - IT Training Center: kzbin.info...
Всем привет, меня зовут Сергей Гливинский, сегодня среда и это означает, что мы изучаем очередную тему нашего курса Тестирование ПО для новичков. Уже 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 #школатестирования

[@JessMystic]

Круто! Спасибо! По этой теме интересный пример был на Хабре, мне понравился: "Когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» - программа сработала, с точки зрения «валидации» - нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки." (с)

[@pffff218]

Доходчиво, респект)

[@alexalekseeva6815]

Спасибо. Вся информация по делу, понятно, и подробно. Очень приятно слушать и легко для понимания.

[@nstzyaa]

Спасибо за ваши видео! Очень кратко, чётко и по делу👍🏼

[@oksanakozlova7410]

Бомбическое объяснение! Спасибо!

[@irinas6338]

Спасибо! Наконец-то я нашла качественный и удобный источник информации. Я очень редко пишу комментарии, но в этот раз я должна Вас поблагодарить. Вы мне очень помогли понять разницу.

[@annchehova7115]

Как же все понятно вы обьясняете! Спасибо вам большое)

[@user-jx6jm1io4t]

Дякую за Ваші уроки !!

[@user-nf9fy6le5d]

Спасибо за видео!

[@juliaarte1708]

Сергей, спасибо огромное за ваш труд! Очень интересно и доступно. А главное не затянуто (что обычно отпугивает новичков).

[@ryderlochlan4721]

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

[@albertorogelio7368]

@Ryder Lochlan instablaster ;)

[@user-jy6rq5mc4o]

Почала знайомство з професією тестувальника з Вашого відео) зрозумілі та класні пояснення, важко відірватися від перегляду:) дякую за доступність автору😉😊

[@se1142]

Очень круто и понятно.

[@Jmenderinyo]

Лайк не глядя)

[@Tanya-by7pt]

Чудові схеми👍👍👍

[@user-pf8on4wb3x]

Спасибо!

[@user-mr5hl6nm3l]

Спасибо, пока всё понятно, если бы и дальше было так просто😃

[@user-qm5he2ns2i]

На 3:37 баг. Окошко с тобой закрывает концовку определения.

[@user-xl2hw5hx3k]

Спасибо большое. Очень помогли 🤣

[@selenast7561]

Я читала несколько другие определения) Верификация (Verification) - это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы. Валидация (Validation) - это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе

[@QASTARTUPITTrainingCenter]

верификация - сравнение продукта с требованиями, которые БА написал, а вся команда их изучила (но по сути это же то, что команда и собирается поэтапно делать), то что в Вашем определении. Именно поэтому и говорят еще на счет верификации: Правильно ли мы делаем продукт???, то есть в соответствии спецификации. А вот валидация это уже то что в реале нужно конечным пользователям. Поэтому все что в видео и Вы написали - одно и тоже, только по разному сказано.

[@maksymskachkov1098]

хороший курс!

[@user-qb6zk4nw6z]

Спасибо за эту тему. Коротко и ясно.

[@mercuriussphere1732]

супер!

[@dinab.8677]

Пожалуй одно из лучших обьяснений этих понятий!

[@AkhVi]

Лучшее объяснение! Спасибо огромное! Тысяча лайков 👍👍👍👍👍👍👍👍👍👍👍👍 ♾

[@goddestolyan3189]

Завтра сдаю госы, большое спасибо за объяснение С:

[@konik3138]

Коротко и очень доступно)))

[@user-ws1jd2id3o]

спасибо

[@lazerix1986]

Ни фига не понял, но было очень интересно!

[@you-tube36]

Какие есть унструменты контроля процесса Validation ?

[@chyngyzchannel1581]

МЕГАЖИРНЫЙ ЛАЙК

[@annahimic5346]

Самое лучшее и краткое объяснение что я когда либо слышала. Спасибо невероятно круто!!!!!

[@user-cu6rn8my9y]

Все просто і зрозуміло пояснили. Дякую!

[@user-qk6ir1ym3m]

Дякую, що внесли ясність в цю тему.

[@Ilya-ki2ev]

Спасибо.не как не мог запомнить и понять эти понятия

[@sergiyk5129]

хорошо, если обратная связь для проц верификации существует посредством связи разработчика и ВА, то на кого замыкается проц валидации, если условно нет прямой связи разработчика и заказчика? (только через ВА! а это верификация!)??

[@umayulchieva1281]

жалко нет примера. не понятно, чем отличаются требования от нужд заказчика, сорри (

[@SaintTrident]

а как вы прошлые видео смотрели? Сижу на скорости 1.5 улавливаю что происходит. Нужды заказчика - машина, требования - механизм, способный передвигаться. Требования мы выполнили, т.е. предоставили лошадь с полмашиной, а вот про нужды забыли.

[@mr.tuttifrutti9280]

@@SaintTrident Здорово у Вас получилось объяснить)

[@nonoali9110]

@@mr.tuttifrutti92807

[@SuperWermut]

@@SaintTrident в тз и тп должно было быть априори все обозначено, просто мало кто понимает что написание грамотного тз очень расточительно, на этом все экономят. Валидация- явление, вызванное некомпетентностью составителя тз. Как вам такое определение?

[@ooommm4102]

Спасибо, Вы очень помогаете этим курсом

[@maksimnik6417]

Где найти презентации?

[@user-yw8fw1vq4j]

Сергей, доброй день. Позвольте задать вопрос : понятия "Требования" и "Нужды заказчика" мне кажется можно все-таки приравнять,при наличие на проекте достаточно квалифицированного BA, ведь требования, по сути, это производная от анализа нужд заказчика. Если требования заказчика грамотно проанализированы и задокументированы то зачем разделение на верификацию и валидацию, мне кажется данное разделение можно упразднить путём написания технического задания максимально отражающего требования непосредственного заказчика. По сути это двойная работа. Конкретно в тестирование имею небольшой опыт, могу ошибаться. Спасибо.

[@sergiiglivinskyi6489]

Добрый день, Олег. Все верно, в идеале "Требования" и "Нужды заказчика" должны быть эквивалентны, и то что описано в требованиях, должно полностью отражать реальные потребности заказчика/конечных пользователей. Но в реальной жизни не всегда бывает так, что требования написаны на 100% идеально, даже при наличии высококвалифицированного BA. Бывает даже сам заказчик меняет очень часто требования, уже на этапе разработки и тестирования, при этом и близко не все сообщает BA. Так же представитель заказчика (например Product Owner) не всегда точно знает, что нужно конечным пользователям. В общем есть много нюансов когда мы можем получить Требования которые в полной мере не описывают того, что нужно реально конечным пользователям. В тестировании есть такое понятие как уровни тестирования, еще можно услышать такую фразу как Quality Gates. Так вот, например, Системное тестирование в компании аутсорсера будет направлено как раз на Верификацию продукта, а уже Приемочное тестирование будет проводится на стороне заказчика или конечными пользователями для определения все ли ок с продуктом для его применения в реальной жизни, а это и будет Валидация. Что бы подитожить, Верификация это проверка со стороны просто тестировщиков на стороне разработки (так как мы на 100% не можем проверить то, что могут конечные юзера, в случае сложного продукта), а Валидация - проверка со стороны конечных юзеров, правильный ли продукт они получили. Именно поэтому и разграничивают эти два понятия.

[@user-yw8fw1vq4j]

@@sergiiglivinskyi6489 благодарю за развернутый ответ!

[@user-dg2uw8jh2j]

Я с Вами согласен. Если требования отличаются от пожеланий Заказчика - значит Бизнес-Аналитик накосячил

[@user-dg2uw8jh2j]

@@sergiiglivinskyi6489 Когда Заказчик по ходу "пьесы" меняет исходные данные и набор фичей - это называется многовариантная разработка. Раньше была версия "хотелок" 1.0, где требования и пожелания ПОЛНОСТЬЮ совпадали, то после появления хотелок 2.0 появляется расхождение требований хотелок 1.0 и 2.0. И как эту неувязку тестировать, если по сути это 2 разные ПО (например, хочу, чтобы сайт был синего цвета, а теперь красный). Это косяк Quality Assurance, что хотелки 2.0 застряли "на верхах" и не оказались у всех участников разработки.

[@user-jo3ck4vo9h]

Сделайте пожалуйста субтитры к видео, а то приходится пропускать (

[@money_monke]

3:37m - 3:56m Ведущий перекрывает часть текста в блоке определения "Валидация" Глухие или слабослышащие не смогут понять, о чём идёт речь.

[@user-wo3bd6zr5m]

На 2:25 минуте зависло видео и дальше не идёт. Это только у меня такая проблема ?

[@meafery1426]

Тоже самое было. Поставь качество 1080р, мне помогло.

[@ly1360]

Что означает ADB в тестировании?

[@QASTARTUPITTrainingCenter]

ADB (Android Debug Bridge) - это инструмент, который позволяет через командную строку общаться с устройством, на котором Вы тестите софт.

[@PyCbKa1]

море позитива!

[@MrExteriors]

Но ведь требования составляются в соответствии с нуждами заказчика.В чем конкретная разница?

[@QASTARTUPITTrainingCenter]

BA человек и он может ошибаться, заказчик, который что-то излагает в своих хотелках, тоже мог подразумевать другое, в итоге часто получается ситуация когда требования уже не эквивалентны конечным нуждам юзеров. Хотя конечно, если все друг друга поняли правильно и BA не сделал никаких ошибок, то требования и нужды заказчика это одно и тоже!

[@user-ye3dv9hd6j]

Если верификация прошла успешно, почему мы не можем предположить что и валидация пройдет упешно? Если валидацию продукт не проходит в очем ошибка?

[@QASTARTUPITTrainingCenter]

потому что-то мы можем реализовать не так как нужно это конечным пользователям, и только валидация даст нам понять все было сделано как нужно или нет, с точки зрения конечного пользователя

[@natyneero6305]

смогла запомнить это только так veR(requirements)ification . подача материала супер!!!

[@unformedvoid2223]

То есть верификация относится к тому, КАК делать, а валидация к тому, ЧТО делать.

[@user-qg1jj1ih9c]

Если требования определяет непосредственно заказчик, а бизнес аналитик их документирует, то кто определяет нужды заказчика?

[@QASTARTUPITTrainingCenter]

Сам заказчик/конечные пользователи это определяют. Нужды это то, что в реальной жизни должно быть пригодно к использованию для решения поставленных задач или заказчиком, или юзерами (зависит от контекста того, кто заказчик)

[@user-qg1jj1ih9c]

@@QASTARTUPITTrainingCenter Видимо какая-то тонкая грань между двумя этими понятиям существует, думаю легче будет понять на примере. Спасибо за ответ!

[@user-jz5ih5mg8b]

вот тут примеров нехватает

[@veskras]

Футболка😸

[@akmakm7412]

Пора знать что ударение правильно обеспЕчение..

[@TuneTales_Kids]

Странно, что требования к продукту и нужды клиента это разные вещи.

[@sergiiglivinskyi6489]

Это не разные вещи, а одно и тоже. НО, из-за того, что бизнес аналитик человек, он может допускать ошибки при написании требований, так же сам заказчик может иметь ввиду одно, а высказывать другое, и еще много факторов. Поэтому и получается, что на выходе требования не равны нуждам заказчика

[@TuneTales_Kids]

Sergii Glivinskyi понятно. А обычно сильно нервничаете сопоставляя одно с другим?

[@user-zw1gf1mt3m]

Зрозуміло пояснюється відмінність валідації від верифікації.

[@Irina-fl1ho]

Очень странные определения. На основании которых можно сделать вывод что документация от БА отличается от требований заказчика..

[@QASTARTUPITTrainingCenter]

Ещё как может отличаться, как минимум из-за человеческого фактора

[@Irina-fl1ho]

@@QASTARTUPITTrainingCenter это в том случае, если БА неправильно интерпретировал требования клиента?

[@QASTARTUPITTrainingCenter]

@@Irina-fl1ho да, или сам заказчик не уверен как в итоге должно все работать. И еще как пример - Приложение для докторов, БА и вся тех команда не могут знать всех тонких нюансов медицины, поэтому валидация просто жизненно необходима и ее будут выполнять именно конечные юзера, то есть доктора

[@user.moi2007]

3:27 - Верификация - это процесс подтверждениЯ соответствия, а на слайде ошибка.

[@kharciv]

Про валідацію - те саме. 🙂 Теж хотів на це звернути увагу.

[@SuperWermut]

А зачем нужна валидация вообще? Если выстроены гоамотные отношения с заказчиком(тз, тп), то какие несоответствия с хотелками могут быть? Или постановщика задач на мыло.

[@QASTARTUPITTrainingCenter]

А зачем вообще тестирование нужно, разработчики все же могут делать без дефектов)))

[@SuperWermut]

@@QASTARTUPITTrainingCenter Ну не перегибайте)) Просто непонятно зачем вообще тогда нужны постановщики задач (или как вы их там по-модному называете), если ТЗ не регламентирует четкое взаимодействие с заказчиком. В мое время ТЗ писали долго и мучительно согласовывали, и чем дольше его пишешь - тем меньше в итоге проблем. Ладно ГОСТ на ТЗ никто не соблюдает, но самые большие вопросы вызывает массив онлайн-курсов, в которых везде говорится о ТЗ на систему, подразумевая ТЗ на программу, это вообще вне моего понимания. Несмотря на мои вопросы (они не к вам, они скорее к общим тенденциям), ваши ролики (речь, логика мысли и тд) отличные.

[@QASTARTUPITTrainingCenter]

@@SuperWermut Какое сейчас время? Все очень быстро. Не успел выпустить продукт быстро, ты проиграл, потому что это сделали уже другие. И они заработали деньги, а не ты (я про компании и стартапы). Поэтому и работают по Agile, все гибко и быстро и минимум документации (+ друг друга не поняли, хотелки резко поменялись и тд). Поэтому проблемы и возникают. А если будут писать ОЧЕНЬ долго требования, никому этот продукт уже не нужен будет.

[@SuperWermut]

@@QASTARTUPITTrainingCenter я работаю в ИТ, но в другом направлении, если у нас кривой договор на услуги с заказчиком - с нас, как с исполнителей, все соки выжмут и мы будем работать себе в убыток. Получается что в тестировании заказчик может кружить исполнителя до бесконечности, если эти работы заранее не регламентированы, не всегда же все адекватные и понимающие. Подскажите, как этот вопрос реализован в Европе (Америке)?

[@user-dh1jl4rl6u]

Во время страшного суда

[@Cngnkbhfbjjbt]

Очень много воды и непонятно ничего

[@polpoli9830]

Бред

[@user-xv5xo3tn2s]

Спасибо!