Та ви ж не з роботами працюєте, а з людьми. І фейлити проекти будуть люди, бо у одного рибкалка, у іншої дитина захворіла. І витягати проекти із дупи теж будуть люди, бо один відповідальний сам по собі, друга вас поважає, третій не звик терпіти поразки. Розумієте? А не тому що вони Selenium знають. Selenium всі з них знають, або можуть опанувати в мінімально короткий строк.

Давайте рівнятися на кращих, саме в компаніях з західними цінностями людям набагато комфортніше працювати

Це що за комплекси меншовартості? І як це фото в резюме призводить вас до висновку про західні цінності, які краще ніж українські? В Україні треба рівнятись на український менталітет, клієнта, ринок. Не на американський. От якщо мені доведеться наймати американців, працюючи у Гуглі десь у Пало-Альто, то звичайно, буду орієнтуватись на місцеві стандарти і рекомендації.

дискримінація по будь яким ознакам ( в тому числі по знанням з рибалки чи кінематографу

та яка ж тут дискримінація? :) Тут тема для розмови і можливість задати творчі питання при чому на комфортному для кандидата полі.
От дивіться:

— які види тестування провалили перші версії матриці?

На мою думку, сфейлились usability або performance (soak чи resilience) тести. Чому я дійшов такого висновку.
Usability — система була спроектована і розроблена як заплановано. При чому людям було заготовлене щасливе життя, повне насолод. Проблема полягала в тому, що люди не захотіли такого продукту, і страждання були необхідною невід’ємною частиною. Поведінка клієнта не була очевидною для машин, що і стало причиною change request на більшу кількість імперфектності.
Performance (soak або resilience) — можливо були прототипи і вони показували гарні результати. Але не була перевірена робота системи на довгому відрізку часу. І машини не побачили, що у людей накоплюється роздратованість ідеальним життям. Або вони тестували на малій вибірці і не побачили проблем, які виникнуть на великій вибірці данних.
І тут є декілька моментів. По-перше правильної відповіді не існує. По-друге, я вам продемонстрував свої скіли thinking out of the box, problem-solving та stress resistance. По-третє, я відсік стандартні теоретичні питання, відповідь на які можна просто завчити (і на які ви точно вже завчили, якщо це не перше ваше технічне інтервю). Якщо ви вступите зі мною в полеміку — тим краще, я побачу як ви відстоюєте свої ідеї, як ви їх врешті-решт узгодите з іншою людиною. Це все — прототипи реальних кейсів, які вам зустрінуться в команді і в роботі.
А всю ту рутину накшталт вибору селекторів можна легко запихнути у тести або тестове завдання. Навіщо на банальну базу витрачати час менеджера?

Базуючись на чому ви таке пишете?

Базуючись на тому, що в переважній більшості люди не тренують цю навичку окрім як під час пошуку роботи (читай раз на 1-2 роки або навіть рідше). Тому нема ніяких передумов, що з грейдом також покращується цей навик якось по дефолту. Резюме у переважної кількості сеньорів, що я читав, такі нічемні, що якби не досвід, яким дійсно людина володіє (і про який я вже запитав заздалегідь у рекрутера), то я б взагалі його одразу у смітник відправляв (це стосується українських резюме). Ну не реджектять у нас сеньорів по резюме (а тим паче ще більш високі позиції, за якими на людей полювати треба).
От скажіть, якби вам кандидат сказав, що рік тому він 2 тижні (1 місяць) витратив на роботу з Selenium, ви б вважали, що він гарний експерт у роботі з цим фреймворком? Думаю, що ні. А чому ви впевнені, що з резюме воно працює по нішому?
Знову ж таки ви ж погодитесь, що усі, геть усі проекти без виключення мають проблеми з документацією, костилі, якісь застарілі рішення, які мало хто спроможен розшифрувати і підтримувати, цілий беклог дефектів, які ніхто не буде фіксити ніколи? От так само і з резюме. Їх майже ніхто не вміє писати. В Україні так точно. Кандидати знаходяться в неадекваті, менеджери також знаходяться в неадекваті. Рекрутери якось намагаються всіх привести до загального знаменника і в них теж виходить з перемінним успіхом, от так і працюємо :)

як то писати про хоббі чи ставити фото, що взагалі моветон

