День тестувальника відзначають щороку 9 вересня. У 2026 році ця дата припадає на середу. Свято неофіційне, але вже десятиліттями живе в IT-спільноті як день тих, хто шукає дефекти до того, як їх знайде користувач.
Дата прив’язана до 9 вересня 1947 року, коли інженери Гарвардського університету вийняли справжню міль із реле машини Mark II і вклеїли її в технічний журнал із написом «First actual case of bug being found». Відтоді «баг» і «дебагінг» стали мовою всієї індустрії, а 9 вересня — символічним днем якості.
Це не вихідний і не державна дата. Це привід привітати QA-інженерів, автоматизаторів, мануальних тестувальників, лідерів якості та всіх, хто щодня стримує хаос у продуктах, якими користуються мільйони людей.
Коли святкують День тестувальника і чому дата не «плаває»
День тестувальника має фіксовану дату: 9 вересня. На відміну від Дня програміста, який у багатьох країнах прив’язаний до 256-го дня року, тут немає формули з календарем. Дата стоїть на місці, бо прив’язана до конкретного історичного епізоду, а не до астрономічного чи корпоративного циклу.
У 2026 році 9 вересня — середа. У 2027-му це буде четвер, у 2028-му — субота. Для команд це зручно: середу легше перетворити на внутрішній демо-день, короткий мітап або вечірній збір, ніж п’ятницю з релізом «на вчора». За моїм досвідом, саме середина тижня найкраще працює для професійних свят в IT: люди ще в робочому ритмі, але вже готові відкласти черговий регресійний прогін на годину.
Важливо не плутати це свято з іншими датами якості. World Quality Day відзначають у другий четвер листопада; у 2026 році це 12 листопада. Там акцент на культурі якості в бізнесі загалом. День тестувальника вужчий і тепліший: він про людей, які ловлять дефекти, пишуть тест-кейси, сперечаються з розробниками і рятують реліз о другій ночі.
Офіційного статусу свято не має ні в Україні, ні в США, ні в більшості інших країн. Його не затверджували указом і не вносили до міжнародних календарів ООН. Популярність тримається на спільнотах, мемах, корпоративних чатах і конференціях. У 2026 році, наприклад, Testers’ Day у Тбілісі входить до мережі заходів ISTQB і збирає QA-фахівців регіону. Це типова модель: локальна спільнота бере дату 9 вересня і робить із неї живий професійний день.
Типова помилка початківців і редакторів календарів — писати «1945 рік» замість 1947-го. Помилка тягнеться з підпису в одному з ранніх музейних експонатів, де рік указали невірно. Harvard Mark II взагалі не був готовий до літа 1947-го, тож «баг 1945 року» фізично неможливий. Друга плутанина — вважати свято американським державним. У США історія з міллю відома як кумедний епізод історії обчислень, але окремого національного «Tester’s Day» там немає.
Практичний нюанс для 2026 року: якщо команда розподілена між Україною, Польщею й США, вітання варто планувати з ранку за київським часом. Американські колеги ще спатимуть, а українські QA вже будуть у стендапі. Коротке повідомлення в Slack о 9:09 — дрібниця, яка працює краще за довгий корпоративний лист о 18:00.
Ключові цифри дня
9 вересня 1947 року, близько 15:45 — час запису про міль у реле №70 панелі F машини Harvard Mark II.
9 вересня 2026 року — середа, фіксована дата Дня тестувальника.
Літо 2026, опитування DOU: медіанна зарплата Automation QA в Україні — 3663, Manual QA —2000, Junior QA — 890, Head/Manager —5000.
Історія першого комп’ютерного бага: що насправді сталося в Гарварді
9 вересня 1947 року в Гарвардському університеті команда працювала з електромеханічною машиною Mark II Aiken Relay Calculator. Це був величезний калькулятор на реле, збудований для Бюро озброєнь ВМС США. Він важив тонни, займав цілу залу й умів додавати числа зі швидкістю, яка сьогодні виглядає кумедно, але тоді вважалася проривом.
Машина почала збоїти. Інженери простежили несправність до реле №70 на панелі F. Між контактами застрягла міль — жива істота, а не метафора. Комаху вийняли пінцетом, приклеїли скотчем до сторінки операційного журналу й написали: «First actual case of bug being found». Формулювання точне. Не «перший баг у світі», а «перший випадок, коли баг виявився буквальним». Слово bug інженери використовували ще з часів Томаса Едісона в XIX столітті для дрібних дефектів у схемах.
Журнал із міллю зберігається в Національному музеї американської історії Смітсонівського інституту. Об’єкт має номер 1994.0191.01. Міль досі на сторінці. Це рідкісний випадок, коли метафора професії має фізичний артефакт, який можна побачити власними очима.
Грейс Гоппер часто фігурує в переказах як авторка знахідки. Це красива, але неточна версія. Гоппер була в команді Mark II, пізніше десятиліттями розповідала цю історію на лекціях і зробила її знаменитою. Сама вона неодноразово уточнювала, що міль знайшли оператори зміни, а не вона. Почерк у журналі пов’язують зокрема з Вільямом «Біллом» Берком. Гоппер стала оповідачкою міфу, а не його героїнею. Для історії професії це навіть цінніше: якість живе не лише в знахідці, а в тому, як про неї говорять і чому навчають інших.
Підводний камінь популярних статей — романтизувати момент як «народження тестування». Тестування як інженерна практика існувало і раніше. Окрему роль тестувальника від налагодження коду чіткіше відокремили в 1950-х. У 1951 році Джозеф Джуран писав про планування, контроль і поліпшення якості. У 1957-му Чарльз Бейкер розвів testing і debugging. У 1958-му Джеральд Вайнберг зібрав команду тестувальників для програми Mercury. Книга Гленфорда Майерса «The Art of Software Testing» пізніше закріпила дисципліну як окрему професію.
Зв’язок із 2026 роком простий і жорсткий. Сьогодні баг рідко є міллю. Частіше це гонка в багатопотоковому коді, крива авторизація, зламаний шрифт на українській «ї», витік токена або галюцинація моделі, яку продукт видає за факт. Метод той самий: знайти причину, зафіксувати доказ, не дати дефекту дійти до людини.
Цікавий факт
У записі 1947 року навмисно стоїть слово actual. Інженери вже називали збої «багами», тому знахідка комахи стала внутрішнім жартом лабораторії. Саме жарт, а не наукове відкриття, закріпив слово в комп’ютерній мові.
Від молі в реле до окремої професії: як тестування стало інженерією
Перші десятиліття комп’ютерів перевірку робили самі розробники або оператори машин. Окремої ставки «тестувальник» майже не існувало. Якість була побічним ефектом акуратності інженера. Коли програми виросли з кількох сотень команд до банківських систем, авіаційних контролерів і космічних місій, цей підхід луснув.
Класичний кейс — ранні космічні програми США. Помилка в розрахунках або в логіці запуску коштувала не «кнопку не натиснули», а роки роботи і життя екіпажу. Саме тому з’явилися люди, чиє єдине завдання — сумніватися в тому, що «вже працює». Другий кейс ближчий до цивільного життя: банківські системи 1970–80-х. Одна невірна комісія в циклі обробки платежів множилась на мільйони транзакцій. Третій приклад — веб-епоха кінця 1990-х: сайт міг «відкриватися в Netscape» і розсипатися в Internet Explorer. Кросбраузерність стала окремим ремеслом.
У 2000-х тестування розкололося на кілька професій. Мануальний тестувальник досліджує продукт руками, будує сценарії, шукає крайові випадки. Автоматизатор пише перевірочний код. Фахівець із продуктивності ганяє систему під навантаженням. Спеціаліст із безпеки шукає дірки, якими скористається не клієнт, а зловмисник. Пізніше з’явилися SDET, QAOps, Quality Coach. Назви змінюються швидше, ніж суть: людина, яка зменшує ризик релізу.
Практичний нюанс, який досі ламає команди: плутанина між debugging і testing. Дебагінг — це коли розробник знає, що щось зламано, і шукає причину. Тестування — це спроба дізнатися, чи система взагалі відповідає очікуванням, включно з тими, про які ніхто не подумав. Якщо QA лише «прокликує щасливий шлях», це не тестування, а демонстрація.
Типова помилка менеджерів 2010-х, яка в 2026-му ще живе в слабких командах: найняти джуніора «покликати кнопки», дати йому чеклист і вважати якість закритою. Такий підхід тримається, поки продукт простий. На складній доменній системі він випускає в прод тихі дефекти: неправильне округлення податків, зникнення діактричних знаків, блокування акаунта після зміни номера телефону.
Емоційний бік професії рідко потрапляє в вакансії. Тестувальник живе в постійному когнітивному дисонансі. Він має любити продукт достатньо, щоб хотіти його покращити, і не довіряти йому достатньо, щоб ламати його щодня. Це виснажує. Саме тому професійне свято потрібне не як корпоративна гірка, а як публічне визнання: якість — не служба сервісу для розробки, а окрема інженерна відповідальність.
Хто такий тестувальник у 2026 році і чим він уже не є
У 2026 році слово «тестувальник» одночасно застаріле і живе. У вакансіях частіше пишуть QA Engineer, Quality Engineer, SDET, Test Automation Engineer. На святі 9 вересня всіх однаково вітають як тестувальників. Це чесно: ринок змінив вивіски, але користувач досі страждає від тих самих класів дефектів.
Сучасний сильний QA вміє читати вимоги критично, ставити питання до того, як написано код, будувати тестову стратегію, оцінювати ризик і пояснювати його бізнесу людською мовою. Він розуміє клієнтський шлях, логіку API, базові запити до бази, як збирається білд і де в CI падає пайплайн. Автоматизація більше не «плюс», а базова грамотність для middle-рівня в продуктових компаніях.
Приклад з фінтеху. Команда додає миттєві перекази. Розробник закриває задачу, бо сума доходить. QA перевіряє не лише «гроші прийшли». Він дивиться на комісію при сумі 0,01, на ліміт опівночі за київським часом, на повторний клік, на пуш, який приходить двічі, на стан транзакції, якщо інтернет зник на третій секунді. Другий приклад — медичний сервіс запису до лікаря. Баг «слот зник після оновлення сторінки» виглядає косметичним, доки через нього пацієнт не втрачає єдине вільне вікно на тиждень. Третій приклад — генеративний інтерфейс. Модель впевнено вигадує номер наказу. Без окремої стратегії перевірки відповідей ШІ продукт поширює неправду швидше, ніж будь-який класичний дефект UI.
У нашій практиці найдорожчі баги 2024–2026 років рідко були «кнопка не натискається». Частіше це дані: подвійне списання, неправильна локаль, зламаний експорт у Excel, роз’їзд прав доступу після міграції. Саме тому тестувальник, який вміє дивитися в логи і базу, цінніший за того, хто ідеально оформлює баг у Jira, але не розуміє, звідки береться стан системи.
Підводний камінь року: делегувати перевірку виключно штучному інтелекту. Генератори тестів швидко пишуть сотні перевірок щасливого шляху і майже так само швидко пропускають бізнес-абсурд. ШІ корисний як прискорювач рутини — генерація чернеток тест-кейсів, аналіз логів, підказки для регресії. Він поганий як єдиний арбітр якості. Відповідальність лишається на людині, яка розуміє контекст.
Ще один зсув 2026-го — shift-left уже не гасло, а умова виживання. Якщо QA вперше бачить фічу на демо в останній день спринту, свято 9 вересня перетворюється на іронію. Якість починається на етапі формулювання критеріїв приймання, а не після кнопки «Ready for test».
Зміни 2026
Ринок України після кількох важких років знову підтягнув компенсації QA, особливо в автоматизації. Водночас поріг входу зріс: «пройти курс і клікати сайти» вже не відкриває двері так легко, як у 2021-му. Роботодавці шукають людей, які поєднують дослідницьке тестування, автоматизацію, роботу з даними та базове розуміння ШІ-інструментів. Конференції вересня 2026 року ставлять у центр порядку денного саме вплив штучного інтелекту на майбутнє тестування, а не черговий огляд Selenium.
Як святкують День тестувальника в компаніях, спільнотах і вдома
Формат свята залежить від розміру команди. У маленькому стартапі це торт із цукровою міллю, кілька мемів у чаті й година без нових тікетів. У великій продуктовій компанії — внутрішній мітап, блискавичні доповіді, ретроспектива найцікавіших багів року, інколи навіть мініпремія «Баг року». У спільнотах — мітапи, ефіри, конференції.
Один живий сценарій: команда збирає «музей дефектів». Кожен приносить скріншот або запис найдивнішого бага, який знайшов за рік. Перемагає не найкритичніший, а найабсурдніший: оплата проходить, якщо в полі «ім’я» ввести пробіл і смайлик; кнопка «скасувати» насправді підтверджує замовлення в темній темі; пуш приходить латиницею, коли в системі українська. Такі збірки лікують вигорання краще за корпоративний лист «дякуємо за ваш внесок».
Другий сценарій — день без нових фіч. Команда бере технічний борг якості: флакаючі тести, мертві перевірки, неактуальні тест-кейси, дірки в тестових даних. Це не романтика, але саме так свято стає корисним. Третій сценарій — відкритий офіс для суміжних ролей. Розробник, дизайнер і продакт проводять годину з QA і проходять чужий сценарій. Після цього розмови про «ну це ж очевидно» стають рідшими.
У 2026 році частина святкувань гібридна. Українські команди часто розкидані між Києвом, Львовом, Краковом і віддаленими містами. Відеодзвінок із поганою камерою все одно працює, якщо є ритуал. Хтось ставить на аватар жука. Хтось змінює статус на «out of office, hunting bugs». Хтось дарує колезі сертифікат на курс або квиток на осінню QA-конференцію.
Типова помилка святкування — перетворити день на розбір польотів. «Давайте 9-го розберемо, чому на проді знову інцидент» — найгірший подарунок. Для інцидентів є постмортем. Для свята потрібне визнання. Інший підводний камінь — вітати лише автоматизаторів і ігнорувати мануальних дослідників. Саме дослідницьке тестування досі знаходить дефекти, які сітка автотестів обходить десятий місяць поспіль.
Якщо в команді є стажери, 9 вересня — гарний день для парного тестування. Сеньйор не читає лекцію, а думає вголос: навіщо перевіряє порожнє поле, чому дивиться в мережеву вкладку, як формулює баг так, щоб розробник не хотів сперечатися. Це передача ремесла, якої не замінить жоден курс.
Чек-лист гідного святкування 9 вересня
- Привітати іменно, а не «шановні колеги QA» одним рядком на всіх.
- Показати один конкретний баг, який уберегли від користувача.
- Не ставити реліз «на свято», якщо немає окремої домовленості.
- Дати людям пів дня без нових срочних «потрібно ще вчора».
- Окремо відзначити тих, хто тримає регресію, тестові дані й нестабільні середовища.
- Запропонувати одну корисну дію: почистити флакаючі тести або оновити критерії приймання.
Список працює лише разом із повагою в будні. Одне свято не компенсує рік ігнорування якості на плануванні.
Міфи про тестувальників, типові помилки і що ламає кар’єру
Навколо професії наросло стільки міфів, що частина вакансій досі пишеться так, ніби 2012 рік не закінчився. Найшкідливіший міф: тестувальником може стати будь-хто, бо «треба лише уважно клікати». Уважність потрібна. Її недостатньо. Без системного мислення людина бачить симптом і пропускає причину.
Другий міф: автотести замінять людей. Автотести замінюють повторювану перевірку відомого. Вони не замінюють постановку питання «а що, якщо користувач зробить заборонене, але логічне». Третій міф: QA — ворог розробника. У здорових командах QA і розробка мають спільну мету: продукт, який не соромно віддати. Конфлікт починається там, де дедлайн важливіший за доказ ризику.
Приклад із життя сервісної компанії. Замовник вимагає «повне покриття автотестами». Команда пише 800 UI-тестів на нестабільному середовищі. Через пів року пайплайн зелений раз на три запуски, реліз все одно йде «на вірі». Інший приклад: джуніор оформлює баг «нічого не працює» без кроків, очікуваного результату, логів і оточення. Розробник не може відтворити. Баг закривають як «cannot reproduce», хоча дефект живий. Третій приклад: тестувальник боїться блокувати реліз і ставить critical як major. Через тиждень інцидент на проді. Страх конфлікту коштує дорожче за незручну розмову.
Практичні помилки початківців повторюються з року в рік. Перша — вчити лише інструмент, а не тестування. Знати Selenium, Playwright чи Cypress корисно. Без розуміння оракулів, покриття ризиків і тестового дизайну людина просто автоматизує слабкі перевірки. Друга — ігнорувати домен. Тестувати банківський продукт без розуміння проводок — це ловити кнопки й пропускати гроші. Третя — писати баги як претензію, а не як доказ. Хороший звіт про дефект — це інструкція, як повторити біль користувача.
У 2026 році окрема пастка — сертифікатоманія. ISTQB Foundation корисний як спільна мова. Він не робить людину сильним дослідником. Роботодавець усе частіше дивиться на портфоліо: як кандидат розібрав публічний продукт, які ризики побачив, який мінімальний набір перевірок запропонував би перед релізом.
Експертний акцент простий. Тестувальник, який вміє сказати «ні» з аргументами, цінніший за тестувальника, який завжди каже «можна релізити». Свято 9 вересня варто читати і так: це день права на сумнів.
Міфи vs реальність
Міф: тестувальник шукає баги, щоб «підставити» розробника.
Реальність: тестувальник шукає докази ризику, щоб користувач не став бета-тестером.
Міф: мануальне тестування померло.
Реальність: померло бездумне прокликування чеклиста. Дослідницьке тестування живе і часто знаходить те, чого не бачить автомат.
Міф: 9 вересня — офіційне міжнародне свято на кшталт Нового року.
Реальність: це професійна традиція спільноти, побудована навколо гарвардського епізоду 1947 року.
Як привітати тестувальника і що подарувати, щоб не було соромно
Найгірше привітання — шаблон «бажаю, щоб баги самі знаходилися». Жарт стерся до дірок. Найкраще — конкретність. «Дякую, що минулого місяця зловила подвійне списання до релізу» працює сильніше за оду якості. Люди пам’ятають імена власних перемог.
Короткий текст колезі може бути таким: «З Днем тестувальника. Через твої зауваження до комісії на граничних сумах ми не відправили в прод сором. Дякую за впертість». Для керівника інший тон: «Сьогодні варто пригадати не кількість закритих тікетів, а інциденти, яких не сталося». Для людини, яка лише входить у професію: «Нехай перші баги будуть навчальними, а не бойовими на проді».
Подарунки теж мають ієрархію користі. Працюють: хороша технічна книга, підписка на інструмент, який людина давно хотіла спробувати, квиток на профільну конференцію, зручна механіка для робочого столу, сертифікат на відпочинок, бо очі після логів і скріншотів втомлюються раніше за клавіатуру. Слабко працюють: кружка з написом «bug hunter», якщо в людини вже третя така кружка, і плюшевий жук «для галочки».
Кейс із продуктової команди: замість сувенірів ліду QA подарували два робочі дні без зустрічей і право самостійно вибрати, який технічний борг закрити. Це виявилося цінніше за торт. Інший кейс: розробники команди написали спільно один «лист подяки» з переліком багів, які спочатку дратували, а потім врятували архітектуру. Третій варіант для родини: не питати «ну як, сьогодні багато багів знайшов?», а просто забрати побутові задачі на вечір. Мозок після восьми годин пошуку винятків погано перемикається на дрібну побутову логістику.
Підводний камінь публічних привітань у соцмережах — виставляти внутрішні баги продукту. Свято не привід світити вразливість, скріншот продакшену з персональними даними чи мем про конкретного клієнта. Гумор має зупинятися там, де починається відповідальність.
У 2026 році окремий хороший жест — доступ до навчання з ШІ-інструментів для тестування. Не як заміна мислення, а як важіль. Людина, яка вже вміє тестувати, після нормального інструмента стає швидшою. Людина, яка не вміє тестувати, після того самого інструмента швидше виробляє красиве сміття.
| Кому | Що сказати | Чого уникати |
|---|---|---|
| Колезі QA | Конкретна подяка за врятований сценарій | Загальних фраз про «гостре око» |
| Розробнику в команді з QA | Визнання спільної роботи над ризиком | Жартів «тестувальники знову все зламали» |
| Джуніору | Підтримка сумніву й допитливості | Тиску «давай уже як сеньйор» |
| Керівнику напряму | Питання про час і вплив якості, не лише про швидкість | Святкової промови без бюджету на тестові середовища |
Таблиця не замінює тон. Одна й та сама фраза звучить тепло в особистому повідомленні і фальшиво в розсильці на двісті людей. Краще п’ять особистих рядків, ніж один «корпоративний каскад щастя».
Якщо хочеться публічного формату, підійде коротка історія без назв клієнтів: який ризик побачили вчасно, як сперечалися, чим закінчилося. Такі історії навчають новачків краще за будь-яке привітання у віршах.
Ринок, зарплати й навички: яким є День тестувальника для кар’єри у 2026-му
Професійне свято завжди стоїть поруч із ринком. В Україні тестування довго було одним із найпопулярніших входів в IT. Це дало галузі тисячі фахівців і водночас породило перегрів на junior-рівні. У 2026-му картина інша, ніж на піку масових курсів. Початківцю складніше. Людині з досвідом, автоматизацією і доменом — навпаки, є за що торгуватися.
За літнім зарплатним зрізом DOU 2026 року медіани зросли в усіх основних гілках QA. Automation QA тримає найвищу медіану — 3663. General QA —2700, Manual QA — 2000. За посадами орієнтири такі: Junior близько890, Middle 1900, Senior3200, Team Lead 3500, Tech Lead4575, Head/Manager $5000. Цифри не обіцянка офера. Вони показують, куди ринок ставить вагу: складність, відповідальність, автоматизація, керівництво якістю.
Приклад кар’єрної розвилки. Мануальний тестувальник із трьома роками досвіду у e-commerce може лишитися в «перевірці вітрин» і поступово втрачати вартість. Або за рік закрити прогалини: API, SQL, один фреймворк автотестів, розуміння аналітики воронки. Другий шлях важчий і значно живіший. Інший кейс — автоматизатор, який пише лише UI-тести на кожну кнопку. У 2026-му це крихка позиція. Роботодавці хочуть піраміду: більше перевірок на рівні API й контрактів, менше повільних енд-ту-енд сценаріїв.
Навички, які реально відділяють резюме від стопки. Перше — уміння оцінити ризик і сказати, що можна не тестувати. Друге — робота з даними й логами. Третє — комунікація без агресії і без підлабузництва. Четверте — тестова стратегія для систем зі штучним інтелектом: оцінка правдивості, зміщення, деградації відповіді, а не лише «кнопка Send активна». П’яте — розуміння, як продукт заробляє гроші. QA, який бачить бізнес-втрату за дефектом, говорить із менеджментом іншою мовою.
Типовий кар’єрний підводний камінь — сидіти в одному продукті п’ять років і не бачити нічого, кроме «нашого Jira». Свято 9 вересня добре використовувати як особистий аудит. Що я вмію довести портфоліо? Який останній складний дефект я розслідував до причини? Де мої тести допомагають команді, а де лише зеленіють у звіті?
Для тих, хто лише дивиться в професію, чесне попередження. Вхід можливий. Легкого входу майже немає. Краще один розібраний пет-проєкт із тестовою документацією, ніж десять сертифікатів без жодного самостійного дослідження. Краще вузький домен і глибина, ніж рядок «тестував усе підряд».
Для кого це свято / для кого ні
Для кого. Для QA всіх рівнів, SDET, тест-ліців, спеціалістів із продуктивності й безпеки, аналітиків, які пишуть критерії приймання, розробників, що самі покривають критичні гілки, і викладачів тестування.
Не для кого як «професійний вихідний». Дата не скасовує інциденти, он-кол і гарячі релізи. Не варто чекати державних привітань чи скороченого дня за законом. Це свято спільноти, а не стаття трудового календаря.
День тестувальника тримається на простій ідеї: світ програм крихкий, а довіра користувача ще крихкіша. 9 вересня 1947 року в реле машини знайшли міль і мали сміливість це записати. 9 вересня 2026 року робота та сама, лише інструменти інші. Якщо після цього дня в команді стане на один чесний розмов про ризик більше, свято виконало свою функцію краще за будь-який торт у формі жука.
