Предпосылка 1: Низкий уровень подготовки тестировщиков
До начала войны я работал лидом команды тестирования в достаточно крупной международной компании. Я пришел в компанию из автоматизации финучета. Кроме того, у меня был относительно свободный год, который я потратил на изучение полного цикла производства ПО: от разработки архитектуры, планирования проектов, ведения Scrum-проектов, реализации кода и заканчивая CI/CD и тестированием.
Как лид я, конечно же, проводил множество собеседований и обнаружил, что уровень тестировщиков катастрофически низкий. Как следствие, отношение к тестировщикам всегда было (и есть) как к самой низкоквалифицированной IT-профессии. Я бы сравнил это с отношением к уборщице, которая моет полы у программистов в кабинете и только поэтому имеет отношение к IT…
Предпосылка 2: Обучающие компании – инфоцыгане
Началась война. Никто ничего не мог понять, и разные компании повели себя по-разному: кто-то профинансировал сотрудников на релокацию в более безопасные города, кто-то решил всех кинуть на произвол судьбы. Компания, где я работал, решила идти по пути сокращения и первыми сократила тестировщиков, а вторыми — все команды с проектами в процессе разработки. Зарплаты за последние месяцы не выплатили, но это уже совсем другая история…
Через какое-то время мне предложили написать и вести курс по тестированию, и я, конечно же, согласился (я очень люблю преподавать). Первую версию плана курса мне отклонили, сказав, что это слишком сложно и “не нужно”. Наша целевая аудитория — неудачники и пенсионеры 🙂 Мне предложили посмотреть курсы конкурентов. Я посмотрел и понял: нет цели научить — есть цель продать “воду”, пока тема “войти в IT” (ненавижу этот слоган) в тренде.
Курс я все равно написал более или менее информативный (пришлось по требованию инфоцыган добавить темы с “водой”, но минимально). Обучил по нему больше 100 студентов, отзывы можно посмотреть в этом видео:
Ну а деньги за половину проданных курсов я, конечно же, не получил. А чего можно ожидать от инфоцыган (но об этом как-нибудь в другой раз).
Предпосылка 3: Опыт работы с ERP-системами
Я имею достаточно большой опыт работы с ERP (Enterprise Resource Planning) и являюсь большим поклонником таких систем. Идея в том, чтобы иметь целую экосистему программ, связанных между собой, но работающую с абсолютно разными ресурсами предприятия.
Упрощенный пример: у нас есть интернет-магазин, состоящий из сайта, колл-центра, склада и бухгалтерии.
- На сайте клиент делает заказ товара — это одна “программа”.
- Заказ попадает в колл-центр, и сотрудник колл-центра созванивается с клиентом, подтверждает наличие товара, уточняет дату доставки и т.д. Кстати, этот этап — это только наша украинская ужасная практика. Ненавижу, когда мне звонят для подтверждения: я же уже все выбрал на сайте и даже оплатил. Зачем? Тем не менее, это вторая программа — программа колл-центра.
- После подтверждения заказа товар попадает на склад — это третья программа, программа складского учета.
- Наконец, информация о продажах, поступлениях денег, списании товара со склада, рабочих днях сотрудника и т.д. из всех других программ системы попадает в программу финансового учета, где собирается вместе и формирует как управленческие отчеты (для собственника), так и бухгалтерские — для ведения учета.
Кто такой SDET?
«Инженер по тестированию программного обеспечения (SDET) также является разработчиком, но его внимание сосредоточено на тестируемости и общей инфраструктуре тестирования. SDET’ы рассматривают дизайны и внимательно изучают качество кода и риски. Они рефакторят код, чтобы сделать его более тестируемым, и пишут фреймворки для модульного тестирования и автоматизации. Они являются партнерами в кодовой базе SWE, но больше озабочены повышением качества и покрытия тестами, чем добавлением новых функций или увеличением производительности.»
Д. Уиттакер, Д. Арбон, Д. Каролло «Как мы тестируем в Google»