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