Обожнюю, коли є фото в резюме. Чого це одразу моветон? Моветон це у Штатах, де є низка антидискримінаційних законів, і де за це можуть притягнути до відповідальності, тому кандидатів максимально «деперсоніфікують». Хоббі також може послужити приводом для дискусії. Більш того розкажу вам такий кейс. Наймали людину на досить високу позицію, яка серед іншого займалась рибальством, прям дуже полюбляла, змагання, всі діла. Так там була умова, що коли умовно йде сезон рибалок, то вона бере відпустку і жоден проект не повинен на цю відпустку впливати, не важно там спрінт це, чи реліз, чи ще щось. Як вам таке хоббі, яке впливає безпосередньо на роботу?

Джун — це людина, яка має принаймні кілька місяців досвіду комерційної розробки

Я писав аргумент про рік, бо це мало б хоча б якийсь сенс. Якщо ви орієнтуєтесь, ще на менший строк (3-6 місяців), то це висвітлює вашу позицію до найму ще в гіршому світі. Ми ж не копачів чи грузчиків наймаємо, де навчити можна за кілька тижнів. Горизонти планування повинні бути довшими.

Джунам зазвичай такі прості поради вже не потрібні, вони вміють складати резюме.

Тетяно, за рахунок чого джуни вміють оформляти резюме краще ніж трейні? В більшості своїй жоден з грейдів за замовчуванням не вміє складати резюме, хоч джун ти, хоч сеньор, хоч СТО. Чи ви цій навичці (оформлення резюме) спеціально тренуєте в своїй компанії?
Здається помилка саме в вашій термінології. Наймають на позицію Junior, Middle, Senior. А от хто була людина до того, як прийшла на позицію, то справа вже зовсім інша. Ви не можете людей судити — от ти трені, ти джун. Ви обираєте чи підійде людина на вашу позицію Trainee/Junior Engineer, а хто людина була до того — судити колишньому роботодавцю.

І ще в мене враження, що ви хороший знайомий Галини, чи помиляюсь?)

В перший раз Галину бачу, і бажаю їй вдалої кар’єри.

Якщо дотримуватись умовного сценарію, який ми тут з вами розробили, то так, взяв би.
Щодо ООП і тестувальника, то там можна розвиватись в автоматизацію, а ще трохи подалі — в SDET. Там вже ООП — робочий таки концепт. Ми ж не уточнили чи це manual чи automation позиція, так?
І взагалі на співбесіді треба виштовхати кандидата за межі його зони комфорту, щоб по-перше більш точно розуміти, наскільки глибоко сягають знання, а по-друге — побачити як людина працює з невідомим або в стресовій ситуації. От ви наприклад, вирішили зробити таке ментальне айкідо і перевести мою увагу з суті моїх питань до їх доцільності. Якщо ви не тестувальник, то ок, ви і не зможете на них відповісти (хоча, нє, брешу, про Архітектора, Сміта та staging повинні всі знати).
Тим не менш, навіть в жартівливому діалозі на dou ви потенційно втратили як умовний кандидат на софтскілах. Вам доведеться бути дуже крутим на хардскілах, або майже не мати конкуренції, щоб отримати офер від мене.
А почалася наша дискусія якщо пам’ятаєте з того навіщо хоббі. А от саме такі «цікавинки» як хоббі, якісь невластиві технології в резюме, фото, і відрізняють одних кандидатів від інших і дають варіанти проведення співбесіди

Звісно візьму, тільки зможете відповісти на декілька запитань:
— які види тестування провалили перші версії матриці?
— в якій сцені нам показали dev/staging enviroments?
— як би ви назвали підопічних Меровінгена категоріями тестування?
— яку концепцію тестування уособлює Нео?
— яку роль в команді розробки займав би персонаж Архітектора?
— яку парадигму ООП порушував агент Сміт?
Якщо б ви змогли відповісти на ці питання, офер був би у вас в кармані :)

блін, відповів на ваш комант вище, давайте в тій гілці подискутуємо

Тетяно, давайте так: і ваше і моє бачення існують в рамках бізнес-моделі наших компаній та команд і звісно ж мають право на життя. Тож я припускаю, що ваша система працює для вашої компанії. Тож тут мої роздуми.

