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

Я писав аргумент про рік, бо це мало б хоча б якийсь сенс. Якщо ви орієнтуєтесь, ще на менший строк (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, а й інші департаменти.

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

Так багато запитань до автора статті:
— назва не відображає змісту. Я розраховував побачити якісь реальні бізнес-кейси з поясненням як певна (неочевидна) техніка тест-дизайну допомогла протестувати цей кейс, або підходи по дизайну тест-кейсів, а побачив загальні міркування про тестову політику и тестову стратегію (особливо в першій половині статті). Це так зроблено навмисне чи я чогось не розумію?
— деякі терміни вжиті занадто загально і абстрактно, наприклад «документація» в

Адже, щоб документація не просто стояла і метрики красиві були, в ідеалі б на кожному етапі уявляти, що це і навіщо — як інструмент, і як концепція.

Документація — це ви про що? Про тестартефакти, що створюють QA, чи про вихідну документацію бізнесу, архітектури та дизайну проекту?

Весь розділ «Мета» — не додає нічого нового до розкриття теми про тест-дизайн. Більш того, останнє ствердження в ньому є хибним. Я про це

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

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

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

Компанія продуктова чи аутсорс?

Команда на 100, 500 чи 100500 людей?

Яка загальна плинність кадрів?

Яка ціна помилки

Чи є тенденція до розширення та наскільки?

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

Знову і знову зустрічається міксування різних рівней асбтракції

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

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

Міфологія давнього IT стверджує, що тестери — нижча каста, і до розробника їм просто так підійти не варіант.

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

Сукупний досвід довів, що зробити вашу спільну скриньку якомога білішою — справа корисна для всієї команди.

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

Від протилежного: обрана без глибокого розуміння організації продукту комбінація технік тест-дизайну майже 100% буде заскладною та надмірною. Не треба так.

Все навпаки, якщо у вас нема розуміння архітектури продукту, то тестування буде більш прости і інтуітивним, адже ви будете застсовувати exploratory testing, use case і якісь інші 1-2 техніки тест дизайну, що відносяться до black box. Чи більше у вас інформації про продукт, тим більшим стає ваш спектр доступних технік, включаючи доволі складні model-based, pairwise. Збільшується кількість метрик, якими ви можете зазначати покриття тестами, зявляється та сама цикломатична складність системи і т.д.

Переходимо до підходів і інструментів. Хоча в цілому ці 2 ствердження є вірними в цілому:

Комбінація технік, яку потрібно сформувати, повинна базово відповідати двом характеристикам:
— Створений набір тестів виявляє найсерйозніші дефекти продукту.
— Кількість тестів, що виявляють критичні дефекти зведена до достатнього мінімуму.

Але їх вплив на техніки прям зворотній. Ви спочатку обираєте техніки тест-дизайну, а вже потім працюєте зі статистичною інформацію завершених етапів тестування і починаєте розуміти які тести виявляють найсерйозніші дефекти (не забуваємо про парадокс пестициду).
Якщо ж статистики нема, проект новий, все створюємо з нуля, то тут точно більш ефективними за замовчуванням стають experienced-based техніки такі як error guessing та exploratory testing. Помноживши їх на risk-based сратегію, відсікаємо всі замудрені методологічні підходи. Як же ш тоді вийти на 100500 юніт-тестів, на які ви натякали в розділі «Що в чорному ящику?»

З патетичних істин, що стають такими, як тільки їх озвучити, але чомусь часто ігноруються, якщо цього не зробити: краще довго писати тести, які швидко виконуються, ніж швидко написати ті, що... (оберіть самі, яким обсценним словом завершити це речення, щоб зробити аксіому веселішою).

Ці причини не патетичні. Якщо продукт нескладний, має невелику кількість ітерацій, то краще швидко зробити прості тести і забути про нього, тому ще на інше все одно нема коштів (часу). Взагалі тут ми сильно забираємось в юніт-тестування, а без координації з командою розробки (яка зачасту і пише повільно оті самі швидкі тести) цей аспект обговорювати марно. На рівні ж інтеграції, e2e розрив між швидкістю тестів не такий вже й великий.

Щоб створити гідний набір тестів, нам потрібно:
— розбити цілісну систему на складові;
— зібрати та проаналізувати увесь перелік вимог до продукту;
— розставити пріоритети (не дивитися в бік мінорних дефектів, доки не розібралися з критичними);
— сформулювати зібрані ввідні дані, унеможлививши їх хибне трактування;
— взяти і застосувати обрані техніки.

Дуже абстрактний список вийшов, хоча ви його і розбили на булети. Проходжу по кожному:

розбити цілісну систему на складові;

що значить розбити на складові? А для чого? А користувач теж розбиває на складові чи користується продуктом as isб в цілому? А якщо таки на складові, чи не про test conditions ви хотіли сказати? Не зрозуміло

зібрати та проаналізувати увесь перелік вимог до продукту;

що значить проаналізувати? що це нам дає? як ми цей аналіз використовуємо подальшому? Памаятаєте назву статті? «... до готового набору артефактів».

розставити пріоритети (не дивитися в бік мінорних дефектів, доки не розібралися з критичними);

А коли ви кажете про мінорні, ви маєте на увазі priority чи severity? А якщо продукт у нас загинається від тисячі порізів, як ми будемо себе поводити?Я згоден з тим, що треба розставляти пріоритети, але я б подав це під соусом, що більш ризиковані частини вважаємо більш пріоритетними, а тому тестуємо більш ретельно. Хоча окей, тут ви хоча б навели приклад, варто було б зробити це і по іншим булетам списку

взяти і застосувати обрані техніки.

як кажуть у нас у селі «план надійний як швейцарський годинник» :)

