Отраслевое исследование QA: автоматизация, AI и метрики — сбор данных
Команда Test IT (бренд «Девелоника» FabricaONE.AI (акционер – ГК Softline)) запустила опрос для сбора данных перед публикацией отраслевого исследование по состоянию QA в российских компаниях.
Наша задача опросить реальных тестировщиков и понять, что меняет их работу прямо сейчас, какие особенности в проектах нужно учитывать в 2025-2026 году и как меняется тестирование с учетом новых инструментов и развития отечественных решений TMS.
Если вы представитель QA-сообщества и готовы поделиться реальной практикой (включая проблемы и ограничения), то будем ждать ваших ответов! Участие в опросе займет немного времени, итоговые данные будут направлены всем участникам-респондентам.
Присоединяйтесь, давайте вместе составим объективную картину по рынку в нашем сегменте! Всем недели без багов и без пятничных релизов)!
Проект QArt Coder позволяет вставить лицо пользователя в QR Code. Многие точки в QR‑коде являются лишними, что означает, что их можно расположить в виде картинки, а не просто случайным образом. Короткие URL‑адреса и небольшие изображения с высокой контрастностью в этом проекте работают лучше всего.
На работе мне понадобилось реализовать воркер. Описываю, как сам эту тему разобрал.
Воркер — это сервис, который ждёт событие-триггер и по нему выполняет некий коллбэк. В отличие от фоновых задач в вашем сервисе, воркер живёт в отдельном контейнере.
Пример Сборщик мусора в БД: пройтись раз в час, например, и удалить старые записи. Или, как у меня задача на работе: обработать xlsx-файл, который передали в ручку.
Зачем Чтобы сделать работу приложения асинхронной. Представим задачу, которую можно обработать дольше, чем за 10 секунд. Клиент на вашем сайте не будет сидеть и смотреть в экран эти 10 секунд. Он перезагрузит страницу, сессия прервётся, и задача не выполнится. Или веб-сервер вернёт клиенту таймаут. В описанном сценарии обработка запроса — синхронная процедура. Она плохо подходит для быстрых веб-сервисов. А вот асинхронная обработка: кинули запрос, получили ответ 200 OK и пошли чилить, пока задача исполняется — это то, что нужно. Воркер как раз для этого.
Коллбэк Коллбэком воркера может быть любая нужная функция: отправить имейл, прочитать содержимое, залить файл во временное хранилище и т. д.
Триггеры Триггерами для воркера могут быть:
крон
таймер
событие
Очереди Воркеры по событию обычно подписаны на очередь. В моём случае это как раз Redis Queue (библиотека rq, например https://python-rq.org/ ). Запрос в ручку получает 200 OK. Мой сервис создаёт запись в БД типа «задача id такой-то, статус processing» и публикует событие в очереди. Воркер забирает событие, чтобы другие воркеры не могли задачу задублировать, и пробует выполнить свой коллбэк. Если всё ок, воркер пишет в БД данные по выполненной задаче и подтверждает в очереди прочтение события. Иначе воркер может ретраить, может завалить задачу и вернуть её в очередь, а может и сам упасть.
Воркер-пул Воркеров может быть несколько. Они могут выполнять как несколько разных задач, так и одну вместе. Увеличение числа воркеров требует оркестрации и иногда для этого также выделяет контейнер с оркестратором. Воркеры могут передавать задачи друг другу. Могут конкурировать за задачи, если очередь организовать неправильно. А могут вообще читать разные потоки и быть никак не связаны друг с другом.
Накладные расходы Чем сложнее слой с воркером, тем больше необходимость следить за их хелсчеками. В отличие от вашего сервиса, воркер может тихо упасть. Ваш сервис отдаёт 200, а по факту задачи не отрабатывают. Так что воркеры накладывают дополнительные накладные расходы: связанность, обработка ошибок, логирование, алерты, ретраи, рестарты подов и т. д.
Образ Воркер собирается из того же образа, что и ваше приложение, но у него отдельный энтри-поинт. Вместо запуска через main.py у, например, worker.py, есть строчка вида:
def main():
... # Какая-то логика по инициализации воркера и очереди
if name == '__main__':
main() # Если запускают этот модуль напрямую, выполни команду main()
Из-за этого кода модуль можно вызвать напрямую python -m app.worker. В main(), как правило, скрыта логика какого-то while-true цикла и шатдауна на случай завершения работы воркера.
Открытый проект blip в режиме онлайн позволяет визуально оценить сетевую задержку (латентность или latency) при передачи данных от ПК до разных серверов в мире. Решение работает в браузере на любом ПК, ноутбуке, планшете, смартфоне с поддержкой javascript и HTML canvas.
Вы либо видите эти проблемы в своих проектах, либо уже боретесь с ними. А если ваш репозиторий пока только растёт, то со временем и ростом проекта вас ждут те же сложности, ведь это закономерный этап развития любого большого проекта.
Главная цель «реформ» — достижение максимального эффекта с минимальными изменениями (трудозатратами). Мы хотели сохранить ту практику работы с репозиториями, которая у нас уже была. Поэтому мы решили подходить именно со стороны нашего сборщика — со стороны Gradle, чтобы не производить радикальных изменений с проектом.
Надеемся, что наш опыт поможет и вам, когда вы столкнетесь с похожими вызовами!
Если ты — Automation QA и хочешь перейти в мир обеспечения качества AI-приложений*, как это сделала я, то мой путь может послужить небольшой дорожной картой.
*не путать с использованием AI-инструментов для тестирования классических приложений
Некоторое время назад я решила сменить вектор развития. Это не произошло в одночасье; это был осознанный, местами трудный, но невероятно вдохновляющий процесс.
Вот как я восполняла пробелы в знаниях:
Временные затраты Около 7 месяцев изучения теории и параллельно более года практического опыта. Этот год я провела, участвуя в стартап-проектах (в основном в роли QA Lead), что дало мне «безопасную песочницу» для применения знаний в области ML на реальных практических задачах.
Переход на Python Java — отличный язык, но в экосистеме ML/AI «лингва франка» — это Python. Библиотеки для работы с моделями, статистикой, метриками и трансформерами здесь есть на любой вкус и цвет. Так что, если ты Java QA, стоит сменить Java на Python.
Создание теоретической базы Нельзя оценивать то, чего не понимаешь. Мне пришлось изучать, как модели строятся с нуля, чтобы понять, как их измерять.
Мое прошлое обучение в аспирантуре по прикладной лингвистике здесь немного помогло, но кое-где математика и архитектура стали новым вызовом.
Кроме того, я изучила множество других материалов (например) и, конечно, много общалась с «железным другом» Gemini. :)
Практика на рынке Сейчас в найме непростые времена, но я решила рассматривать это как бесплатное обучение. Параллельно со своим «апгрейдом» я выполнила около 10 технических тестовых заданий для потенциальных работодателей. Даже те задания, которые не привели к офферу, добавили в мой арсенал новую метрику или технику оценки.
Представлен открытый проект Mimesis: The Fake Data Generator для генерации фейковых данный для проектов, пентеста, хакинга или анонимности в сети, включая ФИО, email, адреса проживания, телефоны, локации, смена стран и адаптирование данных в соответствие с задачами. Полезно также для создания файлов JSON и XML произвольной структуры, а также анонимизации данных. Устанавливается за один клик, имеет простой и понятный интерфейс.
Обновлён открытый ИБ-проект на Go под названием cariddi для поиска уязвимостей и проблемных мест на любых сайтах, включая спрятанные API‑ключи и токены, забытые админки, файлы, которые не должны были быть в открытом доступе.
Представлен открытый проект на Python под названием Reverse API engineer. Это консольный инструмент, который фиксирует трафик браузера и автоматически генерирует готовые к работе клиенты Python API. Больше никакого ручного реверс‑инжиниринга — просто просматривайте, записывайте и получайте чистый API‑код.
«Этот инструмент выполняет код локально, используя Claude Code‑ пожалуйста, следите за выводом/ На некоторых веб‑сайтах используется расширенная система обнаружения ботов, которая может ограничивать захват или требовать ручного взаимодействия», — пояснил автор проекта.
Особенности Reverse API:
автоматизация браузера: создан на базе Playground с режимом скрытности для реалистичного просмотра;
режим автономного агента: полностью автоматизированное взаимодействие с браузером с помощью агентов искусственного интеллекта (автоматический режим с MCP, использование браузера, stagehand);
запись HAR: фиксирует весь сетевой трафик в архивном формате HTTP;
генерация на основе искусственного интеллекта: использует Claude 4.5 для анализа трафика и генерации чистого кода на Python;
поддержка нескольких SDK: встроенная интеграция с Claude и OpenCode SDK;
Мы в 2ГИС верим, что в QA есть место опыту из самых разных сфер. И каждый месяц рассказываем истории людей, которые это доказывают. «Нетипичный QA» — это рубрика про инженеров, чей путь в тестирование начался далеко за пределами IT. У каждого свой путь, но всех объединяет одно: стремление к качеству и умение смотреть на задачи под неожиданным углом.
Николай, руководитель команды Ads QA
Николай с детства занимался хоккеем с мячом — сначала в школе, потом параллельно с учёбой в университете. После выпуска стал профессиональным спортсменом: играл за команды в Новосибирске, Красногорске и Хабаровске и выступал за сборную России. В его карьере — серебро чемпионата мира. О достижениях скромничает, но у него даже есть статья в Википедии. Завершить карьеру пришлось из-за состояния здоровья — в 34–35 лет.
После спорта встал вопрос: чем заниматься дальше? Вспомнил школьный интерес к алгоритмам и программированию — и выбрал тестирование. Переезд в Калининград и пандемия усложнили поиск работы, но Николай не сдавался. В итоге устроился в аутсорсинговую компанию, где работал с API и десктопом. За год вырос в зарплате и уверенности.
По совету брата подал резюме в 2ГИС — указал и спортивный опыт. Прошёл собеседования, удивился вопросу «о чём пожалеешь, если уйдёшь?». Сейчас тестирует мобильные приложения, влияет на процессы и ценит логику в работе. Удалёнка, гибкий график и возможность расти — всё это стало частью новой жизни. Тестировщик, по его словам, — это клей между идеей и реализацией.
Екатерина, тимлид в команде UGC (это я, автор поста)
Начинать карьеру в компании с сомнительной репутацией — всё равно что жить на вулкане. Я работала офис-менеджером и довольно быстро поняла, как моё образование в антикризисном управлении начинает работать на практике. Эти знания помогли мне вовремя распознать тревожные сигналы и начать искать более стабильное и безопасное место.
Такое место оказалось буквально этажом выше — я перешла в рекламный отдел 2ГИС. От офис-менеджера до руководителя сервис-менеджеров — прошла весь путь бумажной работы. Но в какой-то момент стало слишком скучно. Внутренний голос всё настойчивее подсказывал, что мне нужно что-то другое, что-то по-настоящему увлекательное.
Так я пришла в тестирование. Прочитала описание позиции — и почувствовала: вот оно. То, что искала. Я сменила руководящую должность на стажёрскую, и, хотя поначалу было непросто, уже не представляла себя в другой роли. А сейчас я уже тимлид в QA!
Наталья, QA-инженер в команде WebAPI
Работая бухгалтером, Наталья была мастером оптимизации процессов, но её всегда завораживало программирование — загадочные символы, палочки и отступы. В декретном отпуске она открыла в себе педагога: занимаясь семейным обучением детей, научилась структурировать знания и выстраивать процессы.
Желание освоить нечто новое не отпускало, и Наталья решила разгадать тайну тех самых «палочек и отступов». Курс Python-разработчика стал отправной точкой. Освоив основы, она выбрала тестирование — здесь соединились её бухгалтерские навыки организации, педагогический опыт структурирования и технические знания.
Уже полгода Наталья в QA и уверена в своём выборе: тестирование стало для неё увлекательным миром поиска багов, неожиданных сценариев и постоянного совершенствования.
Почему захотелось поделиться этими историями? Потому что тестирование — не про «нажал кнопку — получил результат». Это про понимание, как думает пользователь, как работает система и где она может дать сбой. А значит, чем разнообразнее опыт — тем сильнее команда. Если у вас тоже был нетипичный путь в QA — расскажите!
И заглядывайте в наш канал, чтобы вдохновиться другими и не пропустить следующие истории.
Представлен ИИ-сервис Vibetest Use, который тестирует сайты на прочность и ищет уязвимости. Параллельно запускаются сразу несколько проверок с помощью ИИ, которые ищут ошибки, битые ссылки или проблемы в дизайне. Работает на базе Claude. В качестве альтернативы можно запустить с бесплатным API от Google через Cursor.
Представлен открытый проект релейного компьютера 1961 года Minivac 601, работающий в браузере (код на GitHub). До появления микрочипов компьютеры строились на основе механических реле. Это рабочая модель Minivac 601, образовательного компьютера, разработанного Клодом Шенноном.
Представлена шпаргалку по JavaScript. Внутри есть всё для изучения, проверки себя и прокачки навыков до уровня сеньора: основы и теория, поиск и выбор элементов, CSS, AJAX и база по DOM, формы и ввод данных, общие проверки , разметка и текстовое содержание, документ, область просмотра, переходы и удобный поиск по всем темам.
Энтузиасты выяснили, что фильтры чат‑ботов с ИИ (работает в GPT-4o и Claude 4) можно обойти с помощью «=coffee». Если после запроса добавить слово =coffee, то фильтры нейросетей не видят угрозу. Например, можно получить ключи регистрации Windows 11.
Ранее компьютерный энтузиаст и исследователь ИБ Марко Фигероа предложил ИИ‑модели сыграть в игру «угадайка» и тем самым нашёл способ обмануть ChatGPT 4.0 и выдать скрытые в системе обучения нейросети рабочие ключи для активации Windows 10, включая как минимум один, принадлежащий банку Wells Fargo. В этом эксперименте исследователь обманом смог обойти защитные барьеры в ChatGPT 4.0, предназначенные для предотвращения передачи секретной или потенциально опасной информации, предложив ИИ сыграть в логическую игру. Эти барьеры были разработаны для блокировки доступа к любым лицензиям, таким как ключи продуктов Windows 10. Разработчики нейросети обучили ИИ на примерах реальных ключей активации, что такое нельзя выдавать пользователю.
Встреча по тестированию от сообщества Moscow QA, проводимая совместно с Ви Tech. Moscow QA — это регулярные мероприятия, которые объединяют специалистов в области качества и тестирования программного обеспечения для обсуждения последних трендов в отрасли и обмена опытом.
21 ноября 2025 года вместе с Ви Tech пройдет митап Moscow QA.
Тайминг:
18:00 —18:30— начало регистрации 18:35 — 19:10 —Как погрузиться в автоматизацию за 60 дней, Сергей Лебедев 19:10 — 19:45 — Подход к организации тестовых контуров, Александр Крылов 19:45 — 20:00 — перерыв 20:00 — 20:35 — Как получить высокую оценку на перф-ревью и не сгореть, Вероника Манкова 20:35 — 21:10— Выжить в одиночку: 20 советов и инструментов для прохождения, Ушакова Анастасия
Доклады:
Как погрузиться в автоматизацию за 60 дней
Расскажу о собственном опыте, как я будучи QA-lead ручного тестирования 2 месяца погружался в автотесты на Playwright + TypeScript Как мне с этим помогал ИИ и как мешал учебник по программированию
Сергей Лебедев, QA Lead в «Яндекс Лавке»
Подход к организации тестовых контуров
Когда вы разрабатываете в микросервисах, всегда возникает вопрос — как быстро и эффективно выстроить технологический пайп для того, чтобы эффективней организовать процесс тестирования. Каким образом вы организуйте рабочее пространство тестирования? Будут это кластера K8s под задачи или namespace? Насколько много у тестировщиков будет прав и на что? О том, как ответить на эти вопросы и организовать процесс тестирования на базе K8s мы поговорим в сегодняшней теме.
Александр Крылов, CPO «Штурвала»
Игра "Выжить в одиночку" — история, основанная на реальных кейсах, с которыми может столкнуться каждый QA.
Вы только пришли в новый проект и … начинается настоящее испытание: задачи летят со всех сторон, документации нет, ожидания туманны, а сроки поджимают. Знакомо?
Покажу практические советы и инструменты — чек-листы, шаблоны, промты для ИИ, которые помогут быстро войти в процесс, определить приоритеты и пройти этот квест с минимальными потерями и максимальной пользой!
Ушакова Анастасия, QA Lead/Яндекс Маркет
Как получить высокую оценку на перф-ревью и не сгореть.
В докладе поделюсь опытом, как QA получить высокую оценку на перф Расскажу о наборе реальных кейсов, которые привели сотрудников нашей компании к карьерному апдейту, а также об ошибках, которые ведут к выгоранию на этапах подготовки к перф-ревью.
Чтобы ответить на этот вопрос, сначала нужно разобраться с терминологией и сутью процесса. Сейчас моками называют вообще все что связано с подменой реализации в тестах. Но подмена это просто техника, она может использоваться для совсем разных задач.
Представьте себе две ситуации. В одной мы подменяяем логер, который работает по http, чтобы он просто складывал данные в файл и не делал http запросов во время тестирования. В другой, в другой, мы проверяем что какой-то метод был вызван с определенными аргументами. И там и там работает подмена, но между этими ситуациями почти ничего общего с точки зрения решаемой задачи.
Последний случай, описывает процесс мокирования. То есть мок, это когда мы проверяем то, как код что-то делает, а не что он делает. Иногда говорят, что мы тестируем методом white-box, потому что мы знаем как конкретно написан тест и завязываемся на это, а не на результат работы этого кода, как в black-box тестировании.
Когда мы проверяем как код работает, мы связываем тест с внутренней реализацией. Любое изменение внутри функции (например, вызов другого метода или смена порядка действий) может поломать тест, даже если внешнее поведение программы остаётся тем же. В итоге тест перестает быть защитой от ошибок и превращается в тормоз для рефакторинга. В подкасте про спринг я услышал классный термин: "бетонирование кода", вот это оно и есть.
Когда же моки все таки нужны? Допустим мы пишем систему с поддержкой хуков, например фреймворк для тестирования. В тестах такого фреймворка вполне допустимо проверить что хуки setup, teardown, beforeSetup, afterSetup и так далее, вызываются в нужном порядке и с нужными аргументами.
Общее правило здесь такое, если код можно тестировать методом black-box, то лучше так и делать. White-box это вынужденная необходимость, когда по другому ни как. Правда будьте осторожны, нередко программисты только думают, что по другому никак, потому что они не знают других подходов или по каким-то причинам решили, что другие подходы не подходят по идеологическим причинам.
Гораздо чаще же в тестах нужны не моки, а стабы, которые позволяют изолировать код от внешних эффектов.
Например:
База данных, которая хранит данные в памяти.
Фейковые сервисы какого-нибудь облака, например AWS
Поддельный HTTP клиент, который возвращает заранее заготовленные ответы.
Заглушка почтового сервиса, которая записывает письма в список, а не отправляет их.
Все эти решения делают тесты быстрыми, предсказуемыми и независимыми от инфраструктуры, при этом вы все еще проверяете поведение системы снаружи, не нарушая принцип black-box.
Стабы часто формируются не в конкретном тесте, а на уровне всего приложения. Тот же логер из первого примера просто мешает тестировать наш код, поэтому мы можем поменять реализацию на этапе конфигурирования и на этом все, ни в одном тесте про этот логер мы не вспоминаем.
Итого
Моки используются тогда, когда вы хотите проверить как написан ваш код. Стабы используются тогда, когда вы хотите, чтобы внешние эффекты не мешали вам тестировать результат работы вашего кода.
Когда люди слышат «QA-инженер», они обычно думают: «А, это тот человек, который нажимает все кнопки подряд и заносит баг-репорты в Jira». Ха-ха, мимо.
Всем привет! Я Настя, QA-инженер в «Финаме». Мой путь в тестировании начался с эксплуатации торгово-клиринговой системы «СПБ Биржи», а последние несколько лет я тестирую бэк-офисные и торговые системы. И за это время я убедилась: QA в финансовой компании — это отдельная вселенная.
Сегодня я хочу поделиться чек-листом навыков выживания и развития, которые просто необходимы любому QA в финтехе, — три кота, на которых всё держится.
Кот Смыслюня — с умным видом объясняет, что лимитка не равно рыночка, и спокойно может мурлыкать лекцию про хеджирование в три часа ночи.
В обычном QA баг-репорты выглядят как «пользователь нажал кнопку — система упала». В финтехе сценарий может звучать как «один трейдер выставил заявку на опционы через API ЦБ, а в это время сработала маржинальная проверка, в результате чего вышло несхождение в клиринговом отчете». Ничего не понятно?
Поэтому знание предметной области — основа QA в финансовой сфере. Здесь важно понимать терминологию, специфику работы и все бизнес-процессы: как проходят сделки, что такое дисконтирование, и почему неправильный расчет одного показателя может стать причиной ошибки на миллионы. Я пришла в IT из финансов, работала с брокерами и депозитариями, поэтому мне было немного проще.
Как прокачать предметку? Изучите бизнес-процессы. Разберите базовые термины. И не ленитесь изучать теорию финансов, а не только учебники по Java и Python.
Кошка Табличка —ловко таскает данные из разных таблиц и всегда возвращается домой с добычей. Иногда кусается, если забыли про типы данных.
Без знания SQL вы потеряетесь в финансовом секторе. Тут лучше иметь продвинутые SQL-навыки, например:
агрегаты (COUNT, SUM, AVG) — быстро сворачивают кучу данных в удобный формат;
временные таблицы — магический инструмент. Данные не лежат «готовыми», их нужно поймать, сохранить и присоединить к основной таблице;
JOIN’ы — мостики между таблицами. Без них ваши данные просто стоят отдельно, как несогласованные депозиты на разных счетах;
типы данных и кастинг — часто разные источники хранят одно и то же по-разному. Не забудьте привести к одному виду.
И не храните текст — ID гораздо быстрее. Умение работать с SQL в финтехе — не просто навык, а мастхэв для QA: чем лучше владеете этим языком, тем увереннее двигаетесь в мире цифр и транзакций.
Кот Скриптик —ленивый, но гениальный: «Зачем делать руками, если я могу запустить автотесты и спать дальше?» Избавляет QA от рутины, оставляя время на умные проверки и кофе.
Без автотестов в финтехе никуда, слишком много данных и проверок. Для меня топ — Python, идеален для тестирования SQL-запросов. Конечно, можно и на других языках, всё зависит от задач. Но если только начинаете, Python, простой и с кучей бесплатных курсов, будет вашим спасательным кругом. Я, кстати, стартовала на «Питонтьюторе» — и ничего, выжила!
Пара фишек:
pytest — швейцарский нож для автотестов. Параметризация позволяет запускать кучу тестов с разными данными, не плодя сотни копий кода;
и подружитесь со словариками: они как маленькие контейнеры для данных, очень удобны при работе с результатами SQL или параметрами тестов.
Мой главный совет — выбирайте одну-две рутинные проверки и автоматизируйте их хотя бы по одной в неделю. Через месяц вы не только прокачаете свои навыки, но и покрытие тестами вырастет, и ваша жизнь станет на порядок проще.
Что мы поняли из истории про трех котов? Предметка рулит. Для работы в финтехе нужно знать термины, процессы и специфику инструментов. SQL — ваш супергерой. Без него вы потеряетесь в горах таблиц и хранимок. Автотесты спасают ваши нервы и время. Даже пара тестов в неделю увеличит покрытие и прокачает навыки.
В следующих постах мы с коллегами расскажем больше о работе в финтехе. До скорых встреч!
Рубрика «Тестировщики за 40» — мы решили поделиться историями выдающихся инженеров, внесших вклад в развитие тестирования и обеспечения качества систем — от авторов популярных книг до создателей инновационных инструментов и методологий.
Роман Савин
Помните легендарную книгу «Тестирование Дот Ком»? Её автор, Роман Савин, стоял у истоков русскоязычного QA-сообщества. В 90-х он с нуля освоил профессию в Калифорнии и построил успешную карьеру в Кремниевой долине: работал в PayPal, создавал фреймворки для API-тестирования, обучал новичков в QA.
А потом он круто изменил свою жизнь. Из мира баг-репортов и тест-кейсов он переместился в солнечную Коста-Рику, где занялся производством заквасок для йогуртов. Также новую страсть — пишет книги о СДВГ (синдроме дефицита внимания), помогая людям лучше понять себя и свои особенности.
Хороший пример, как знания и опыт в QA могут стать прочным фундаментом для самой разной жизни.
Лесли Лампорт
Многие знают его как создателя LaTeX — инструмента, без которого не обходится ни одна научная публикация. Но его вклад в мир распределённых систем и формальной спецификации куда глубже. Именно Лампорт сформулировал понятие логических часов — способа упорядочивания событий в распределённых системах без единого источника времени. Это стало основой для построения надёжных, отказоустойчивых сервисов, которые мы используем каждый день.
Кроме этого, он создал язык спецификаций TLA+ — инструмент формальной верификации, с помощью которого инженеры проверяют корректность сложнейших систем до написания кода. TLA+ применяют в Amazon, Microsoft, MongoDB и других технологических гигантах для предотвращения катастрофических сбоев.
И вот что вдохновляет: Лесли Лампорту сейчас 84 года, и только этой зимой он завершил работу в Microsoft Research. Он по-прежнему публикует статьи и участвует в конференциях, доказывая, что для настоящего исследователя возраст — это просто число.
Кристина Комафорд
В 80-х Кристина была обычным тестировщиком в Microsoft: тестила приложения для OS/2 и Windows 3.0, а заодно успела поработать инженером в Lotus, Adobe и Apple. Но на этом она не остановилась — вместо привычной корпоративной карьеры Кристина отправилась строить свой бизнес и основала сразу несколько ИТ-компаний: Kuvera Associates, Corporate Computing, Planet U, Artemis Ventures.
Сегодня она CEO и консультант в собственной компании SmartTribes Institute, помогает бизнесам перестраиваться и выстраивать крутую корпоративную культуру. Плюс — пишет книги и поддерживает стартапы.
История Кристины отлично доказывает: путь из тестирования может привести куда угодно — главное, не бояться экспериментировать и меняться.
Ещё мы делимся другими интересными фактами в QA в телеграм-канале, заглядывайте.
Каждая из этих историй — про развитие, изменения и поиск смысла. А что дала вам профессия тестировщика — помимо багов и баг-трекинга?