Згідно статистики dou 90% Junior QA мають до 2 років досвіду роботи. Після 1 року досвіду половина джунів починають себе позиціонувати як Middle QA. Спираючись на ці дані, я можу стверджувати, що половина найактивніших, впевнених в собі QA мають сили подаватись на позиції мідлів. А решта, яка після року роботи йде на знову ж таки позицію джуна — це або невпевнені в собі люди, яким важко дається це ремесло, і таким чином ви набираєте собі не нкйкращих кандидатів, а кращих з гірших, або (скоріше навіть не або, а також) ставите себе в позицію, коли через півроку-рік людина запросить зарплатню мідла (а здебільшого це буде приріст зарплатні в 50-100%). Є велика ймовірність, що ви відмовите людині в таком підвищенні і вона піде, тому вона піде деінде.

Хто такі трейні, я звісно ж знаю. Я знову ж таки, якщо ви подивитесь статистику dou, то побачите, що їх апріорі на існує з досвідом хоча б рік. І власне спираючись на здоровий глузд і власний досвід, можу стверджувати, що позиція трейні закінчуються з випробувальним терміном / онбордингом, тобто через 3 (в деяких випадках — через 6) місяців. Скоріше за все, якщо у людини не зрослось з компанією і вона з неї йде, то ви і побачите є у себе в воронці як джуна з 1 роком досвіду (ви ж не вірите, що всі пишуть правду в резюме, так? :)). І взагалі, чого людина буде залишати команду через рік роботи? Щось не так в команді? Щось не так в людині? Якщо навіть взяти співвідношення «у мене була токсична команда / нудна робота» проти «цей джун щось сам собі навигадував та пішов», то шанс того, що саме джун навигадував, він статистично більший. І чи не побоюєтесь ви тоді, що ваша команда не виявиться для нього токсичною / нудною? Для мене така людина дає більше ризиків. Мені простіше (надійніше) навчити з нуля перспективну людину, яка буде мені вдячна. Джун з 1 роком досвіду на ринку для мене є менш перспективним і більш ризикованим.

Хай би там як. Що трейні, що джун, сам грейд каже про те, що людина не зможе виконувати свою роботу самостійно, без нагляду, і зі швидкістю, необхідною команді. Якщо може — то ви просто взяли мідла, який не вміє себе продати (і тут таки існує ринок таких людей, заперечувати не буду). Інший варіант, коли джун з роком досвіду може вам підійти (я все ж таки думаю, що то вже мідл) — це ви робите щось дуже ... поширене і скіли ,які потрібні вам, дуже легко трансферяться з інших компаній. Нажаль у випадку моєї компанії це не так (ну нема на ринку джунів з 1 роком досвіду, які б знали як тестувати голосових чатботів, та знали 2 іноземні мови на рівні B2+).

Повертаючись до мого коменту і вашої відповіді. Сильна сторона у джуна може бути відносно всіх інших його якостей (може ви це мали на увазі?), але це скоріше за все буде все ж таки недостатньо для того, що вимагають задачі, що джун буде вирішувати (і його все одно доведеться пильно опікати). І як я казав, окремий ризик — це взяти джуна 1 роком досвіду, не маючи для нього позиції через півроку-рік і втратити його. Я конкретно в своїй компанії і своїй команді маю концепцію розвитку людини з нуля до мідла за 1-2 роки (в ідеальних випадках — до сеньора за 2-3 роки) і я сприяю іх підвищенню в рамках компанії на більш технічні і челенджеві позиції. Тому 3-6 місяців умовного трейні-досвіду, це не те, за чим я би став ганятись при співбесіді. Можливо є сенс в вашій стратегії за умов бюджетування (може так воно дешевше? треба рахувати). І чи це причина, чому ви шукаєте досвідченого джуна?

Я (інтерв’юер) люблю ДжоДжо, Матрицю і хокей, ви вказуєте це в хобі чи згадуєте під час співбесіди. Ви вже мені рідніший за інших кандидатів, і набрали кілька балів по софтскілах.

Дуже гарний, персональний приклад вийшов. Таких статей багато не буває. Є трохи що доповнити.

Розберу по тексту.

Про резюме:

У вас досить непоганий взірець резюме. Єдине що, додавайте побільше контактів. У вас наприклад не вистачає Telegram або Whatsapp (залежно від ринку, країни, може бути специфіка у месенджерах).

По питаннях:

• про книжки:
  Краще, щоб у вас були заготовлені 2 книжки (мінімум). Одна — на довільну тему, яка свідчить про ваші вподобання. Це може бути художня література, публіцистика, научпоп, і т.д. Друга — обовз’яково профільна (і якщо ви QA — хай це буде не Роман Савін :) ).
