«Нажать кнопку – это уже ручной процесс». Знакомьтесь, Дмитрий Харьков – руководитель отдела тестирования и гость рубрики #внутренняя_кухня. Сегодня обсуждаем, как сейчас устроено тестирование в «Аэродиске» и какие у нас планы на будущее.
– Дима, что изменилось в работе после февраля?
– Рынок кардинально перестраивается. Большинство западных вендоров, к которым мы все так привыкли, ушли с рынка. А многие компании построили на их решениях свои ИТ-инфраструктуры. Но что поделаешь, жизнь продолжается, надо развиваться и поддерживать свое дело.
И у российских разработчиков сейчас, по сути, уникальная ситуация – все внимание обращено на них, появилась какая-то реальная поддержка отрасли, минимум конкуренции. И при этом есть огромный спрос. Данные где-то хранить надо? Надо, поэтому дайте-ка мне хорошую СХД. Виртуализация нужна? Конечно. Ведь в среднем на маленькую компанию приходится минимум 10 сервисов, которые работают изолированно друг от друга. А устанавливать 10 отдельных серверов – такая себе перспектива.
Поэтому, безусловно, работы стало больше, как и требований к продуктам. Люди привыкли к определенному функционалу, который видели у иностранных вендоров, и ожидают того же и от отечественных решений.
– С какими трудностями сейчас сталкивается отдел?
– Не хватает времени и хороших специалистов. Наши продукты Engine/Восток и vAIR/АИСТ быстро развиваются. И чтобы предоставлять клиенту качественное решение, требуется максимально покрывать тестами как новый, так и текущий функционал. Для ускорения работ и повышения качества продукции мы все время добавляем новые сценарии тестирования и оптимизируем внутренние процессы. Также обучаем сотрудников и усиливаем команду новыми кадрами.
Если говорить об уходе западного софта, тот нас (разработчиков и тестировщиков) эта тема не коснулась. Мы пользуемся либо Open Source, либо отечественным ПО, на которое перешли еще давно.
– Как сейчас выстроены ключевые процессы в тестировании?
– Само тестирование программно-аппаратного продукта продукта можно разделить на 3 этапа.
🔷 Сначала проводим визуальный осмотр всех компонентов, которые пришли с производств, на целостность, впервые включаемся, проверяем версии прошивок и определение системы (все ли отображается верно). В случае необходимости сборщики перепрошивают и/или настраивают оборудование.
🔷 Затем делаем стресс-тестирование. Каждый физический модуль изначально смотрим по отдельности, дальше – уже совместно. Самые базовые элементы, которые можно выделить, это сеть, процессоры, память, диски. Среднее время такого стресс-теста составляет около суток, но может варьироваться в зависимости от конфигурации.
🔷 После «физической проверки» оборудования переходим к третьему этапу – ручному тестированию уже готового продукта (ПО+ «железо»). Опять же, в зависимости от комплектации и пожеланий заказчика, проводим как базовый сценарий, так и проверку отдельных компонентов.
Только после вышеперечисленных операций мы можем быть уверены, что продукт готов к встрече с клиентом.
Продолжение следует...
#внутренняякухня #тестирование
– Дима, что изменилось в работе после февраля?
– Рынок кардинально перестраивается. Большинство западных вендоров, к которым мы все так привыкли, ушли с рынка. А многие компании построили на их решениях свои ИТ-инфраструктуры. Но что поделаешь, жизнь продолжается, надо развиваться и поддерживать свое дело.
И у российских разработчиков сейчас, по сути, уникальная ситуация – все внимание обращено на них, появилась какая-то реальная поддержка отрасли, минимум конкуренции. И при этом есть огромный спрос. Данные где-то хранить надо? Надо, поэтому дайте-ка мне хорошую СХД. Виртуализация нужна? Конечно. Ведь в среднем на маленькую компанию приходится минимум 10 сервисов, которые работают изолированно друг от друга. А устанавливать 10 отдельных серверов – такая себе перспектива.
Поэтому, безусловно, работы стало больше, как и требований к продуктам. Люди привыкли к определенному функционалу, который видели у иностранных вендоров, и ожидают того же и от отечественных решений.
– С какими трудностями сейчас сталкивается отдел?
– Не хватает времени и хороших специалистов. Наши продукты Engine/Восток и vAIR/АИСТ быстро развиваются. И чтобы предоставлять клиенту качественное решение, требуется максимально покрывать тестами как новый, так и текущий функционал. Для ускорения работ и повышения качества продукции мы все время добавляем новые сценарии тестирования и оптимизируем внутренние процессы. Также обучаем сотрудников и усиливаем команду новыми кадрами.
Если говорить об уходе западного софта, тот нас (разработчиков и тестировщиков) эта тема не коснулась. Мы пользуемся либо Open Source, либо отечественным ПО, на которое перешли еще давно.
– Как сейчас выстроены ключевые процессы в тестировании?
– Само тестирование программно-аппаратного продукта продукта можно разделить на 3 этапа.
🔷 Сначала проводим визуальный осмотр всех компонентов, которые пришли с производств, на целостность, впервые включаемся, проверяем версии прошивок и определение системы (все ли отображается верно). В случае необходимости сборщики перепрошивают и/или настраивают оборудование.
🔷 Затем делаем стресс-тестирование. Каждый физический модуль изначально смотрим по отдельности, дальше – уже совместно. Самые базовые элементы, которые можно выделить, это сеть, процессоры, память, диски. Среднее время такого стресс-теста составляет около суток, но может варьироваться в зависимости от конфигурации.
🔷 После «физической проверки» оборудования переходим к третьему этапу – ручному тестированию уже готового продукта (ПО+ «железо»). Опять же, в зависимости от комплектации и пожеланий заказчика, проводим как базовый сценарий, так и проверку отдельных компонентов.
Только после вышеперечисленных операций мы можем быть уверены, что продукт готов к встрече с клиентом.
Продолжение следует...
#внутренняякухня #тестирование
Если говорить именно про программную составляющую тестирования, то тут все несколько иначе. Каждый разработчик сначала сам проверяет свой мердж с помощью unit-тестов, затем подключает коллег. Если все в порядке, код отправляется в «CI/CD». Это отдельный стенд, куда автоматически заливается весь новый код, и где запускаются smoke-тесты для оценки работоспособности остальных функций и выявления возможных ошибок. А далее, при позитивных результатах, задача переносится в QA.
Здесь также свои этапы. Ручная проверка, увеличение количества сценариев использования, вновь smoke-тесты, и уже в зависимости от их результатов задача считается выполненной. В случае ошибки – разработчики корректируют, и алгоритм повторяется.
После того, как заранее выбранные для релиза задачи пройдут все этапы, выпускается единая сборка (патч или инсталлятор, зависит от количества и особенностей обновления). Снова smoke-тесты – для проверки работоспособности. Затем идут интеграционные/функциональные/нефункциональные/нагрузочные тесты. На них уже смотрят, как ведут себя все программные компоненты.
Заключительный этап – выходное тестирование. Специалисты проверяют продукт вручную, добавляя новые сценарии. И лишь затем уже можно отправлять патч на оборудование.
Стоит отметить, что все программные решения требуют отдельного внимания и понимания архитектуры. Поэтому для каждого направления выделена своя команда тестировщиков. Это необходимо для более глубокого погружения в продукт и улучшенного выявления различных багов.
Дьявол, как говорится, в деталях. Можно сделать высококлассное решение, но не учесть незначительный, на первый взгляд, нюанс, который в итоге все и испортит. К примеру, возьмем производственное помещение. Казалось бы, а что тут такого? Освободить достаточно места для сборки оборудования, да обеспечить бесперебойное электроснабжение и охлаждение. А вот и нет. Есть такая штука, как статическое электричество. И по своему опыту работы в техподдержке могу сказать, что из-за него немало оборудования вернулось обратно производителю сразу после первого включения.
Мы в «Аэродиске» достаточно серьезно подошли к этому вопросу. В помещении, где проходит выходное тестирование, установили специальный набор, включающий:
🔸 напольное покрытие;
🔸 антистатическая краска на стенах;
🔸 специальное ковровое покрытие на столах;
🔸 ионизаторы.
Не менее серьезно относимся к совместимости наших продуктов с решениями других вендоров. К сегодняшнему дню мы подобрали базовые шаблоны сценариев тестирования, которые помогают быстро определить, совместимы ли продукты.
Если требуется посмотреть «что-то новое», к чему таких тестов нет, мы оперативно подбираем возможные варианты использования и делаем ручную проверку. А именно: собираем сценарии ситуаций, которые могут возникнуть в процессе работы оборудования, моделируем ошибки и отслеживаем, как отрабатывает совместный ПАК. После этого, разумеется, создаем еще один шаблон.
– К какому результату стремитесь в будущем?
– Я бы здесь ответил лозунгом: «Автоматизировать то, что еще не автоматизировано, а что автоматизировано – нужно оптимизировать до полнейшей автоматизации. Ведь нажать кнопку – это уже ручной процесс».
Также помимо автоматизации и усиления тестирования, есть желание привнести в компанию инструмент, который улучшит качество продуктов. Когда я работал в других организациях, нередко в процессе тестирования применяли открытую платформу для проверки «железа». В «Аэродиске» я хочу создать что-то подобное, только модифицировать под актуальные требования и нужды.
#внутренняякухня #тестирование
@aerodisk_official — трезво про импортозамещение в ИТ
Здесь также свои этапы. Ручная проверка, увеличение количества сценариев использования, вновь smoke-тесты, и уже в зависимости от их результатов задача считается выполненной. В случае ошибки – разработчики корректируют, и алгоритм повторяется.
После того, как заранее выбранные для релиза задачи пройдут все этапы, выпускается единая сборка (патч или инсталлятор, зависит от количества и особенностей обновления). Снова smoke-тесты – для проверки работоспособности. Затем идут интеграционные/функциональные/нефункциональные/нагрузочные тесты. На них уже смотрят, как ведут себя все программные компоненты.
Заключительный этап – выходное тестирование. Специалисты проверяют продукт вручную, добавляя новые сценарии. И лишь затем уже можно отправлять патч на оборудование.
Стоит отметить, что все программные решения требуют отдельного внимания и понимания архитектуры. Поэтому для каждого направления выделена своя команда тестировщиков. Это необходимо для более глубокого погружения в продукт и улучшенного выявления различных багов.
Дьявол, как говорится, в деталях. Можно сделать высококлассное решение, но не учесть незначительный, на первый взгляд, нюанс, который в итоге все и испортит. К примеру, возьмем производственное помещение. Казалось бы, а что тут такого? Освободить достаточно места для сборки оборудования, да обеспечить бесперебойное электроснабжение и охлаждение. А вот и нет. Есть такая штука, как статическое электричество. И по своему опыту работы в техподдержке могу сказать, что из-за него немало оборудования вернулось обратно производителю сразу после первого включения.
Мы в «Аэродиске» достаточно серьезно подошли к этому вопросу. В помещении, где проходит выходное тестирование, установили специальный набор, включающий:
🔸 напольное покрытие;
🔸 антистатическая краска на стенах;
🔸 специальное ковровое покрытие на столах;
🔸 ионизаторы.
Не менее серьезно относимся к совместимости наших продуктов с решениями других вендоров. К сегодняшнему дню мы подобрали базовые шаблоны сценариев тестирования, которые помогают быстро определить, совместимы ли продукты.
Если требуется посмотреть «что-то новое», к чему таких тестов нет, мы оперативно подбираем возможные варианты использования и делаем ручную проверку. А именно: собираем сценарии ситуаций, которые могут возникнуть в процессе работы оборудования, моделируем ошибки и отслеживаем, как отрабатывает совместный ПАК. После этого, разумеется, создаем еще один шаблон.
– К какому результату стремитесь в будущем?
– Я бы здесь ответил лозунгом: «Автоматизировать то, что еще не автоматизировано, а что автоматизировано – нужно оптимизировать до полнейшей автоматизации. Ведь нажать кнопку – это уже ручной процесс».
Также помимо автоматизации и усиления тестирования, есть желание привнести в компанию инструмент, который улучшит качество продуктов. Когда я работал в других организациях, нередко в процессе тестирования применяли открытую платформу для проверки «железа». В «Аэродиске» я хочу создать что-то подобное, только модифицировать под актуальные требования и нужды.
#внутренняякухня #тестирование
@aerodisk_official — трезво про импортозамещение в ИТ
