День тестировщика отмечают ежегодно 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, Senior 3200, Team Lead 3500, Tech Lead 4575, Head/Manager $5000. Цифры не обещание оффера. Они показывают, куда рынок ставит вес: сложность, ответственность, автоматизация, руководство качеством.
Пример карьерной развилки. Ручной тестировщик с тремя годами опыта в e-commerce может остаться в «проверке витрин» и постепенно терять стоимость. Или за год закрыть пробелы: API, SQL, один фреймворк автотестов, понимание аналитики воронки. Второй путь тяжелее и значительно живее. Другой кейс — автоматизатор, который пишет только UI-тесты на каждую кнопку. В 2026-м это хрупкая позиция. Работодатели хотят пирамиду: больше проверок на уровне API и контрактов, меньше медленных end-to-end сценариев.
Навыки, которые реально отделяют резюме от стопки. Первое — умение оценить риск и сказать, что можно не тестировать. Второе — работа с данными и логами. Третье — коммуникация без агрессии и без подхалимства. Четвертое — тестовая стратегия для систем с искусственным интеллектом: оценка правдивости, смещения, деградации ответа, а не только «кнопка Send активна». Пятое — понимание, как продукт зарабатывает деньги. QA, который видит бизнес-потерю за дефектом, говорит с менеджментом другим языком.
Типичный карьерный подводный камень — сидеть в одном продукте пять лет и не видеть ничего, кроме «нашего Jira». Праздник 9 сентября хорошо использовать как личный аудит. Что я умею доказать портфолио? Какой последний сложный дефект я расследовал до причины? Где мои тесты помогают команде, а где лишь зеленеют в отчете?
Для тех, кто только смотрит в профессию, честное предупреждение. Вход возможен. Легкого входа почти нет. Лучше один разобранный пет-проект с тестовой документацией, чем десять сертификатов без единого самостоятельного исследования. Лучше узкий домен и глубина, чем строка «тестировал все подряд».
Для кого этот праздник / для кого нет
Для кого. Для QA всех уровней, SDET, тест-лидов, специалистов по производительности и безопасности, аналитиков, которые пишут критерии приемки, разработчиков, которые сами покрывают критические ветки, и преподавателей тестирования.
Не для кого как «профессиональный выходной». Дата не отменяет инциденты, он-колл и горячие релизы. Не стоит ждать государственных поздравлений или сокращенного дня по закону. Это праздник сообщества, а не статья трудового календаря.
День тестировщика держится на простой идее: мир программ хрупок, а доверие пользователя еще хрупче. 9 сентября 1947 года в реле машины нашли моль и имели смелость это записать. 9 сентября 2026 года работа та же, только инструменты другие. Если после этого дня в команде станет на один честный разговор о риске больше, праздник выполнил свою функцию лучше любого торта в форме жука.