• про роботу в команді чи одному:
  Якщо ви джун, то скоріше за все фіг знаєте як вам краще. То я б рекомендував запитати в HR, в яку команду в подаєтесь і відповідно з hiring manager вже видати той варіант, який підходить під формат команди. Або принаймні сказати, що в команді звичайно прогресувати легше за рахунок менторства/навчання у більш досвідчених колег, але за необхідності ви самостійно також зможете.
• чому обрали компанію:
  Тут треба трохи потренирувати навичку підмічати особливості обєкта. Наприклад, позиція в якийсь маленький, нікому невідомий стартап на 10 людей — люблю дух креативу як у вас, ненавиджу бюрократію. Йдете в велику компанію — ненавиджу стартапи, там безлад, люблю поставлені процеси, документацію та причетність до великого колективу. І в такому дусі. Причому ви це не впарюєте співбесіднику, ви дійсно для себе виділяєте переваги саме даної компанії (для цього фокусуйтесь саме на перевагах та особливостях компанії). Радше не фокусуватись на плюшках, офісі, соцпакеті (ви джун, це все ще не для вас, в плані, це не та мотивація, задля якої ви повинні обирати компанію), а на процесах, місії, цінностях, стилю роботі, особливостях проекту і т.д. І взагалі джуну задача мінімум — отримати офер і здобути свій перший рік досвіду роботи, потім і легше буде і дійсно вже зрозумієте, принамйні, що вам не подобається у форматі компаній, в якій ви пропрацювали. Не перебирайте вакансіями, це не ваш ринок. Є офер — погоджуйтесь. Є якісь дуже мізерний шанс, що вам кілька оферів прийдуть з різницею в кілька днів, але це прям супер рідко.
  

Про підбір вакансій та відправку резюме:

10 відгуків в день — це досить непоганий темп і достатній мінімум. Але з огляду на ринок я б рекомендував відправляти на всі нові вакансії, які знаходите (принаймні на dou та djinni) в день виходу, кожен день, без вихідних. Якщо ви не відправили. 300+ резюме за місяць, то вважайте, що ви і не виходили на ринок праці. Будьте впевнені, що якщо ви це зробите, то вже обійдете, переважну більшість своїх конкурентів.

Перехід до співбесід:

Якщо кожне 10 резюме призводить до скрінінгу (вам написав рекрутер), то резюме у вас ок. Значить можна вже не заморочуватись над його вдосконаленням. Якщо після першого тижня розсилок ви не отримали жодного відгуку від рекрутерів, то щось у вас там категорично не так. З чого можна почати — це передивитись список вакансій і перевірити чи є у вас більшість з вимог у резюме (не додавайте їх без розбору, а переконайтесь, що ви зможете відповісти на базові питання з теми, заодно і підтягнетесь по теорії).
Наступний етап — навчитись проходити скрінінги. А це — мати під рукою оті основні питання а-ля зарплата, готовність працювати в офісі, рівень англійської, чи відкритий ФОП і таке інше. Якщо кожен 2-3 скрінінг (переписка в месенджері/пошті/Linkedin) призводить до співбесіди з HR, то і тут у вас все ок.
Якщо 70-80% рекрутерів переводять вас далі до технічної співбесіди, то зі софтскілами, персоною і цінностями у вас теж все ок. Якщо ні — передивляйтесь онлайн-інтервю в youtube, питайте фідбеку під час інтервю у рекрутерів. Обовязково записуйте питання, які почули, можете навіть ввімкнути запис аудіо з вашого компа/ноуту або хоча б диктофон на мобільнику. Не повинно залишитись питань, на які у вас не було б швидкої, короткої відповіді. Ваша ціль на HR інтервю — ввести себе в режим людини «з гарячим серцем, широко розплющеними очима, яка рветься в бій і буде вдячна за надану можливість».

Технічні завдання:

В залежності від того, як вам його видали — уточніть строки виконання, форму здачі, конкретизуйте саме завдання (це те, що ви будете робити і безпосередньо на роботі, тому вже тренуйтесь). Завдання виконуйте сумлінно, з натхненням. Обовзяково зробіть основний блок, який від вас просять і потім додайте частину «з зірочкою» — якійсь інший підхід до виконання, ваша пропозиція по вдосконаленню, ваші роздуми щодо можливої подальшої роботи над завданням.
Дуже важливо — не кажіть щось в дусі «скільки ви мені заплатите за завдання», чи «це тягне на тиждень повноцінної роботи». Тобто ніякого скиглення. Якщо думаєте, що компанія дійсно знахабніла, просто обгрунтовано скажіть, що відмовляєтесь робити це завдання з таких-то і таких причин. Скоріше за все це кінець вашого хайрінгу, але зробіть його чемно.

