Насправді, дуже цікаве питання. Але якщо копнути трішки глибше, стає зрозуміло, що проблема криється не стільки в самих техніках тест-дизайну та складності їх впровадження, скільки у вмінні побачити, де саме вони будуть найбільш доречними. Звідси й випливає, що вивчити техніку та її механізм — це ще не означає бачити, де її ефективно застосувати. Саме тому граничні значення й є фаворитом, адже обсяг аналізу, необхідний для їх застосування, є мінімальним.
А от такі штуки як pairwise, decision table, чи state transition вже вимагають значно глибшого розуміння системи та вміння виділити ключові взаємодії чи стани. Тут вже не обійдешся просто знанням «що це таке», потрібно ще й чітко бачити, де їх застосування дасть найбільший ефект і покриття. Тому й не дивно, що вони використовуються рідше, особливо тими, хто ще тільки набирається досвіду.

Цікавий досвід.
Розкажу свою історію підготовки та здачі сертифікації.
Ще на курсах, назвімо їх «Війти в IT через QA», викладач розказував студентам про ці магічні пʼять літер і яку цінність вони мають. Проте, на щастя, він давав правильний посил, що не треба йти на сертифікацію одразу після курсів чи навіть до 1 року комерційного досвіду.
Тому в моєму випадку я наважився на здачу аж через 3 :)
Після того як я остаточно вирішив що буду здавати ISTQB FL пройшовся по варіантах підготовки. Вибір був достатній: від курсів на Udemy/Prometeus, великих IT шкіл і до індивідуальних.
Я зупинився на курсі підготовки від О. Ковальової Certified Unicorns, і це на мою думку, найкращий вибір.
Чому?
Живі вебінари, актуальна інформація з мега великою кількістю прикладів з життя.
Тести для контролю засвоєного матеріалу і пробні сертифікації.

Придбав я купон на сертифікацію з додатковою спробою (оплачувала компанія:) ), проте це було зайвим.
В день Х сертифікацію було здано.
39/40

Підсумовуючи, шлях підготовки був, однозначно, продуктивнішим, інформативнішим та цікавішим, ніж сама сертифікація та успішна здача.
Більшість, топіків з силабусу були впроваджені на проєкт. Та працюють і надалі, після мого звільнення.

Чудова стаття.
Дякую за цікаву інформацію)

Таких довідників не бачив, проте ніхто не скасовував вікіпедію :)
Моя пропозиція використовувати ISO код валюти (USD, GBP, UAH). Таким чином можна уникнути зміни місця написання символу, та й не треба забувати, що деякі валюти мають однаковий символ. Для прикладу: $ (долар) є не лише у США, але й у Канаді, Новій Зеландії, Австралії, Сінгапурі... І для позначення валюти лише одного символа буде точно не достатньо.

Я був на одному з перших своїх проектів одним QA. Досвід цікавий, проте нікому не рекомендую такої історії коли ти джуніор, практично без досвіду. На щастя, на проекті досить «повільний» темп розробки, я встигав, попри основної діяльності на проекті, ще й додатково проходити онлайн курси. Може звучати досить смішно оскільки на проекті лише я QA, але налаштував процеси тестування на проекті) шкода, що менеджмент не помічав позитивних змін. Що в стало причиною зміни проекту.