Прагнемо щільного тестового покриття? Дивимося в бік функціонального тестування та розбиття на класи еквівалентності.

Розбиття на класи еквівалентності — це прям сама поверхня функціонального тестування. Більш щільне -> +граничні значення +pairwise +більше уваги error handling (коли інвалідних класів може виявитись знаааачно більше ніж ми вважали).

Важливо чиїми саме очима дивитися на продукт? Бета та користувацьке — до ваших послуг.

В комерційній розробці QA завжди дивляться очима користувача, чи ні?

Хочете зрозуміти, як продукт виконує свою бізнес-задачу? Організовуйте UAT (user acceptance testing).

UAT — практично невідємна частина процесу розробки. Кількість проектів, що минують цю фазу незначна. Тому і UAT, і все, про що йдеться вище разом, не окремо.

Залежно від мети (хоча, скоріше, етапу), також визначаємо підхід. Базові підходи: дослідницький та тестування за тест-кейсами.

А наведіть будь-ласка приклади мети (етапів). А логічно, чому ця інформація не потрапила до розділу «Мета»?

Але є одне але.
Чи зможе довільна інша людина, окрім «творця», так само ефективно застосовувати створене?

Якщо виконані умови і документація як ви вказали, прям хочеться поділитися в соцмережах, то так, проблем не виникне.

Розділи «Документація загадкова» та «Обмеження, які дають свободу» абсолютно зайві та ніяк не розкривають тему тест-дизайну.

Субєктивні висновки:
Заінтригував стиль написання, власне прочитавши вступні абзаци, збирався почитати щось іронічне та кумедне, але коли подивився на суть, то просто не міг не прокоментувати. Нажаль, стаття не несе ознак практичності, які слід було б очікувати, прочитавши її назву. Дуже велика кількість контроверсійних стверджень (а іноді і відверто хибних). Хоча може авторка задумала це як певний тролінг, то тоді я явно не збагнув задуму.

P.S. Сподіваюсь коментарій буде корисним і Валентині і потенційним читачам статті
P.P.S. Відкритий до подальшої дискусії