Технічні співбесіди:

Знову ж таки. Це ок, якщо ви провалите перші співбесіди. Налаштуйте себе, що йдете на марафон і перші співбесіди — це ваш розігрів. Тут головне — зрозуміти перелік питань і мати на них коротку, зрозумілу відповідь (яку ви зможете розвернути під час співбесіди або уточнюючих питань). Кожне нове запитання записуйте, аналізуйте та розбирайте. Буквально через 5-10 співбесід навряд чи залишаться запитання, які будуть ставити вас в тупік. Велика ймовірність, що офер ви отримаєте, ще до того, як покажете себе з найкращого боку. Десь тут на dou була тема з 250 запитань по QA чи щось таке, опрацюйте її на рівні джун-мідл.

Питання інтервюеру:

Обовзяково, обовязково, ОБОВЯЗКОВО задавайте питання інтерв’юеру наприкінці сесії. Якщо не задасте, то у вас оцінять як низькомотивовану людину, що не цікавиться компанією, це майже 100% reject. Якщо ви ну дуже сподобались, то вам підкажуть, що краще все ж таки запитати, або навіть скажуть які питання від вас очікували, але по-перше — це рідкість, по друге — враження про себе ви вже зіпсували.
Той список, що записали ви — це питання до рекрутера.
У наймаючого менеджера можна (треба!) запитати таке:

• як виглядає команда (вас більше за все цікавить скільки в них QA, і якого вони досвіду)
  
• чи є випробувальний термін і що вони від вас очікують в його кінці
  
• як буде виглядати ваш типовий робочий день (це про ваші обовязки, а не про те, яке смузі ви будете пити)
  
• кого б вони хотіли бачити в команді (або що для них нійбільш важливе в кандидаті)
  

• що за технології
  
• що за проект
  
• Scrum не Scrum
  
• чи є автоматизація
  
• вся інша маячня, яка нібито вмовить вас відмовитись від майбутнього оферу.
  

Сподіваюсь комент буде корисним. Всім вдалого тестування і швидше знайти свою першу роботу.

Відповідь про сильні сторони від джуна QA — про фреймоврки? Ви серйозно? І взагалі, навіть якщо не QA — джун, фреймоврки, сильна сторона? Та це ж самообман. І бізнес-процеси туди ж. Єдине, що треба зрозуміти про технічіні навички джуна це:
а) він (вона) вчили той напрям, який ви застосовуєте в роботі
б) згідно відповідей, начебто людина здатна до навчання.
Ну які технічні навички у джуна можуть бути сильними?

Взагалі не дивляться на хард скіли :)

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

То у вас його поки що нема просто :)

А постійно розсилали резюме — це скільки? Хоча б сотню резюме на тиждень розсилали?

З вашого коменту випливає, що у вас не з делегуванням проблема, а з тим, що люди працювати не хочуть. Якщо запитання, як за 4 години зробити роботу на 8 годин, то відповідь — ніяк

+

+

влучно!

Мене теж стиль зацепив :)

1. Про документацію і тест артефакти. Все ж таки цікаво, що тест-дизайн це про тест-кейси, а ви впродовж статті апелюєте до всіх артефактів, аж від тест плану (а то і тест стратегії) і до тест репортів. Чи нема у вас тут певної плутанини у визначеннях?
2. А чи дало вам? А розкажіть простими словами? І взагалі мета чого, Тест дизайну чи цієї статті? І чому для IT не підходить кодекс самурая?
3.

Чим більше людей і проміжних ланок, тим важливіше спрощувати та розбивати на менші елементи,

не зрозумів до якого з моїх коментів це відноситься, але про які проміжні ланки йдеться? QA спілкується безспосередньо зі своєю командою розробки, то це скоріш за все не про імплементацію рішення, а значить про що? спілкування з клієнтом? Як це впливає на тест-дизайн? Я неправильно зрозумів ваш коментарій?
4.

Стратегії.

