- PVSM.RU - https://www.pvsm.ru -
Задача: Компания (далее Компания) разрабатывает и выпускает некоторый продукт (далее Продукт). Необходимо создать программное обеспечение для проверки Продукта на сборочной линии (далее Линия) некоторой сторонней или принадлежащей компании фабрике (далее Завод).
Вы: разработчик тестового ПО для проверки Продукта, или менеджер этих разработчиков, или вообще менеджер, или инженер, или тестер широкого профиля… в общем лицо, ответственное теперь за проверку работы Продукта на выходе. У вас есть некоторый опыт лабораторного тестирования, но нет накопленного опыта работы с фабрикой.
Цель: Грамотно сгладить ошибки разработки тестового ПО для фабрики, допускаемые в процессе жизненного цикла Продукта.
Примечание: под Продуктом понимается некоторое устройство или его часть, обладающее внутренней логикой, SW / FW / Функционал которого требуется проверить. Пример: сотовый телефон, контроллер, программируемые устройства, материнская плата.
В данной заметке я поделюсь своим опытом, накопленным за последние 4 года. Надеюсь, он позволит вам сэкономить лишние человеко-часы и нервы, повысив при этом качество выпускаемого продукта.
Заметка ориентирована на опытного разработчика, тестера, технического руководителя и менеджера. Однако, если вам не достает опыта, но у вас есть время, прочитайте, так как чужие ошибки могут быть ценным источником знаний.
Информация представлена в виде большого «чеклиста» из действий, которые необходимо сделать, с пояснениями и примерами. Любителям аргументировать, начиная с «а у нас не так», повторю, я делюсь своим опытом, который помог мне и работодателю не ударить в грязь лицом.
Если вы ее застали стадию дизайна Продукта и имеете голос, донесите до менеджмента, что наличие любого тестового интерфейса, доступного на момент сборки Продукта, может сильно облегчить жизнь на фабрике. Вам немедленно последует возражение, что на любой плате есть тестовые точки и контактные разъемы некоторых портов. Вопрос, которые вы должны будете задать: «А будут ли они доступны когда Продукт будет в сборе? Как осуществлять такие-то проверки, когда не будет дырочки, в которую можно вставить шнур?»
Эти простые вопросы и ответы на них определят будущее вашего проверяющего ПО. Экономия на тестовом интерфейсе, может вылиться в бутылочное горлышко при тестировании на Линии (об этом ниже), простой которой может стоить больше чем лишний порт на плате.
Пусть интерфейс есть в дизайне. Обратитесь к разработчикам железа и ПО Продукта и выясните, не противоречит ли правилам, нормам и стандартам безопасности данный интерфейс. Например, само наличие тестового USB порта может лишить Продукт сертификации. Read / Write доступ через Serial порт может сделать тоже самое (даже если от порта на плате лишь ряд контактов).
Мысли о том, что порты не уберут, и вы через них будете посылать тестовые команды, вызывать некоторые API, могут быть очень опасны. Общение с портом в конечной версии Продуктового ПО может быть просто заблокировано. В идеальном случае, он может быть открыт только на вывод информации. Просьба не путать это с read. Read подразумевает доступ к конкретной информации. Не помешает и бдительность при переходе с одной версии железа на другую (P0 --> P1 --> …), волшебный порт может так же волшебно исчезнуть. Менеджмент HW команды и их решения не постоянны.
Важно понимать, что как только внятная логика будет работать на железе, разработчики железа начнут создавать машину, которая будет отправлена на фабрику (или уже там есть) для проверки HW продукта и его частей. Вы знали о такой машине? Нет? А она существует.
Машина может быть элегантным готовым решением стороннего производителя или каким-то алюминиево-пластиковым монстром внутренней разработки, содержащим в себе сторонние узлы и агрегаты с жуткой смесью «самопала».
Никогда не придирайтесь к внешнему виду данной машины, очень часто она такая из-за требований безопасности на производстве. Простой вольтметр может быть прикручен к бетонной плите, только для того чтобы избежать падения вследствие вибраций конвейера.
На этапе строительства данной машины вас скорее всего будут спрашивать про оборудование, которое потребуется для тестов. Здесь необходимо иметь четкую картину отличия лабораторных тестов (одно устройство из партии проходит проверку) и производственных тестов (каждое устройство проходит проверку).
Разработчики железа и Продуктового ПО – параноики. Требования на тесты в машину HWщики пишут сами. Обязательно пройдитесь по всем и задайте вопросы: «Что вы хотите проверить этим тестом (покрыть этим требованием)? И почему вы это хотите проверить? И почему именно так?» После пары часов беседы вы сильно удивитесь как 10 требований превратятся в одно, а то и в 0.
По умолчанию они включат в документацию тестирования на Линии все, что можно. Не поддавайтесь. «Да ведь тест занимает всего 3 секунды!!!» — «Да, тест – 3 секунды. Подключение устройства на тест 1 минуту, итого для одного устройства 63 секунды, на 100 000 устройств это займет 70 человеко-дней». Всегда имейте холодный и трезвый расчет ресурсов в голове или в виде таблицы под рукой, иногда это единственный аргумент в борьбе за исключение или изменение теста. Убедитесь, что ваша аргументация доведена до собеседника. Убедитесь, что все договоренности закреплены на бумаге, так как машина будет сделана и сдана строго по документации. И если там будет написано, что тест есть, а вы как бы договорились, что его нет, то виноваты вы сами.
Все, что вы оставите в документе, будет производственным тестом. Все, что исключите, станет лабораторным тестом.
Пример. Продукт – радиочастотные модули (прием/передача сигнала). HW команда ставит перед вами требование проверить все каналы 3х радиочастотных диапазонов. Простое описание количества каналов (их много) и грубая прикидка времени собьет их пыл. Проверка всех каналов – это теперь лабораторный тест (Тест 1). Тогда они станут требовать проверить пограничные каналы для каждого диапазона (это 2*3=6 каналов). Однако, все эти каналы будут покрыты в «Тест 1». Вуаля, у вас теперь лишь требование проверки работы на трех диапазонах, а это всего 3 канала.
Читатель может возразить, что если мы производим радиочастотные модули, то надо проверять все каналы для всех устройств. Конкретный ответ будет зависеть только от класса и стоимости производимых устройств. Достаточно провести сравнение затрат по полному циклу тестирования для каждого устройства и по гарантийному обслуживанию бракованных устройств при одинаковом распределении брака в партии, это голая математика. Плюс ко всему, помните, что к моменту массового выпуска на всех версиях железа и ПО будут уже проведены многочисленные тесты (sanity, feature, functional, stress, stability, burn…), которые многократно покроют и перекроют все требования HW и SW команд.
Второй и очень важный момент – это железо и setup, который потребуют от вас для машины, чтобы покрыть тесты. Обсуждение c HWщиками конкретных методик выполнения оставшихся требований, позволит вам определить круг и функционал необходимого оборудования. Ошибка, которою может допустить новичок, заключается в том, что вы видите только одну машину перед собой или ее часть. А она может быть более сложнее, чем вам покажут, и их на фабрике может быть несколько. Задайте себе и им вопросы: «Не будут ли узлы внутри машины мешать друг другу? Не будут ли машины, стоящие рядом на фабрике мешать друг другу?» Попытайтесь в теории учесть ВСЕ – механические помехи, электромагнитные помехи, интерференцию, дублирование, износ и тп.
Пример. Вернемся к предыдущему. Нам необходимо покрыть 3 канала из каждого диапазона. Значит нам нужно 3 приемника/передатчика, или 1 программируемый. В рамках одной машины нет никаких проблем с реализацией. А теперь поставьте в ряд 3 машины, между которыми нет экранов. Что получили? На ум сразу приходят помехи и интерференция. Что еще? Дублирование каналов. «Но ведь машины можно настроить на разные радио каналы, ведь в диапазоне есть из чего выбрать». Да можно и так, но представьте ситуацию. На завод приходят 3 одинаковые машины, на каждую идет том инструкций, и они отличаются только 2мя-3мя строчками с указанием частоты каналов. Обратит ли инженер, собирающий и настраивающий их, на это различие? Скорее всего нет. Будет очень хорошо, если он прочтет хотя бы один мануал полностью. В итоге, на Линии окажутся 3 машины с одинаковыми каналами: А(1, 2, 3), Б(1, 2, 3), С(1, 2, 3). Линия запускается и устройство, которое должно быть на А(1), общается с С(1). Если вы думаете, что вина на такую настройку ляжет на инженера, то учтите, что он имеет право менять требования к тестовой машине и изменять ее, и свою ошибку он может списать на такое изменение. Например, три сборочные Линии (по N машин на каждую) не могут делить RF диапазон, так как он занят другим оборудованием, и настройка каждой машины на свой RF канал может быть просто невозможна.
Помните, что узлы и агрегаты машины, используемой на Линии, должны оттестировать не 1 устройство, а тысячи. Не переносите свой лабораторный опыт на Завод. Разрабатывайте методику тестирования заново.
Пример. Продукт тот же, что и ранее. Ставят задачу проверить выходной уровень сигнала (мощность). Шаги: берем устройство, подсоединяем тестовую антенну, измеряем выходную мощность, отсоединяем тестовую антенну, подсоединяем заводскую, отправляем устройство далее. Механический износ тут может быть критичен. Тестовая антенна должна выдержать тысячи присоединений без потери качества передачи сигнала (иначе много устройств пойдут в брак). Разъем на Продукте тоже должен выдержать несколько подсоединений и оставить запас на будущее. Для многих открытие, что антенные разъемы на любимых нами ноутбуках и сотовых телефона предназначены всего на 10 циклов присоединения/отсоединения антенны. Сколько их у нас? На рассматриваем тесте 2. Само устройство может попасть на тест раза 3 (уже 6), а потом еще пройти пару циклов пересборки (уже 12). 12 больше 10, значит риск забраковать устройство на линии своими тестами – велик. Значит необходимо разговаривать с HWщиками, искать альтернативу, или делать тест лабораторным. И если «затырканных» устройств всего 2%, это очень много (2000 из 100 000).
Пусть тест все же включили в производственный цикл. Какое оборудование будет производить измерение? Даже если «контора платит», не стоит создавать боинг. Не переносите свой лабораторный опыт на Завод. Лучше всего остановиться на оборудовании, которое будет требовать меньше всего поддержки и может быть откалибровано на месте без отправки в сервисный центр. Еще лучше, если у вас в запасе всегда будет альтернатива.
В предыдущем пункте у вас уже скопится некоторая база тестов, применимая к проверке HW. Там же начнется их разделение на лабораторные и производственные.
Пусть нас уже есть некоторый рабочий и не сильно сырой Продуктовый софт. Тогда настало время вести диалог о проверке, готового устройства. Тактика точно такая же, но теперь опрашиваем разработчиков продуктового ПО и Менеджеров Продукта. Вопросы: «Что и как вы хотите тестировать на фабрике? Почему? Почему именно так? Что вы использовали ранее для подобных продуктов? Есть ли требования на проверку готового устройства?».
Как правило, вы – не первопроходец. До вас была куча людей, которые занимались похожим делам, после них останется часть toolов, документации к ним и требования. Изучите все, сопоставьте с ответами разработчиков и менеджеров, выделите риски, и составьте план действий.
Просмотрев все, большой ошибкой будет сказать самому себе: «Это все устарело! Дизайн кривой! Код написан криво! Я все сделаю с нуля сам!». Помните, что эта старая «фигня с кривым дизайном и кодом» оттестировала на фабрике и/или в лаборатории кучу всего еще до вас. Значит, она (фигня) со своей задачей справилась, а вы пока нет.
Изучив всю документацию и покопавшись в коде предшественников, составьте список получившихся тестов. Постарайтесь оформить его как технические требования к будущему тестовому ПО, примерно так же как это делали HW разработчики для своей машины. Дело в том, что стандартная документация внутри компании очень похожа. Вам все равно придется все описывать для фабрики, а так у вас уже будет готовый черновик, который можно предоставить по первому требованию.
Полученный список обсудите с коллегами внутри команды. Это может быть официальное Review или простая беседа. Интересуйтесь, как бы они сделали тот или иной тест. Фиксируйте любые даже абсурдные аргументы. В результате вы сами для себя получите дорожную карту почти на каждый тест. Естественно их количество может увеличится или сократится.
Конечный черновик разбейте на лабораторную часть и производственную часть. Если у вас есть команда, то данное разбиение необходимо пустить снова на review.
Перед тестерами все чаще ставят задачу автоматизации тестов. В списке вакансий «ручное тестирование» оценивается ниже «умения автоматизировать».
Помните одну простую вещь: «Автоматический тест покрывает только тот алгоритм, который в него заложен. Он никогда не может проверить шаг влево или вправо от алгоритма. Он никогда не найдет вспомогательную проблему. 100 ручных тестов могут найти 200 проблем. 1000 автотестов могут быть написаны так, что заведомо всегда будут PASS».
Золотая середина – наличие тестов двух видов в рамках каждой фазы тестирования.
Не смотря на сказанное выше, лабораторные проверки, лучше всего автоматизировать. Обычные рутинные тестовые прогоны основных веток Продуктового SW (feature test, sanity) все равно будут выполняться кем-то из команды, вот там и должна быть «золотая середина». Лаборатория может и должна проверять только самые сложные и критические для Продукта и сертифицирования тесты.
Если вам необходимо продолжать лабораторное тестирование и готовить тесты на Линии, то лаборатория – прекрасное место, чтобы откатать методики работы с тестовыми интерфейсами и методами автоматизации, которые вы планируете использовать на фабрике. Критерий «хорошего» метода – его стабильность (100 000 устройств должны пройти тест). А как же скорость выполнения тестирования? Скорость – приятный бонус, которого может не быть. Вспомните теперь кривой дизайн уродливого кода из прошлого пункта. Вот он стабилен. Возможно его уродливость есть следствие его стабильности?
Главные инженеры, процессники (классический QA) и безопасники проектируют линию и составляют документацию. В ней описаны шаги производства на линии. Одним или несколькими шагами будет использование вашего ПО (тестовой станции, или тестовой линии). Добавить или удалить шаг из данного процесса, когда он запущен, крайне сложно и практически невозможно.
Большинство Линий – это конвейеры типа линия или змейка.
Пример. Представьте конвейер – змейку, который занимает производственное помещение полностью (100 человек, 3 смены). Там есть только место для эвакуации, работы сотрудников и транспортные линии (подвоз комплектующих). Вставить в данный конвейер какой-то узел просто невозможно. Он или не войдет (физически нет места) или не пройдет проверку безопасности (пожарные требования и пр). Если же узел вставить необходимо, то конвейер полностью будет остановлен и, скорее всего, разобран. Далее будет составлена новая документация, сборка и настройка будет осуществлена заново, приемка и отладка тоже займет некоторое время, а 300 рабочих будут получать зп так же как и получали.
«Вон там в углу есть место, давайте туда поставим!». Такое даже говорить нельзя. Невозможно снимать со змейки продукт, тащить его в угол а потом возвращать на место в змейку. Возникнет путаница и хаос.
На этом шаге от вас могут попросить описание рабочей станции оператора, использующего ваше ПО. Естественно, это будет PC и набор необходимых тестовых инструментов и узлов. Barcode reader – это тестовый инструмент, Ethernet шнур – тоже, USB шнур – тоже и тд. Отнеситесь серьезно и опишите все до винтика, документацию в процессе разработки тестового ПО можно будет править, чем больше вы укажете в начале, тем меньше вам придется добавлять потом.
Так же вас спросят, как примерно будет работать станция, и что необходимо делать оператору. И, естественно, попросят список требований к вашему ПО. Вспоминаем, что вы уже подготовили черновик в шаге 4. Он будет перенесен на стандартные шаблоны документации, подвергнут review и возвращен вам на доработку как список требований к тестовому ПО, но уже от имени фабрики. То есть ваш черновик вернут вам же как утвержденный набор требований и план. Поэтому важно исключить из него все «плохое» на шагах 1-4.
Все эти действия будут направлены на то, чтобы понять сколько под ваш шаг на Заводе отворить места.
Не думайте, что там будет 1 оператор на 1 тестовую станцию. Или что они поставят то же железо, что вы дали в списке. Все будет сложнее.
Главные инженеры будут работать с тем, что есть, и с тем, что им дадут. Скорее всего ваш тестовый модуль будет разобран на части и собран некоторый кластер или гибрид из N станций, работа которого не будет противоречить указанному вами описанию и требованиям.
Самое главное, о том, что получится в конце, вам вряд ли скажут. Так как сами в начале не будут этого знать, а потом просто «забудут» прислать конечное или хотя бы черновое описание того, что получилось.
Имейте это в виду, читая дальнейшие мои рекомендации.
После того как ваше тестовое ПО будет готово, оно должно пройти стадии приемки, инженерного внедрения и внедрения на линию.
Внесение любого изменения или просто выпуск новой версии ПО будет подвержен тем же самым стадиям приема и внедрения. Даже если это всего лишь один printf в коде.
Дизайн – ваше все. Логическая схема структуры вашей программы должна быть максимально гибкой. Каждый из ее узлов должен быть настраиваемым, стабильным и самостоятельным. Здесь как никак уместно review, мозговые штурмы и тп.
Хороший дизайн (включая UI) спасет вам жизнь и будет главным фактором экономии человеко-часов в будущем.
Структуру наверное любого тестового ПО можно представить в виде следующих пунктов:
Все эти пункты будут рассмотрены далее.
Казалось бы, все просто. Тесты определены, требования представлены, садись и пиши. На первый взгляд даже можно обойтись скриптом строк в 500, а то и меньше, вот тут уже даже есть почти готовый open source tool… Не спешите так думать.
Завод и Компания могут иметь вполне конкретные ограничения на использование сторонних готовых приложений. Например, для Web автоматизации вы можете использовать Python и библиотеки Selenium, так как это относится к Programming Language, но не сможете использовать Python и Curl, так как последний является готовой сторонней программой, которая не прошла приемку внутри Компании. Вы, конечно, можете провести приемку Curl сами, но это займет время и ресурсы, а конечный результат будет неизвестен (могут отклонить). Вы можете конечно засунуть Curl код в свой и сделать вид, что так оно и надо. Но не стоит недооценивать коллег «по цеху».
Вспоминаем снова уродливый не красиво написанный инструмент предшествующих проектов. Может быть он такой от того, что использовал только то, что прошло приемку внутри Компании?
Даже если в Компании похожих правил нет, то на Заводе они будут. Узнайте о них заранее.
Пользоваться вашим продуктом будут обученные операторы. Не обученные им пользоваться не должны. Подумайте над способом авторизации оператора, заступившего на смену.
Самая простая – считать пропуск (badge) сотрудника. Однако, доступа в сеть на проверку пропуска сотрудника у тестовой станции может не быть, так что авторизация должна быть сделана (еще и) локально.
Так же должен быть легкий способ у привилегированных лиц заносить и удалять ID операторов из локального реестра пользователей. Операторы – люди, они могут менять место работы, или болеть.
Так же должен быть легкий способ заносить и удалять ID привилегированных лиц из локального реестра. Эти лица – тоже люди, а конвейер не может стоять.
Изменение списка лиц не должно быть сложной процедурой типа «установите SQLite, составьте запрос...», это должен уметь делать человек с квалификацией гораздо ниже чем у вас. Более того, это должно быть легкой процедурой.
Простой текстовый файл со списком пользователей может быть выходом, но такую простоту могут научиться править и не авторизованные операторы тоже.
Как быть, решать вам.
Ваша программа должна быть максимально гибкой.
Я настоятельно рекомендую вынести наружу все константы и параметры. Нестандартно, да? Соберите их в отдельном текстовом файле и используйте их в качестве настроек вашей программы при запуске. Они все должны быть понятным и читаемыми. Инструкции (а вам придется писать User Manual) типа «посчитайте третий бит старшего байта значения параметра» не приемлемы. Оператор должен уметь исправить значение сам. Помним, что его квалификация и опыт могут быть ниже чем у вас.
Зачем так делать? В список параметров часто входят счетчики циклов Retry, таймауты и прочие вещи, на которых можно сэкономить секунду-минуту, просто поиграв параметрами. А основательно поиграть ими можно будет во время инженерного внедрения.
Для Линии это очень актуально. Если устройство тестируется 10 минут, то за сутки максимум – это 144 теста. Тогда экономия в 1 минуту, увеличит максимум до 160. Кластер из 10 станций в этом случае отправит на склад больше устройств. Экономия человеко-дней на Линии тут очевидна.
Если у вас есть много тестовых портов, то лучше не останавливаться на каком-то одном, а сделать поддержку всех доступных. Они так же должны иметь возможность конфигурироваться автоматически или в ручную.
Пример. Вы можете протестировать устройство через USB или SERIAL. Создайте такую настройку в отдельном текстовом файле «Test PORT: AUTO / USB AUTO / SERIAL AUTO / SERIAL COM6». Этот метод позволит вам повысить гибкость вашего ПО. Вам не придется судорожно менять код, заполнять бумаги и проводить приемку, если что-то пойдет не так.
Данную рекомендацию можно расширить и распространить на любые вспомогательные значения, используемые во время выполнения тестов.
Пример. К станции цепляется устройство, которой получает IP c DHCP сервера самой станции. А через USB станция получает доступ к Linux консоли устройства. Вы можете найти IP тремя способами: PING / ARP, через Linux консоль, обратившись к DHCP серверу через его API. Первый вариант сильно зависит от конфигурации сети (вспоминаем про объединение станций в кластеры), второй вариант сильно зависит от уровня доступа по USB (вспоминаем про разные стандарты безопасности устройств, которые могут быть внедрены уже в процессе производства), третий вариант требует наличие специфического DHCP сервера, который может быть не установлен на Линии, и вместо него может быть другой. Но крах всех трех вариантов, маловероятен.
Иными словами, больше гибкости – меньше проблем.
С тестируемого продукта всегда считываются какие-то ID, которые потом используются в качестве доказательства и документального подтверждения в отчетах, что устройство прошло тест.
Ряд этих параметров должен считывается всегда в строгой последовательности. Нестрогая последовательность вызовет путаницу среди операторов.
Предположим на устройстве 6 штрих кодов. Вас просят считать, проверить и использовать только 3 из них. Поработайте над дизайном кода и UI так, чтобы внесение проверок дополнительных штрих кодов не сильно изменило внешность программы и ее код.
Можете сделать поля в UI для всех IDшек (штрих кодов) сразу с занесением дополнительных настроек в текстовый файл, чтобы включать или отключать соответствующий UI элемент при необходимости. Но помните, что сильное изменение UI требует большего времени для переобучения операторов. Это может быть встречено в штыки на Заводе. Процессы обучения и привыкания для операторов – стресс. Они (в отличии от вас) будут стоять по 8 часов в день у тестовой станции, и лишняя головная боль им ни к чему.
Эта часть вашего ПО должна быть для оператора самой невидимой, и чем меньше дополнительных шагов в ней будет, тем лучше.
Это самый креативный для разработки шаг. Очень редко когда можно придумать сценарий без дополнительных ручных манипуляций, особенно когда у вас отсутствует тестовый интерфейс (вспоминайте пункты 1 и 2).
Разберем пару примеров и увидим чего стоит бояться, а чего нет.
Пример 1 (Чего стоит бояться). Вы просите оператора в начале тестирования вставить USB, а в середине тестирования вытащить USB, реализовано в виде диалогового окна.
Опасные моменты:
А). Физический износ — USB кабель может рано или поздно физически поломаться или износиться. Ваша программа такое предусматривает?
Б). Нестабильные драйвера устройств по умолчанию — Вы используете PC в сборке которых (HW или SW) скрыта нестабильность работы с вашим USB драйвером. Это может привести к отказу USB hub на материнской плате PC или подвиванию драйвера. Помните ли вы как часто в процессе разработки у вас неправильно определялся Продукт по USB? Были ли у вас случаи на вашем PC выхода из строя USB портов или touchpad (он тоже часто висит на USB hub) так, что помогала только перезагрузка? Ваша программа такое предусматривает (особенно если Завод будет использовать те же станции, что и ваш рабочий PC)?
В). Несовместимость стандартов — Вы писали код для поддержки только USB 2.0, а на PC с USB 3.0 у вас проблемы со стабильностью. Вы вносите в требования (шаг 6) использования PC только с USB 2.0. Наивно полагать, что его выполнят в точности при повсеместном внедрении USB 3.0. Завод будет использовать то, что есть, чтобы сэкономить. Вы можете сделать некоторый workaround, посоветовав им отключить USB 3.0 в BIOS. Отключение в BIOS имеет некоторые ограничения и сильно зависят от chipset и реализации USB hub на материнской плате. Например, есть платы с честной поддержкой и 2.0 и 3.0 сразу. Есть платы где BIOS можно выбрать или 2.0 или 3.0. А есть платы где ничего нельзя выбрать и у вас может быть только 1 порт на 2.0. Хватит ли вам этого? Ваша программа такое предусматривает?
Г). Ваш собственный драйвер работает нестабильно. Вот только честно, вы его достаточно хорошо тестировали?
Пример 2 (Чего бояться не стоит). Вы просите оператора вставить Ethernet кабель в начале тестирования, а в середине вытащить его.
Здесь не стоит бояться автоматизировать этот шаг. Для этого необходимо провести некоторое исследование и найти, например, Ethernet switch/router, который физически может выключать питание на конкретном порту и имеет возможность делать это через Serial. Тогда вам не придется просить вытаскивать кабель.
Вы даже можете попытаться сами «спаять» такое устройство. «А так можно?». Нужно! Некоторые простые тестовый коробки, проверяющие проводимость или регулирующие питание на своем пути сделаны с использование дешевых платформ (Arduino, Raspberry Pi). Главное – стабильность работы.
Провести такое устройство по всем правилам приемки не составит труда, так как не будет уже сторонним решением, а будет частью вашего тестового ПО (как баркод сканер).
Внимательный читатель спросит: «Значит Curl из примера шага 6 нельзя сделать частью программы, а самопайное устройство можно?». Ответ: «ДА». Требования к устанавливаемому на станцию софту легче формально ограничить, чем требования к железу. Информационная безопасность и ее принципы формулируются гораздо легче, чем те же правила, применимые к HW. Последние жестко используются лишь на военных заводах и там, где действительно можно что-то украсть.
Теперь поговорим о логике реализации этих тестов. Повторю, что дизайн – ваше все. Каждый из узлов должен быть настраиваемым, стабильным и самостоятельным. То есть обязательно сделать каждый тест отдельным и независимым от остальных. На практике это не всегда удается сделать, но применить такой подход к группам тестов удается в 100% случаев. Это и позволит вам варьировать наличие и последовательность тестов. «Зачем? Зачем так делать? Ведь есть же требования и все определено уже! Мы все описали и отправили на линию». Это так, но требования могут попросить переделать или поменять. Количество тестов могут расширить или уменьшить. Все это приведет к изменению кода и времени работы программы. Более того на Линии Продукт проходит несколько этапов тестирования.
Пример. Вы составили требования на станцию и тестовый софт и отправили их на фабрику. Там решили, что будут использовать ваш продукт для тестирования голой борды после прошивки и готового Продукта (борда в корпусе в сборе с остальными частями). Об этом решении вам могут даже не сообщить. Для Завода главное, чтобы ничего на стадии планирования Линии не противоречило поставленным требованиям, которые вы уже отдали, а они уже одобрили. Эти 2 шага (борда и Продукт) – 2 физически разных места на Линии. Естественно предположить, что для голой борды тестов нужно меньше чем для Продукта в сборе. Тут на помощь и придет возможность выполнять не все тесты. Более того, это ускорит процесс на линии.
Последние и очень важное, о чем стоит упомянуть в этом пункте, это сами тесты.
Пример. Предположим, что ваш Продукт – роутер, ваша задача – проверить один Ethernet порт на нем, дающий доступ к web настройкам устройства. Пусть даже у вас есть тестовый интерфейс, который дает вам полный доступ к консоли устройства (a la telnet). Подойдите к разработчику и спросите: «Как проверить данный порт?» Скорее всего ответом будет: «У меня есть приложение, которое надо залить через USB и запустить через консоль, оно поочередно вызовет некоторые API, и в результате будет видно работает порт или нет». Как только вы услышали слово API, то вам надо идти в другую сторону. Проверка API проверит только API. А ваша задача – проверить устройство. В идеале тест должен подменять собой действия пользователя. Давайте посмотрим, как можно вообще протестировать данную ситуацию.
Вариант от разработчика отпадает. Остаются варианты через тестовый интерфейс и напрямую через Ethernet.
Подсоединяем Продукт к тестовой станции через тестовый интерфейс и Ethernet. Доступ к консоли дает возможность узнать IP и запустить трафик в обе стороны (iperf, ping, wget). Один вариант есть. Но что если тестовый интерфейс уберут? Тогда остается Ethernet. Подсоединяем продукт к станции через Ethernet и пытаемся заменить пользователя. Пишем автотест, который откроет браузер и зайдет на страничку настроек роутера. Это хороший вариант, но у него есть куча рисков: нестабильность браузера, несовершенство средств web автоматизации – самые главные. Помните сбои IE, Firefox, Chrome? А ведь браузер будет использован для тестирования 1000 устройств, плюс этот метод еще и медленный. Тогда попробуем убрать из цепочки браузер. Пишем автотест, который сам откроет сокет и посредством POST/GET методов добьется от web интерфейса ответа. В рабочей версии программы можно оставить все версии теста, сделав их выбор настраиваемым (пункт 9).
Самый легкий для описания пункт. Здесь повествование легче выстроить из подпунктов.
Итак, что же там должно быть и чего не должно быть.
Не стоит выводить в консольное окно любую цветную информацию, она может смутить и оператора и инженера. Весь лог должен быть монохроматическим. Не стоит туда писать большими буквами PASS, FAIL, ERROR… Так как инженеры будут сами проводить анализ сбоев. В отчет о сбоях они запишут самые видимые на экране слова. Просто пишите в лог все, но оформляя это простым текстом. В предыдущем пункте (11) я указывал, что он – самый тихий. Для оператора – да. Для инженера и окошка/файла консольных логов – нет. Все шаги выполнения тестов должны быть в консольном логе. Очень помогают в таких логах ключевые слова и простые фразы, полностью идентифицирующие ошибку. Иными словами не стоит делать 2 версии ПО: дебажную и релизную. Достаточно одной – дебажной. От дополнительного вывода на экран она критично медленней работать не будет. Если вы так не сделаете, то представьте как вы будете отлаживать критическую ошибку стабильности, которая кладет узел Линии наметрво раз в 500-1000 циклов.
Обычно на Заводе вам дают некий шаблон отчета результата тестирования, который многие хардкодят в свой продукт. Это может сыграть злую шутку. Модуль (класс), который будет генерировать отчеты, лучше всего написать так, чтобы шаблон отчета он подхватывал из некоторого структурированного файла (текстовый с ключевыми словами, xml). Данный подход позволит вам генерировать отчеты любого вида. Менеджер линии или QA могут поменяться, а вместе с ним им поменяются желания на процесс и вид документов, а вы уже будете подготовлены к такому. Аналогично в случае если ваш Продукт отправляется дальше Заказчику1 и Заказчику2, у которых разные требования к шаблонам приемочной документации.
Помните при этом, что описание шаблона вам необходимо будет включить в User Manual. И создать шаблон должен уметь инженер на линии, а значит инструкцию по его изготовлению необходимо максимально упростить. Что вы выберете для максимальной простоты? Xml или текстовый файл с ключевыми словами?
А в чем проблема поменять код программы, если изменятся требования к отчету? Проблема в том, что необходимо будет полностью совершать примеку вашей программы на фабрике с полным набором документов. «Да это можно сделать за 3 дня, это не проблема». Для вас это может быть и не проблема, но что будет делать эти три дня линия?
Примечание: на стадиях 7 – 13 review кода более чем обязательно. Самые большие проблему могут скрываться в самых привычных вещах. Нестабильность сторонних библиотек и API – злейшие враги. Постарайтесь выбирать «технологии» имеющие альтернативу. Если какой-то API или метод проявляют себя «иногда плохо», то это многократно вылезет на Линии в виде сбоев. В этом случае вы должны иметь что-то еще, иначе больших изменений не избежать.
Первое, тестерам необходимо дать указания о «проверке» вашего продукта «и в хвост и в гриву». Методология черного ящика тут не подходит. Ваша задача не только покрыть требования, но и написать очень стабильную программу. Значит перед передачей на тестирование, подготовьте материал с полным описанием логики работы вашей программы. Не скрывайте ничего (вообще), более того вы можете указать слабые и сильные места кода, чтобы тестеры обратили на них внимание. Стресс тестирование обязательно! Тестирование нестандартных ситуаций обязательно (вспоминаем пример с физическим износом)! Список нестандартных ситуации составить просто, надо взять каждый логический шаг программы, который зависит от физического устройства, и просто исключить это устройство или симулировать его поломку.
Второе, тестерам необходимо будет собирать скриншоты всех экранов программы во время тестирования, включая ошибки, даже если у вас есть реализованый тестовый режим (Пункт 12 Ж). Эти скриншоты необходимо будет сопоставить с тестовым режимом, перепроверив логику UI. Они же пригодятся для документации и User Manual.
Пока тестеры занимаются делом, вам необходимо начать оформление приемочной документации. Условно ее можно разделить на 3 части: бюрократическая, скриншоты, User Manual.
Бюрократическая часть завязана на внутренние шаблоны и стандартные документы компании. Заполняйте из согласно процессу и предоставленным фабрике требованиям. Не стоит указывать в них как гибко может работать ваша программа. Описывайте все как можно суше, сократите процесс, оставив только суть работы вашего ПО. Старайтесь покрыть не более, чем необходимо для идеального стабильного случая работы вашего ПО на Линии, но не забывайте про ошибки (обработка сбоев и ошибок пользователя) и защиту от дурака.
Скриншоты тоже являются частью приемки. Они визуально подтвердят внешность программы и шаги, которые вы покроете в Бюрократической части. Скриншоты должны быть представлены все. Если на фабрике случится незнакомый экран, который приведет к простою, поломкам, большому количеству брака, травмам, то к вам будут вопросы.
Всю гибкость настроек, подробное описание шагов инсталляции, все скрытые возможности, пояснения, мысли и пожелания можете включить в третью часть – User Manual. Там необходимо описывать все. User Manual, для подобного рода ПО часто не имеет требований к шаблону и содержанию, а значит, он более чем гибок.
Таким образом, сухость в бюрократической и скриншотной частях сведет к минимуму изменения в них, которые сделать на много сложнее чем изменения в User Manual.
Как уже говорилось ранее, инженеры на фабрике могут сделать отличную от вашей тестовую станцию. Они могут объединить их в кластер и/или добавить что-то свое.
Любые сложные изменения могут потребовать изменения количества дополнительно устанавливаемых программ и пакетов.
Я рекомендую делать инсталяционный пакет в виде понятного и не сложного скрипта (batch file). С обязательным указанием в User Manual, что данный файл не является окончательным, и что пользователь может добавлять или удалять из него необходимые строки. Эта маленькая лазейка развяжет руки инженерам, а вас избавит от необходимости переделывать предоставляемый пакет и, как следствие, проводить полную приемку.
Еще более гибким подходом будет наличие нескольких скриптов, каждый из которых устанавливает только свою часть. Соответствующие шаги в User Manual должны будут начинаться с фраз: «Установите, если необходимо, такой-то компонент, используя такой-то batch файл». В этом случае любые изменения в конечную инсталяцию будут вноситься путем добавлением компоненты, полностью исключая изменения вашего пакета. То есть за основу будут взяты ваши инструкции, но с Заводскими изменениями. Последние будут проведены по своей внутренней документации, которая никаким образом не будет касаться вас.
Пример. Установка требует: ваше ПО, библиотеки MS Visual C++, DHCP server, wget client.
Вариант А – негибкий. У вас инсталяционный exe файл. Если Завод решить поменять DHCP server на свой, то вам необходимо заного проводить приемку. Это отнимет несколько дней бюрократии.
Вариант Б – гибкий. Вы создали batch файл, который последовательно устанавливает все пакеты. Вы так же указали в User Manual, что данный файл можно варьировать. Вас могут попросить переделать файл, заменив или исключив пакеты в нем, так как инженер не будет знать как работать с batch файлами. Это не страшно, но менять могут просить каждый день пока не отладят. На итоговое изменение Завод сам составит весь пакет необходимых документов.
Вариант В – почти идеальный. У вас не только есть главный скрипт исталяции, но и куча второстепенных, которые ставят по одному пакету. В User Manual все шаги исталяции описаны как опциональные (за исключением необходимых: ваше ПО, библиотеки MS Visual C++), а «главный скрипт» указан лишь как пример. Этот вариант даст еще большую свободу, так как исключить или добавить шаг будет уже под силу любому инженеру. Минус этого варианта – большое количество инсталяционных шагов в User Manual.
На этом этапе вы уже отгрузите стабильную версию вашей программы инженерам на фабрике. Но приемка еще не будет проведена. Инженеры на Линии будут тестировать ваш софт в режиме реальной работы. Обязательно попросите засечь время тестирования Продукта (для 1 шт, 5 шт, 10 шт, 100шт). Чем больший охват временной статистики у вас будет на руках тем лучше. Эту статистику вы должны будете свести к метрике «бутылочного горлышка» и отправить своему менеджменту до приемки (см шаг 18)! Это важно!
Если у вас есть шанс посетить фабрику, то самое время это сделать. Визит на Линию сильно отрезвляет и выводит вас за рамки лаборатории.
Помните, что на Линии вы не авторизованы делать что-либо и давать советы. Все, что от вас требуется – внимательно наблюдать. Даже если кто-то делает что-то не так, молчите, пока вас не спросят. Любое ваше замечание не имеет полномочий там, а если оно еще приведет к нежелательным последствиям, то вы сами виноваты.
Только на митингах высказывайте свои идеи и замечания.
Любые изменения, которые вам необходимо будет сделать, сначала делаете у себя на рабочем PC, а потом передаете их инженеру.
Если вы все же остались в родных стенах, то приготовьтесь к быстрым «фиксам» и изменениям. Тут гибкий дизайн и хорошая структура программы сыграют вам на руку. Попросят изменить отчет? У вас есть шаблоны. Попросят добавить проверку дополнительного ID? У вас уже все учтено в дизайне и в UI есть место. Попросят ускорить часть программы? Попробуйте поиграться с параметрами, которые уже вынесены в отдельный файл, даже перестраиваться не придется. Захотят изменить количество и порядок тестов? И это тоже уже сделано.
Постарайтесь не сильно бодаться с инженерами на Линии из-за их изменений. Они работают с тем, что есть, и с тем, что было заложено на стадии требований (шаги 6-7). Они не смогут срочно что-то купить или поменять. Просто постарайтесь учесть все и вашем ПО. Сложно? Да не просто, но если вы реализовали дополнительные обходные пути (пример с USB и Serial), то волноваться вам, по большому счету, не о чем.
Если все же проблема с нововведениями возникла, то попробуйте ее решить или обойти в рамках имеющего оборудования. На этапе инженерного внедрения вы уже не сможете сказать «купите то и то», они уже все купили.
Формально там уже все внедрено. На этом этапе подбиваются и подписываются приемочные документы.
На этом шаге ваша подпись имеет значение. Она кладет на ваши плечи груз ответственности. Помните, что на линии десятки, а то и сотни людей будут работать с тем, что вы им дали. Качество выходного Продукта и его частей теперь зависит от вашего ПО. Ваша репутация теперь на виду.
То о чем забывают даже на Заводе это то, что Линия в самом начале не работает на полную мощность. С течением времени и новыми заказами на продукт Линия будет то ускоряться, то замедляться.
Временная статистика шага 14, поможет вам оценить пропускную способность вашего узла. Это очень важный параметр. Узел не должен отставать от остальной линии. Если сборщики собирают 1000 Продуктов за смену, то и ваш узел должен успевать тестировать 1000. Сделайте расчет «бутылочного горлышка». Это простая математическая аппроксимация количества тестируемых устройств на единицу времени. На самом деле, инженеры на Линии делают такие расчеты всегда, именно поэтому они объединяют тестовые станции в кластеры. Их опыт, однако, отличен от вашего, и они могут «рассчитать» идеальный случай, поэтому необходимо продублировать их работу, сделав так, как это понимаете вы.
В случае возникновения «горлышка» на любом узле Линии, она будет остановлена, пока «не возобновится баланс сил». Если линию не останавливать, то может возникнуть перепроизводство (кто за него заплатит?), загромождение складов и временных хранилищ на Линии (может вылиться в противоречие с пожарной безопасностью), путаница (нельзя сказать части работникам Линии, чтобы они остановились, а другой части, чтобы ускорились, отдать обратный приказ будет на много сложнее).
Как правило, «горлышко» — проблема Линии, но если к вам будут вопросы, то в запасе у вас уже есть отправленный отчет менеджменту с данной статистикой. В этом случае любые вопросы «сменят тон» и станут всего одним: «Вы можете что-нибудь сделать?». Ответ, скорее всего, будет скрываться в параметрах, которые вы заблаговременно вынесли в отдельный файл.
На Линии так же могут возникать и сторонние проблемы, которые вообще никто не предусмотрел. Обычно их решают оперативно. Но ряд из них может иметь накопительный характер. Чтобы избежать «критической массы» на вашем узле попросите внести в процесс шаг, который будет требовать от инженера раз в день/неделю отправлять вам весь набор логов с линии – это ваши отчеты и «инженерный лог» шага 12 Е. Анализ этих данных позволит вам быстро выявить проблемы, пропущенные на всех стадиях тестирования и внедрения.
Автор: aewoo
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/analiz-i-proektirovanie-sistem/214722
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/316332/?utm_source=habrahabr&utm_medium=rss&utm_campaign=sandbox
Нажмите здесь для печати.