🐞 П’ятнична флудильня для QA-спільноти #10. Як «ідеальні» процеси тестування із підручників адаптувати до реальності?

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт, друзі! 🙌
Продовжуємо зустрічатися щоп’ятниці усією спільнотою тестувальників тут, на форумі, щоб обговорити актуальні питання, ділитися досвідом та корисними лайфхами.

Тема на сьогодні: У підручниках та документації по тестуванню часто процеси розписані доволі зрозумілими та не важкими у виконанні. Але в реальному житті — не завжди все працює за планом. Розповідайте, як теоретичні знання переносили на практику. Що спрацьовувало добре, а що не дуже? Діліться в коментарях!

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А можна стартувати тему по п’ятницях раніше, а не ввечері? Думаю, багато хто о 19:30 вже «всьо».
Я кілька разів бачу цікаві п’ятничні топіки, але бачу їх вже в понеділок під обід.
Щодо адаптації «ідеальних» процесів — то тут be agile: спробуй використати все, про що читав. Непотрібне само відвалиться, потрібне — само приживеться. Та і всі процеси мають задовольняти та вирішувати якісь проблеми (про які команда може навіть не здогадуватись). Якшо складна бізнес логіка, про яку забуваєш через 3 спрінта — пиши деталізовані тест кейси.
Якщо регресія виконується досить часто — тримай під рукою всеосяжний чекліст.
Якщо тестування займає надто багато часу — закладайте час в естімейти.
Якщо розробник імплементує шось по своєму, відмінно від бачення продакт оунера та QA — робіть shift left testing, проводьте ревью сторі так ретельно, описуйте так детально, щоб розробник не міг зробить крок в сторону.
Тож адаптація процесів — тільки через «спробувати» в реальності. Щось приживеться, і буде «брінгать бізнес велью», щось буде очевидно непотрібним.

дякую за фідбек. будемо раніше випускати 😉

Очікування:
Є етапи тестування (планування, аналіз, дизайн, імплементація, виконання, закриття). Як каже advanced syllabus від ISTQB — іноді деякі фази можуть іти паралельно.
Реальність: вони завжди ідуть паралельно, іноді всі одразу, іноді менеджмент і клієнт здатні запускати ці процеси ззаду наперед. Іноді ти просто потрапляєш в тест процес, далі нічого не пам’ятаю, все як в тумані ... і вже реліз

Тест план написаний, але жити по ньому-те ще завдання у Agile проекті..

А что, я зря его писала?) Вот только после этого его надо по факту через неделю переписывать, так как бизнес его почитал и добавил нагрузки

ооо, у Вас бизнес читает тест план?!_)

Automation first дуже важко втілити на практиці

Підписатись на коментарі