Розумієте, тут така фішка, що багато хто, коли навчиться читати код, і писати автотести, то не дуже поспішають з ручним тестуванням (навіть якщо воно ефективніше або оптимальніше в конкретному випадку). А навіщо? Займаєшся складною справою, корисною для кар’єрного просування і платять за це більше. І приходимо до того, що починаємо пхати ті автотести де треба і не треба. А exploratory? То хай у менеджера голова болить.
5.

Скринька — моє посилання фактичне ширше за вказане

вибачте не зрозумів чи апелюєте до мого якогось конкретного коментаря
6.

Ви тут, певно, уявляєте собі одну людину — яка і складає план, обирає підходи, і тестує.

Якщо тестування робить не одна людина, а команда QA, значить у них буде тім лід, можливо навіть менеджер, який і займеться розробкою високорівневих тест артефактів, включно до тест плану, в якому будуть прописані техніки тест-дизайну, які треба використати на проекті. Тому так, якщо команда велика, то будуть люди, які це зроблять за вас. Якщо команда велика і ви виявились цією людиною і ви не знаєте, що робити, ну що ж мої вітання — прийшов час навчатись в польових умовах (можливо на власних помилках).

достатньо буде exploratory testing, може й smoke досить

цікавий приклад. Smoke testing — це про звуження вибірки ваших існуючих тестів для швидкої перевірки працездатності системи. Чи можна його взагалі ставти в один ряд з повноцінною технікою тест-дизайну (exploratory testing)?

якщо нема розуміння якої кількості коду стосуються апдейт, з чим він пов’яханий і в яких місцях потенційно може щось зламати

а й не завжди потрібно. Женемо регресійні автотести на кожен білд і можна взагалі про це не думати (що багато хто і робить).
7.

Комбінація технік.

. Дивіться як справа. Ви створили тести, які знайшли критичні дефекти, але їх доля невелика, в переважній більшості баги були мінорні. Продукт вийшов в реліз, клієнт задоволений? Чи гарно ви попрацювали? Моя відповідь — так, а ваша? Чи от така ситуація, серйозний медичний софт, питання життя і смерті і все таке. Окрім стандартних функціональних тестів, для яких ви використовували blackbox техніки, ви також застосовуєте model-based, створюєте модель, і вона у вас покриває абсолютно всі можливі переходи, які існують в продукті. Вона навіть не вимикається, тобто у вас там даже не то щоб тест-кейсів багато, вони взагалі виконуються нон-стоп стільки, скільки йде етап тестування. Тобто кількість виконань — мільйони, кількість унікальних paths — десятки тисяч. Знайдено 1 критичний дефект, всього один, але який, десятки людей можливо будуть жити завдяки вам. То що там про нашу комбінацію технік, вона була ефективною чи ні? А як ми могли про це дізнатись, не протестувавши і не знаючи результат?
9.

Список: 1. Ідея умовного поділу.

В принципі ідея декомпозиції — це вже застосування певних технік тест-дизайну з аналітичної добірки. Тобто, що у вас перше — курка чи яйце?
10.

10. Це дозволяє прийти до приорітетів. Приорітети дають відповідь про що в першу чергу та наскільки ретельно з яких пишуться тест-кейси

Не обов’язково. Уявимо, що ми застосовуємо на проекті ризик-менеджмент. І ми знаємо, які ризики є критичними, які — середніми, які можна ігнорувати. Ви все ще повинні прийняти рішення, що «тут» необхідно застосувати «decision table», «там» — класи еквівалентності, а «ось там» вистачить і чек-ліста на основі use cases, які нам надав клієнт в scope of work. Та й той же coverage на мапиться до певних ризиків (пріоритетів) за певним шаблоном. Це вже ваше персональне рішення, засноване на навяних даних і вашому досвіді/знаннях.

Якщо чесно кажучи, то пункти з 11 до 17 були б придирками до окремих слів, вирваних з контексту, тому перейду одразу до узагальнюючого висновку:

В тест-дизайні нема таких вже прям складних речей. Так, треба оволодіти певними навичками та техніками. Причому опанування ними вже в певній мірі дає розуміння, коли їх застосовувати. А те що ви вкладаєте в поняття тест-дизайн покривається такими документами як тестова політика, тестова стратегія і тест-план. І там вже треба знайти відповіді на усі ці запитання. Причому зачасту відповідь на нього знаходять не тільки QA, а й інші департаменти.