Ага, значить, коли в мене буваэ подгорає з фрази "варити до готовності", це, напевно, вказує, що я природжений тестувальник) Дякую за таке круте та зрозуміле пояснення таких тяжких для сприйняття формальних концептів! Ненавиджу документи/роботу з документацією, хочь і розумію, що це невід'ємна частина роботи тестувальника.
Дякую за відео. Зовсім недавно підписалася на ваш канал, до того вивчала тестування лише рос. мовою, бо аналогів українською не було. Рада що знайшла ваш канал і тепер можу продовжити навчання з вами.
невимовно дякую за Вашу працю!!!! я вже говорила, що проходжу платне навчання і там немає такої подачі матеріалу і стільки наглядних прикладів!!!!також хочу зауважити,що подача інформація у такій легкій формі. що можно годинами слухати уроки і не так втомлюєшься як на інших уроках! ще раз дякую, з Вашими уроками розумієш , що все можливо!!!!
Дякую за уроки солов'їною. Дуже доступно;) Виникли питання, якщо буде ваша ласка, - то я буду вдячний за відповідь)) Отже, в опису SRS#1, коли user-story переробляється в PricessFlow - чи можна цей процес описати або назвати як порядок дій, який має виконати користувач, тестермен (будь хто інший) для досягнення бажаного (вказаного в юзер-сторі) результату? Де в вимогах до ПЗ вказуються такі дрібнички до інтерфейсу як форма, колір, розмір, розташування вікон, полів, повідомлень тощо? чи вони вже коригуються в процесі розробки менеджером?
Дякую за курс! Питання: якщо на пет проекті лише юзер сторі, немає вимог, чи коректно прописати в сторі, наприклад в дужках, обмеження до текстових полів, вимоги до паролю, емейлу? Чи все ж таки писати окремо вимоги? (тестувальнику, бо більше нікому)
Чула думку, що якраз не варто чітко прописувати кольори та фігури, бо може бути прийнято рішення про зміну дизайну і тоді БА треба переписувати для тестувальників усі сторі. Що думаєте з цього приводу, як у вас було на практиці?
Не люблю багато абстракції, люблю конкретику. Але це роблять БА тому хай роблять як їм краще) наше діло читати і виконувати, докопуватись до помилок а не до підходу
Виникло два питання щодо слайду "тестування віимог: перевірка документації". 1. Що значить "перевірка на необхідність"? у Вас була фраза "якщо щось, не є необхідним, ми це відкидаємо" - якось так; як ми можемо відкинути функціонал, якщо його визначає замовник; якщо він визначає, що щось є необхідним, значить це необхідно, хіба ні?... 2. Що означає "Перевірка на реальність"? "вимоги повинні описувати, нскільки можливо реалізувати функціонал..." Мається на увазі, що виконавцем оцінюється реалістичність вимог замовника?
1. Може бути написане щось не потрібне, там не цитати замовника, а іх інтерпритація словами бізнес аналітика. Не знаю який приклад навести.. Припустимо, «в поле пароль можна вводити будь-які символи» буде не потрібним, якщо поряд є вимога що пароль обов’язково складається з літер, чисел і спецсимволів
2. Ну якщо в вимогах сказано що замовник хоче завантаження стрінки зі швидкістю світла, то це не реально. Є багато прикладів, які можуть навести розробники, але вони всі «розумними словами» і з назвами технологій, рядовий тестувальник не зрозуміє
«Усміхаються глобусові Школярі на уроках, І сонце, Неначе глобус, Усміхається школярам, А за вікном Реве повесіння, Вантажене снігом і кригою, Та лісом тріск іде - Нові проростають проліски.».
Про фон я для простоти сказала, зазвичай нема в тестувальників вимог про фони, там частіше функціональні вимоги. Але так, якщо мова йде про фон, то можемо спитати відтінок)
З приводу слайду "Тестування вимог: аналіз поведінки системи": який "геній" вигадав схему, в якій є фраза "дитина помирає"? Дуже невдала, непотрібна і недоречна (особливо зараз в Україні) аналогія.
Філософський слайд, насправді. З життям ми також отримуєм і смерть. Так шо "дитина помирає" у любому разі, на жаль. Це лише питання часу. P.S. Це, взагалі, баг вселенських масштабів. Напевно у господабоженьки офіс тестувальників десь у Індії розташований😁
Але ж коли дев пояснює реалізацію, то це далеко не завжди призводить до розуміння тестувальником. Дев розмовляє іншою мовою, Quality Assurance Engineer іншою
Уроки з тестування ПЗ, що не мають аналогів. Дуже якісно і доступно. Дякую!
Добрий день, на 0:24 побачив картинку котика то сміявся хвилин 5) Дякую що підняли настрій) п.с. лекції супер, дуже подобаються)))
Ага, значить, коли в мене буваэ подгорає з фрази "варити до готовності", це, напевно, вказує, що я природжений тестувальник) Дякую за таке круте та зрозуміле пояснення таких тяжких для сприйняття формальних концептів! Ненавиджу документи/роботу з документацією, хочь і розумію, що це невід'ємна частина роботи тестувальника.
Дякую за відео. Зовсім недавно підписалася на ваш канал, до того вивчала тестування лише рос. мовою, бо аналогів українською не було. Рада що знайшла ваш канал і тепер можу продовжити навчання з вами.
Рада бачити тут!)
Ви дуже хороший вчитель. Пiсля роботи я вiдпочиваю переглядаючи вашi вiдео. Дякую.
Уроки супер круті, ви закохуєте в професію тестувальника. Дякую Вам!!!
Коментар на більше ніж чотири слова. Дякую.
З ваших відео я дізнаюсь більше ніж на онлайн заняттях в it- академії . Дякую вам !!!
Дякую, все доступно, цікаво і легко сприймається, обожнюю ваш канал!
Дякую за зрозумілі пояснення та чудові приклади!
Величезна подяка Вам! За якісний концентрат інформації в визначеному її секторі.
Дякую за українську мову. Вивчаю програмне тестування у штатах, цікаво співчувати термінологію
Нікому не писала ніколи коментарі, але вам напишу. Ви найкраща!! Дякую за вашу якісню роботу!
Дякую))
Дякую за "прозоре" і зрозуміле пояснення теми. Зокрема, щодо Acceptance Criteria. Має бути корисною логічною основою майбутньої роботи.
невимовно дякую за Вашу працю!!!! я вже говорила, що проходжу платне навчання і там немає такої подачі матеріалу і стільки наглядних прикладів!!!!також хочу зауважити,що подача інформація у такій легкій формі. що можно годинами слухати уроки і не так втомлюєшься як на інших уроках! ще раз дякую, з Вашими уроками розумієш , що все можливо!!!!
Дякую за урок. Дуже зрозуміле пояснення User Stories.
Дуже круто, особливо дякую за таймлайни!)
Класна подача матеріалу, дякую за Ваші знання!
Дуже круті уроки! Дякую за контент Українською!
залишаю коментар, дякую, все зрозуміло і наочно 👏
Велике дякую!!! Як завжди, одне задоволення!
Дуже круто та позитивно) Дякую за вашу роботу
Чітко, ясно, феєрично,Дякую 😊
Дякую за такі детальні пояснення ❤
Велика робота. Когспектую. , дуже дякую
Супер. Ще коли вчився в Tommy, подобались твої лекції
Лайк! Ще окрема подяка, що з гумором (картинка про ТЗ від замовника) 😉
Дуже якісно і доступно. Дякую!
Чітко і доступно викладено матеріал! Супер!
Ви проробили неймовірну роботу, дякую! ❤️
Дуже круте пояснення, дякую вам за це відео :)
Ви реально крута!) За українську окремий респект!)
Дуже круті уроки! Дякую😊
❤❤❤❤❤❤❤❤❤❤
Дякую! Все зрозуміло і просто!
Класний курс та хороша подача. Діаграма "Життя людини" - жорстко.
Ну аналогія з життям,люди помирають,це не жорстоко це природно.
Дякую + дякую + дякую + дякую = 4 дякую!
🥰😂❤️
дякую. цікавий і корисний урок
Цікава тема, все зрозуміло, дякую!
дякую!
Дякую за контент Українською!
таку обширну інфу наврядче де отримаєш! Жму краба вчительці🦀🦀🦀
Дякую за уроки солов'їною. Дуже доступно;)
Виникли питання, якщо буде ваша ласка, - то я буду вдячний за відповідь))
Отже, в опису SRS#1, коли user-story переробляється в PricessFlow - чи можна цей процес описати або назвати як порядок дій, який має виконати користувач, тестермен (будь хто інший) для досягнення бажаного (вказаного в юзер-сторі) результату?
Де в вимогах до ПЗ вказуються такі дрібнички до інтерфейсу як форма, колір, розмір, розташування вікон, полів, повідомлень тощо? чи вони вже коригуються в процесі розробки менеджером?
Дякую за курс! Питання: якщо на пет проекті лише юзер сторі, немає вимог, чи коректно прописати в сторі, наприклад в дужках, обмеження до текстових полів, вимоги до паролю, емейлу? Чи все ж таки писати окремо вимоги? (тестувальнику, бо більше нікому)
Якщо це пет проект, то перше питання чи потрібно вам їх прописувати? А далі вирішуйте де зручніше вам їх шукати в майбутньому, там і пишіть)
Чула думку, що якраз не варто чітко прописувати кольори та фігури, бо може бути прийнято рішення про зміну дизайну і тоді БА треба переписувати для тестувальників усі сторі. Що думаєте з цього приводу, як у вас було на практиці?
Не люблю багато абстракції, люблю конкретику. Але це роблять БА тому хай роблять як їм краще) наше діло читати і виконувати, докопуватись до помилок а не до підходу
Дякую за зрозуміле пояснення!
В кінці курсу буде сертифікат про проходження курсу?))
Тільки в випадку практичного курсу))
@@Popeliuha у Вас є ще практичний курс?
Якщо можна детальніше напишіть будь ласка
Виникло два питання щодо слайду "тестування віимог: перевірка документації". 1. Що значить "перевірка на необхідність"? у Вас була фраза "якщо щось, не є необхідним, ми це відкидаємо" - якось так; як ми можемо відкинути функціонал, якщо його визначає замовник; якщо він визначає, що щось є необхідним, значить це необхідно, хіба ні?... 2. Що означає "Перевірка на реальність"? "вимоги повинні описувати, нскільки можливо реалізувати функціонал..." Мається на увазі, що виконавцем оцінюється реалістичність вимог замовника?
1. Може бути написане щось не потрібне, там не цитати замовника, а іх інтерпритація словами бізнес аналітика. Не знаю який приклад навести.. Припустимо, «в поле пароль можна вводити будь-які символи» буде не потрібним, якщо поряд є вимога що пароль обов’язково складається з літер, чисел і спецсимволів
2. Ну якщо в вимогах сказано що замовник хоче завантаження стрінки зі швидкістю світла, то це не реально. Є багато прикладів, які можуть навести розробники, але вони всі «розумними словами» і з назвами технологій, рядовий тестувальник не зрозуміє
@@Popeliuha Дякую! Взагалі курс надзвичайно класний!
@@КирилоЛатишев-щ1з дякую;)
Доброго дня! Таке питання, якщо в компанії немає бізнес аналітика, то хто має писати acceptance criteria?чи може писати тестувальник дужун?
Продакт овнер. Тестувальник джун теж може, якщо є потреба
«Усміхаються глобусові
Школярі на уроках,
І сонце,
Неначе глобус,
Усміхається школярам,
А за вікном
Реве повесіння,
Вантажене снігом і кригою,
Та лісом тріск іде -
Нові проростають проліски.».
Доброго дня. Перепрошую, я геть не зрозуміла, яким чином правило 5-ти питань допомагає подрібнити велику задачу на невеликі підзадачі
Правило 5 питань уточняє нашу задачу, допомагає знайти корінь, причину проблеми. А коли зробили висновок, то уже можем розбити задачу на підзадачі
Дякую!
Питання: "червоний фон" передбачає чітко визначений відтінок червоного, який варто вимагати у замовника?
Про фон я для простоти сказала, зазвичай нема в тестувальників вимог про фони, там частіше функціональні вимоги. Але так, якщо мова йде про фон, то можемо спитати відтінок)
Підкажіть будь ласка, чи можна перевірити вимоги, написавши тест кейси для перевірки цих вимог? Буду вдячна за відповідь
Не пишуть тест кейси на перевірку вимог)
@@Popeliuha Дякую. Ось таке тестове завдання кинули одному знайомому)
16:53 Наукові діаграми що схожі на shitpost 😂
З приводу слайду "Тестування вимог: аналіз поведінки системи": який "геній" вигадав схему, в якій є фраза "дитина помирає"? Дуже невдала, непотрібна і недоречна (особливо зараз в Україні) аналогія.
Це приклад з інтернету. Не вдалий, але наглядний
Філософський слайд, насправді. З життям ми також отримуєм і смерть. Так шо "дитина помирає" у любому разі, на жаль. Це лише питання часу.
P.S. Це, взагалі, баг вселенських масштабів. Напевно у господабоженьки офіс тестувальників десь у Індії розташований😁
Але ж коли дев пояснює реалізацію, то це далеко не завжди призводить до розуміння тестувальником. Дев розмовляє іншою мовою, Quality Assurance Engineer іншою
ну дуууууже мілашний голос)
Дякую, все доступно, цікаво і легко сприймається, обожнюю ваш канал!