Особливості побудови тестів і розробки ПЗ, що використовується в тестуванні продукту на складальних лініях

Завдання: Компанія (далі-Компанія) розробляє і випускає певний продукт (далі-Продукт). Необхідно створити програмне забезпечення для перевірки Продукту на складальної лінії (далі Лінія) деякої сторонньої або належить компанії фабриці (далі-Завод).

: розробник тестового для перевірки Продукту, або менеджер цих розробників, або взагалі менеджер або інженер, або тестер широкого профілю… в загальному особа, відповідальна за перевірку роботи Продукту на виході. У вас є певний досвід лабораторного тестування, але немає накопиченого досвіду роботи з фабрикою.

Мета: Грамотно згладити помилки розробки тестового для фабрики, що допускаються в процесі життєвого циклу Продукту.

Примітка: під Продуктом розуміється деякий пристрій або його частина, що володіє внутрішньою логікою, SW / FW / Функціонал якого потрібно перевірити. Приклад: стільниковий телефон, контролер, програмовані пристрої, материнська плата.

У даній замітці я поділюся своїм досвідом, накопиченим за останні 4 роки. Сподіваюся, він дозволить вам заощадити зайві людино-години і нерви, підвищивши при цьому якість продукту, що випускається.
Замітка орієнтована на досвідченого розробника, тестера, технічного керівника і менеджера. Однак, якщо вам не вистачає досвіду, але у вас є час, прочитайте, так як чужі помилки можуть бути цінним джерелом знань.
Інформація представлена у вигляді великого «чеклиста» з дій, які необхідно зробити, з поясненнями та прикладами. Любителям аргументувати, починаючи з «а у нас не так», повторю, я ділюся своїм досвідом, який допоміг мені і роботодавцю не вдарити в бруд обличчям.


1. Наявність інтерфейсу для тестування на стадії дизайну продукту

Якщо ви її застали стадію дизайну Продукту і маєте голос, донесіть до менеджменту, що наявність будь-якого тестового інтерфейсу, доступного на момент складання Продукту, може сильно полегшити життя на фабриці. Вам негайно послідує заперечення, що на будь платі є тестові точки і контактні роз'єми деяких портів. Питання, які ви повинні будете задати: «А чи будуть вони доступні коли Продукт буде в зборі? Як здійснювати такі перевірки, коли не буде дірочки, в яку можна вставити шнур?»
Ці прості питання і відповіді на них визначать майбутнє вашого перевіряючого. Економія на тестовому інтерфейсі, може вилитися в пляшкове горлечко при тестуванні на Лінії (про це нижче), простий якої може коштувати більше, ніж зайвий порт на платі.


2. Наявність інтерфейсу для тестування на стадії розробки заліза

Нехай інтерфейс є в дизайні. Зверніться до розробників заліза і ПО Продукту і з'ясуйте, чи не суперечить правилам, нормам та стандартам безпеки даний інтерфейс. Наприклад, сама наявність тестового USB порту може позбавити Продукт сертифікації. Read / Write доступ через Серійний порт може зробити теж саме (навіть якщо від порту на платі лише ряд контактів).
Думки про те, що порти не приберуть, і ви через них будете посилати тестові команди, викликати деякі API, можуть бути дуже небезпечні. Спілкування з портом в кінцевій версії Продуктового може бути просто заблоковано. В ідеальному випадку, він може бути відкритий лише на вивід інформації. Прохання не плутати це з read. Read має доступ до конкретної інформації. Не завадить і пильність при переході з однієї версії заліза на іншу (P0 --> P1 --> ...), чарівний порт може так само чарівно зникнути. Менеджмент HW команди і їх рішення не постійні.


3. Верстат для тестування 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), B(1, 2, 3), С(1, 2, 3). Лінія запускається і пристрій, що має бути на А(1), спілкується з(1). Якщо ви думаєте, що вина на таку настройку ляже на інженера, то врахуйте, що він має право змінювати вимоги до тестової машині і змінювати її, і свою помилку він може списати на таку зміну. Наприклад, три складальні Лінії (N машин на кожну) не можуть ділити RF діапазон, так як він зайнятий іншим обладнанням, і налаштування кожної машини на свій RF канал може бути просто неможлива.
Пам'ятайте, що вузли і агрегати машини, використовуваної на Лінії, повинні відтестувати не 1 пристрій, а тисячі. Не переносьте свій лабораторний досвід на Завод. Розробіть методику тестування заново.
Приклад. Продукт той же, що і раніше. Ставлять завдання перевірити вихідний рівень сигналу (потужність). Кроки: беремо пристрій, під'єднуємо тестову антену, вимірюємо вихідну потужність, від'єднуємо тестову антену, під'єднуємо заводську, відправляємо пристрій далі. Механічний знос тут може бути критичним. Тестова антена повинна витримати тисячі приєднань без втрати якості передачі сигналу (інакше багато пристроїв підуть в шлюб). Роз'єм на Продукті теж повинен витримати кілька підключень і залишити запас на майбутнє. Для багатьох відкриття, що антенні роз'єми на улюблених нами ноутбуках і стільникових телефони призначені всього на 10 циклів приєднання/від'єднання антени. Скільки їх у нас? На розглядаємо тесті 2. Сам пристрій може потрапити на тест 3 рази (6), а потім ще пройти кілька циклів перезбирання (вже 12). 12 більше 10, значить ризик забракувати пристрій на лінії своїми тестами – великий. Значить необхідно розмовляти з HWщиками, шукати альтернативу, або робити тест лабораторним. І якщо «затырканных» пристроїв всього 2%, це дуже багато (2000 з 100 000).
Нехай тест все ж включили в виробничий цикл. Яке обладнання буде виробляти вимір? Навіть якщо «контора платить», не варто створювати боїнг. Не переносьте свій лабораторний досвід на Завод. Краще всього зупинитися на обладнанні, яке буде вимагати найменше підтримки і може бути відкалібровано на місці без відправки в сервісний центр. Ще краще, якщо у вас у запасі завжди буде альтернатива.


4. Поділ лабораторних тестів і виробничих

В попередньому пункті, у вас накопичиться деяка база тестів, застосовна до перевірки HW. Там же розпочнеться їх поділ на лабораторні і виробничі.
Хай нас вже є певний робочий і не сильно сирої Продуктовий софт. Тоді настав час вести діалог про перевірку, готового пристрою. Тактика точно така ж, але тепер опитуємо розробників продуктового ЗА і Менеджерів Продукту. Питання: «Що і як ви хочете тестувати на фабриці? Чому? Чому саме так? Що ви використовували раніше для подібних продуктів? Є вимоги на перевірку готового пристрою?».
Як правило, ви – не першопроходець. До вас була купа людей, які займалися схожих справах, після них залишиться частина toolов, документації до них і вимоги. Вивчіть все, зіставте з відповідями розробників і менеджерів, виділіть ризики, і складіть план дій.
Переглянувши все, великою помилкою буде сказати самому собі: «Це все застаріло! Дизайн кривий! Код написаний криво! Я все зроблю з нуля сам!». Пам'ятайте, що ця стара «фігня з кривим дизайном і кодом» оттестировала на фабриці та/або в лабораторії купу всього ще до вас. Значить, вона (фігня) зі своїм завданням впоралася, а ви поки немає.
Вивчивши всю документацію і покопавшись в коді попередників, складіть список одержані тестів. Постарайтеся оформити його як технічні вимоги до майбутнього тестового ЗА, приблизно так само, як це робили HW розробники для своєї машини. Справа в тому, що стандартна документація всередині компанії дуже схожа. Вам все одно доведеться все описувати для фабрики, а так у вас вже буде готовий чернетка, який можна надати на першу вимогу.
Отриманий список обговоріть з колегами всередині команди. Це може бути офіційне Review або проста бесіда. Цікавтеся, як би вони зробили той чи інший тест. Фіксуйте будь-які навіть абсурдні аргументи. В результаті ви самі для себе отримаєте дорожню карту майже на кожен тест. Природно їх кількість може збільшиться або зменшиться.
Кінцевий чернетка розбийте на лабораторну частину і виробничу частину. Якщо у вас є команда, то дане розбиття необхідно пустити знову на review.


5. Лабораторні тести та автоматизація

Перед тестерами все частіше ставлять завдання автоматизації тестів. У списку вакансій «ручне тестування» оцінюється нижче «вміння автоматизувати».
Пам'ятайте одну просту річ: «Автоматичний тест покриває тільки той алгоритм, який в нього закладено. Він ніколи не може перевірити крок вліво чи вправо від алгоритму. Він ніколи не знайде допоміжну проблему. 100 ручних тестів можуть знайти 200 проблем. 1000 автотестів можуть бути написані так, що свідомо завжди будуть PASS».
Золота середина – наявність тестів двох видів в межах кожної фази тестування.
Не дивлячись на сказане вище, лабораторні перевірки, найкраще автоматизувати. Звичайні рутинні тестові прогони основних гілок Продуктового SW (feature test, sanity) все одно будуть виконуватися кимось із команди, ось там і повинна бути «золота середина». Лабораторія може і повинна перевіряти тільки найскладніші і критичні для Продукту і сертифікування тести.
Якщо вам необхідно продовжувати лабораторне тестування і готувати тести на Лінії, то лабораторія – прекрасне місце, щоб відкатати методики роботи з тестовими інтерфейсами і методами автоматизації, які ви плануєте використовувати на фабриці. Критерій «хорошого» методу – його стабільність (100 000 пристроїв повинні пройти тест). А як же швидкість виконання тестування? Швидкість – приємний бонус, якого може не бути. Згадайте тепер кривий дизайн потворного коду з минулого пункту. Ось він стабільний. Можливо його потворність є наслідок його стабільності?


6. Виробничі тести і фабрика

Головні інженери, процессники (класичний QA) і безпечники проектують лінію і складають документацію. У ній описані кроки виробництва на лінії. Одним або кількома кроками буде використання (тестової станції, або тестової лінії). Додати або видалити крок цього процесу, коли він запущений, украй складно, практично неможливо.
Більшість Ліній – це конвеєри типу лінія або змійка.
Приклад. Уявіть конвеєр – змійку, який займає виробниче приміщення повністю (100 осіб, 3 зміни). Там є тільки місце для евакуації, роботи працівників і транспортні лінії (підвіз комплектуючих). Вставити в даний конвеєр якийсь вузол просто неможливо. Він чи не увійде (фізично немає місця) або не пройде перевірку безпеки (пожежні вимоги тощо). Якщо ж вузол вставити необхідно, то конвеєр повністю буде зупинений і, швидше за все, розібраний. Далі буде складена нова документація, збірка та настройка буде здійснена заново, приймання та налагодження теж займе деякий час, а 300 робітників будуть отримувати зп так само як і отримували.
«Он там у кутку є місце, давайте поставимо туди!». Таке навіть говорити не можна. Неможливо знімати з змійки продукт, тягнути його в кут а потім повертати на місце в змійку. Виникне плутанина і хаос.
На цьому кроці від вас можуть попросити опис робочої станції оператора, що використовує ваше. Природно, це буде PC і набір необхідних тестових інструментів і вузлів. Barcode reader – це тестовий інструмент, Ethernet шнур – теж, USB шнур – теж і тд. Поставтеся серйозно і опишіть всі до гвинтика, документацію в процесі розробки тестового можна буде правити, чим більше ви вкажете на початку, тим менше вам доведеться додавати потім.
Так само вас запитають, як приблизно буде працювати станція, і що необхідно робити оператору. І, природно, попросять список вимог до вашому. Згадуємо, що ви вже підготували чернетка в кроці 4. Він буде перенесений на стандартні шаблони документації, підданий review та повернуто на доопрацювання як список вимог до тестового ЗА, але вже від імені фабрики. Тобто ваш чернетка повернуть вам же як затверджений набір вимог і план. Тому важливо виключити з нього все «погане» на кроки 1-4.
Всі ці дії будуть спрямовані на те, щоб зрозуміти скільки під ваш крок на Заводі відчинити місця.Не думайте, що там буде 1 оператор на 1 тестову станцію. Або що вони поставлять те залізо, що ви дали в списку. Все буде складніше.
Головні інженери будуть працювати з тим, що є, і з тим, що їм дадуть. Швидше за все ваш тестовий модуль буде розібраний на частини і зібраний певний кластер або гібрид з N станцій, робота якого не буде суперечити вказаним вами опису та вимогам.

Найголовніше, про те, що вийде в кінці навряд чи вам скажуть. Так як самі на початку не будуть цього знати, а потім просто «забудуть» надіслати кінцеве або хоча б чорнове опис того, що вийшло.
Майте це на увазі, читаючи подальші мої рекомендації.
Після того як ваше тестове ПО буде готове, воно має пройти стадії приймання, інженерного впровадження і впровадження на лінію.
Внесення будь-якої зміни або просто випуск нової версії буде схильний до тим же самим стадій прийняття та впровадження. Навіть якщо це всього лише один printf в коді.


7. Дизайн тестового

Дизайн – ваше все. Логічна схема структури вашої програми повинна бути максимально гнучкою. Кожен з її вузлів повинен бути налаштованим, стабільним і самостійним. Тут як ніяк доречно review, мозкові штурми і тп.
Хороший дизайн (включаючи UI) врятує вам життя і буде головним чинником економії людино-годин в майбутньому.
Структуру напевно будь-якого тестового можна представити у вигляді наступних пунктів:

  • Настройка при запуску
  • Доступ користувача
  • Зчитування показань з досліджуваного продукту.
  • Тестування Продукту
  • Висновок результатів
Всі ці пункти будуть розглянуті далі.
Здавалося б, все просто. Тести визначено, вимоги представлені, сідай і пиши. На перший погляд навіть можна обійтися скриптом рядків 500, а то і менше, ось тут вже навіть є майже готовий open source tool… Не поспішайте так думати.
Завод і Компанія можуть мати цілком конкретні обмеження на використання сторонніх готових додатків. Наприклад, для Web автоматизації ви можете використовувати бібліотеки Python і Selenium, так як це відноситься до Programming Language, але не зможете використовувати Python і Curl, так як останній є готовою сторонньою програмою, яка не пройшла приймання всередині Компанії. Ви, звичайно, можете провести приймання Curl самі, але це займе час і ресурси, а кінцевий результат буде невідомий (можуть відхилити). Ви можете звичайно засунути Curl-код в вашому і зробити вигляд, що так воно і треба. Але не варто недооцінювати колег «по цеху».
Згадуємо знову потворний не красиво написаний інструмент попередніх проектів. Може бути він такий від того, що використовував тільки те, що пройшло приймання всередині Компанії?
Навіть якщо в Компанії схожих правил немає, то на Заводі вони будуть. Дізнайтеся про них заздалегідь.


8. Доступ користувача

Користуватися вашим продуктом будуть навчені оператори. Не навчені ним користуватися не повинні. Подумайте над способом авторизації оператора, який заступив на зміну.
найпростіша – вважати пропуск (badge) співробітника. Однак, доступу в мережу на перевірку пропуску співробітника у тестовій станції може не бути, тому що авторизація повинна бути зроблена (ще й) локально.
Так само повинен бути легкий спосіб у привілейованих осіб заносити і видаляти ID операторів з локального реєстру користувачів. Оператори – люди, вони можуть змінювати місце роботи, або хворіти.
Так само повинен бути легкий спосіб заносити і видаляти ID привілейованих осіб з локального реєстру. Ці особи – теж люди, а конвеєр не може стояти.
Редагування списку осіб не повинна бути складною процедурою типу «встановіть SQLite, складіть запит...», це повинен вміти робити людина з кваліфікацією набагато нижче, ніж у вас. Більш того, це має бути легкою процедурою.
Простий текстовий файл із списком користувачів може бути виходом, але таку простоту можуть навчитися правити і не авторизовані оператори теж.
Як бути, вирішувати вам.


9. Настройка при запуску

Ваша програма повинна бути максимально гнучкою.
Я настійно рекомендую винести назовні всі константи і параметри. Нестандартно, так? Зберіть їх в окремому текстовому файлі і використовуйте їх в якості налаштувань вашої програми при запуску. Вони всі повинні бути зрозумілим і читаються. Інструкції (а вам доведеться писати 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 сервера, який може бути встановлений на Лінії, і замість нього може бути іншою. Але крах всіх трьох варіантів, малоймовірний.
Іншими словами, більше гнучкості – менше проблем.


10. Зчитування показань з тестованого продукту

З тестованого продукту завжди зчитуються якісь ID, які потім використовуються як докази та документального підтвердження у звітах, що пристрій пройшов тест.
Ряд цих параметрів має зчитується завжди в строгій послідовності. Нестрога послідовність викличе плутанину серед операторів.
Припустимо на пристрої 6 штрих кодів. Вас просять вважати, перевірити і використовувати тільки 3 з них. Попрацюйте над дизайном коду і UI так, щоб внесення додаткових перевірок штрих кодів не сильно змінило зовнішність програми та її код.
Можете зробити поля у UI для всіх IDшек (штрих кодів) відразу з занесенням додаткових налаштувань в текстовий файл, щоб вмикати або вимикати відповідний UI елемент при необхідності. Але пам'ятайте, що сильне зміна UI вимагає більшого часу для перенавчання операторів. Це може бути зустрінута в багнети на Заводі. Процеси навчання і звикання для операторів – стрес. Вони (на відміну від вас) будуть стояти по 8 годин на день у тестовій станції, і зайвий головний біль їм ні до чого.


11. Тестування Продукту

Ця частина вашого ЩОДО повинна бути для оператора самої невидимою, і чим менше додаткових кроків у неї буде, тим краще.
Це самий креативний для розробки крок. Дуже рідко коли можна придумати сценарій без додаткових ручних маніпуляцій, особливо коли у вас відсутній тестовий інтерфейс (згадуйте пункти 1 і 2).
Розберемо кілька прикладів і побачимо, чого варто боятися, а чого немає.
Приклад 1 (Чого варто боятися). Ви просите оператора на початку тестування вставити USB, а в середині тестування витягнути USB, реалізовано у вигляді діалогового вікна.Небезпечні моменти:
А). Фізичний знос — USB кабель може рано чи пізно фізично зламатися або зноситися. Ваша програма передбачає таке?
Б). Нестабільні драйвера пристроїв за замовчуванням — Ви використовуєте PC в збірці яких (HW або SW) прихована нестабільність роботи з вашим USB драйвером. Це може призвести до відмови USB hub на материнській платі РС або подвиванию драйвера. Чи пам'ятаєте ви, як часто в процесі розробки у вас неправильно визначався Продукт за USB? Чи були у вас випадки на вашому PC виходу з ладу USB портів або touchpad (він теж часто висить на USB hub), що допомагала тільки перезавантаження? Ваша програма передбачає таке (особливо якщо Завод буде використовувати ті ж станції, що і ваш робочий PC)?
). Несумісність стандартів — Ви писали код для підтримки тільки USB 2.0, а на PC з USB 3.0 у вас проблеми зі стабільністю. Ви вносите у вимоги (крок 6) використання PC лише з USB 2.0. Наївно вважати, що його виконають в точності при повсюдному впровадженні USB 3.0. Завод буде використовувати те, що є, щоб заощадити. Ви можете зробити деякий обхідний шлях, порадивши їм відключити 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).


12. Висновок результатів, UI і візуалізація проміжної інформації

найлегший для опису пункт. Тут розповідь легше вибудувати з підпунктів.

  • А). Кожен елемент UI повинен мати великий шрифт. Оператор може перебувати від екрану мінімум в 1 метрі. Він повинен безпомилково бачити на екрані все, що йому належить. Ще з ще більшої відстані повинен бачити це навчальний або перевіряючий інженер, який знаходиться за спиною оператора. Всі вони люди і можуть мати проблему із зором.

  • Б). Колірна гамма UI повинна мати інтуїтивно зрозумілий сильно обмежений набір кольорів. Не допускайте наявність всієї палітри кольорів на одному з елементів (наприклад, кнопки), так як оператори можуть мати проблеми з цветовосприятием, а таким людям легше запам'ятати різні відтінки в деякій області ніж всю палітру.

  • В). Текст діалогів і результатів на екрані, включаючи повідомлення про помилки, повинен бути гранично стислий і простий. Його повинен зрозуміти навіть дитина. Не завжди від відображуваного тексту потрібно граматична правильність. Оператори можуть не володіти усіма шедеврами мови, на якому буде спілкуватися ваше тестове ПО. Часто вони можуть взагалі не володіти мовою вашої програми.

  • Г). Кількість кнопок у UI повинно бути зведено до мінімуму. Оператор не повинен мати вибору того, що йому натискати в даний момент. Ви повинні звести до мінімуму варіант людської помилки. В ідеалі у вас повинна бути одна кнопка «Зробити Добре».

  • Д). Доступ до полів і кнопок повинен бути чітким і послідовним. Як тільки одне поле заповнене, тільки тоді відкривається для редагування друге поле. Як тільки оператор перейшов на друге поле, перше поле стає недоступним для редагування. Початок тестування доступно тільки після заповнення всіх полів. Як тільки почалися тести, всі поля блокуються для редагування. Скасувати виконання тестів можна тільки після їх початку. Далі, я думаю, ви зрозуміли.

  • Е). Оператор повинен бачити мінімум інформації, а ось інженер повинен бачити її як можна більше. І все це необхідно робити в одне і теж час, і без додаткового кроку типу перевірки баджика. Це пов'язано з тим, що оператор, проводячи тестування, відсіває шлюб, грунтуючись на результатах вашої програми. А інженер стежить, щоб кількість браку на сайті мінімально (адекватно) і Лінія працювала стабільно. Якщо на вашому сайті відбувається щось підозріле, то будете впевнені, що вам зателефонують протягом 24 годин. А тепер уявіть цей дзвінок. Ви задаєте питання: «Що сталося?». Якою ви хочете отримати відповідь? Лінію зупинити не можуть, іноді навіть станцію перезавантажити не можуть, не можуть нічого додаткового запустити щоб «зібрати лог», так як це суперечить вимогам Заводу. Висновок: лог повинен збиратися відразу. Можна сипати його відразу в файл. Однак, запис у файл може проводитися жорстким диском тільки після наповнення буфера запису, що може призвести до того вже трапилася помилка, а у файлі її ще немає. Значить треба писати не тільки файл, але і на екран. За UI може ховатися консольне вікно з повним логом (і маленьким шрифтом), навіть самий недогадливый оператор зрозуміє, що це чорне з великою кількістю букв не для нього. Можна виводити цей тип логів на станцію інженера, але чи інший мережевий доступ може бути не завжди.

    Отже, що ж там має бути і чого не повинно бути.

    Не варто виводити в консольне вікно будь-яку кольорову інформацію, вона може збентежити і оператора та інженера. Весь лог повинен бути монохроматичним. Не варто туди писати великими літерами PASS, FAIL, ERROR… Так як інженери будуть самі проводити аналіз збоїв. У звіт про збої вони запишуть найбільш видимі на екрані слова. Просто пишіть в лог всі, але оформляючи це простим текстом. У попередньому пункті (11) я вказував, що він – самий тихий. Для оператора – так. Для інженера і віконця/файлу консольних балок – ні. Всі кроки виконання тестів повинні бути в консольному балці. Дуже допомагають в таких логах ключові слова і прості фрази, повністю ідентифікують помилку. Іншими словами не варто робити 2 версії: дебажную і релізну. Досить однієї – дебажной. Від додаткового виводу на екран вона критично повільніше працювати не буде. Якщо ви так не зробите, то уявіть як ви будете налагоджувати критичну помилку стабільності, яка кладе вузол Лінії наметрво раз в 500-1000 циклів.

  • Ж). UI є один трюк, який може врятувати вам купу часу, і який ніхто не далет, це тестовий режим для вашої програми. У цьому тестовому режимі відсутня досліджуваний Продукт, але програма буде працювати так, як ніби він є, тільки на багато швидше. Цей режим необхідний як повітря, він дозволить вам налагодити програму, UI і зняти всі screenshotы з усіх екранів і всіх видів помилок. Ці картинки будуть потрібні для приймальної документації і User Manual. Якщо ви тестуєте ядерний реактор, зняти скріншот з помилки «Реактор розплавився» без тестового режиму буде проблематично.

  • З). Не забувайте про автостарт. Коли всі поля заповнені, можна заощадити час автоматично запустивши тести, не чекаючи натискання кнопки Старт оператором.

13. Висновок результатів, тестові звіти, логи

Зазвичай на Заводі вам дають якийсь шаблон звіту результату тестування, який багато хардкодят в свій продукт. Це може зіграти злий жарт. Модуль (клас), який буде генерувати звіти, краще написати так, щоб шаблон звіту він підхоплював з певного структурованого файлу (текстовий за ключовими словами, xml). Даний підхід дозволить вам генерувати звіти будь-якого виду. Менеджер лінії або QA можуть змінитися, а разом з ним ним поміняються бажання на процес і вид документів, а ви вже будете підготовлені до такого. Аналогічно у випадку якщо ваш Продукт вирушає далі Заказчику1 і Заказчику2, у яких різні вимоги до шаблонів приймальної документації.
Пам'ятайте при цьому, що опис шаблону вам необхідно буде включити в User Manual. І створити шаблон повинен вміти інженер на лінії, а значить інструкцію з його виготовлення необхідно максимально спростити. Що ви виберете для максимальної простоти? Xml або текстовий файл з ключовими словами?
А в чому проблема поміняти код програми, якщо зміняться вимоги до звіту? Проблема в тому, що необхідно буде повністю здійснювати примеку вашої програми на фабриці з повним набором документів. «Так це можна зробити за 3 дня, це не проблема». Для вас це може бути і не проблема, але що буде робити ці три дні лінія?
Примітка: на стадіях 7 – 13 review коду більше ніж обов'язково. Найбільші проблему можуть ховатися в самих звичних речах. Нестабільність сторонніх бібліотек API – найлютіші вороги. Постарайтеся вибирати «технології» мають альтернативу. Якщо якийсь API або метод проявляють себе «іноді погано», то це багаторазово вилізе на Лінії у вигляді збоїв. У цьому випадку ви повинні мати щось ще, інакше великих змін не уникнути.


14. Стадія тестування, підготовка документів до приймання

Перше, тестерам необхідно дати вказівки про «перевірку» вашого продукту «і в хвіст і в гриву». Методологія чорного ящика тут не підходить. Ваше завдання не тільки покрити вимоги, але і написати дуже стабільну програму. Значить перед передачею на тестування, підготуйте матеріал з повним описом логіки роботи вашої програми. Не приховуйте нічого (взагалі), більш того ви можете вказати слабкі та сильні місця коду, щоб тестери звернули на них увагу. Стрес тестування обов'язково! Тестування нестандартних ситуацій обов'язково (згадуємо приклад з фізичним зносом)! Список нестандартних ситуації просто скласти, треба взяти кожен логічний крок програми, який залежить від фізичного пристрою, і просто виключити це пристрій або симулювати його поломку.
Друге, тестерам необхідно буде збирати скріншоти всіх екранів програми під час тестування, включаючи помилки, навіть якщо у вас є реалізованої тестовий режим (Пункт 12 Ж). Ці скріншоти необхідно буде зіставити з тестовим режимом, перевіривши логіку UI. Вони ж стануть в нагоді для документації і User Manual.
Поки тестери займаються справою, вам необхідно почати оформлення приймальної документації. Умовно її можна розділити на 3 частини: бюрократична, скріншоти, User Manual.
Бюрократична частина зав'язана на внутрішні шаблони і стандартні документи компанії. Заповнюйте згідно з процесу і наданими фабриці вимогам. Не варто вказувати в них як гнучко може працювати ваша програма. Описуйте все якомога сухіше, скоротіть процес, залишивши тільки суть роботи вашого. Намагайтеся покрити не більше, ніж необхідно для ідеального випадку стабільного роботи вашого на Лінії, але не забувайте про помилки (обробка збоїв і помилок користувача) і захист від дурня.
Скріншоти теж є частиною приймання. Вони візуально підтвердять зовнішність програми і кроки, які ви покриєте в Бюрократичній частини. Скріншоти повинні бути представлені всі. Якщо на фабриці трапиться незнайомий екран, який призведе до простою, поломок, великій кількості шлюбу, травм, то до вас будуть питання.
Всю гнучкість налаштувань, докладний опис кроків інсталяції, всі приховані можливості, пояснення, думки та побажання можете включити в третю частину – User Manual. Там необхідно описувати всі. User Manual, для подібного роду часто не має вимог до шаблону і змістом, а значить, він більш ніж гнучкий.
Таким чином, сухість у бюрократичній та скриншотной частинах зведе до мінімуму зміни в них, які зробити на багато складніше ніж зміни в User Manual.


15. Інсталяційний пакет

Як вже говорилося раніше, інженери на фабриці можуть зробити відмінну від вашої тестову станцію. Вони можуть об'єднати їх в кластер і/або додати щось своє.
Будь-які складні зміни можуть зажадати зміни кількості додатково встановлених програм і пакетів.
Я рекомендую робити інсталяційний пакет у вигляді зрозумілого і не складного скрипта (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.


16. Інженерне впровадження вашого тестового на Лінію

На цьому етапі ви вже передавання стабільну версію вашої програми інженерам на фабриці. Але приймання ще не буде проведена. Інженери на Лінії будуть тестувати ваш софт в режимі реальної роботи. Обов'язково попросіть засікти час тестування Продукту (для 1 шт, 5 шт, 10 шт, 100шт). Чим більший охоплення тимчасової статистики у вас буде на руках тим краще. Цю статистику ви повинні будете звести до метриці «пляшкового горлечка» і відправити своєму менеджменту до приймання (см крок 18)! Це важливо!
Якщо у вас є шанс відвідати фабрику, то саме час це зробити. Візит на Лінію сильно протвережує і виводить вас за межі лабораторії.
Пам'ятайте, що на Лінії ви не авторизовані робити що-небудь і давати поради. Все, що від вас вимагається – уважно спостерігати. Навіть якщо хтось робить щось не так, мовчіть, поки вас не запитають. Будь-яке ваше зауваження не має повноважень там, а якщо воно ще приведе до небажаних наслідків, то ви самі винні.
Тільки на мітингах висловлюйте свої ідеї та зауваження.
Будь-які зміни, які вам необхідно буде зробити, спочатку робите у себе на робочому PC, а потім передавати їх інженеру.
Якщо ви все ж таки залишилися в рідних стінах, то приготуйтеся до швидких «фиксам» і змін. Тут гнучкий дизайн і хороша структура програми зіграють вам на руку. Попросять змінити звіт? У вас є шаблони. Попросять додати перевірку додаткового ID? У вас вже все враховано в дизайні і в UI є місце. Попросять прискорити частина програми? Спробуйте погратися з параметрами, які вже винесені в окремий файл, навіть перебудовуватися не доведеться. Захочуть змінити кількість і порядок тестів? І це теж вже зроблено.
Постарайтеся не сильно битися з інженерами на Лінії з-за їх змін. Вони працюють з тим, що є, і з тим, що було закладено на стадії вимог (кроки 6-7). Вони не зможуть терміново щось купити чи поміняти. Просто постарайтеся врахувати всі і ПО вашому. Складно? Та не просто, але якщо ви реалізували додаткові обхідні шляхи (приклад з USB і Serial), то хвилюватися вам, за великим рахунком, не про що.
Якщо все ж проблема з нововведеннями виникла, то спробуйте її вирішити або обійти в рамках має обладнання. На етапі впровадження інженерного ви вже не зможете сказати «купуйте те і те», вони вже все купили.


17. Впровадження тестового на лінію

Формально там вже все запроваджено. На цьому етапі підбиваються і підписуються приймальні документи.
На цьому кроці ваша підпис має значення. Вона кладе на ваші плечі тягар відповідальності. Пам'ятайте, що на лінії десятки, а то і сотні людей будуть працювати з тим, що ви їм дали. Якість вихідного Продукту та його частин залежить від вашого. Ваша репутація тепер на увазі.


18. Пляшкове горлечко і сторонні проблеми

То про що забувають навіть на Заводі це те, що Лінія на самому початку не працює на повну потужність. З плином часу і новими замовленнями на продукт Лінія буде прискорюватися, то сповільнюватися.
Тимчасова статистика кроку 14, допоможе вам оцінити пропускну здатність вашого сайту. Це дуже важливий параметр. Вузол не повинен відставати від іншої лінії. Якщо збирачі збирають 1000 Продуктів за зміну, то і ваш сайт повинен встигати тестувати 1000. Зробіть розрахунок «пляшкового горлечка». Це проста математична апроксимація кількості протестованих пристроїв на одиницю часу. Насправді, інженери на Лінії роблять такі розрахунки завжди, саме тому вони об'єднують тестові станції в кластери. Їх досвід, однак, відрізняється від вашого, і вони можуть «розрахувати» ідеальний випадок, тому необхідно продублювати їх роботу, зробивши так, як ви це розумієте.
У разі виникнення «горлечка» на будь-якому вузлі Лінії, вона буде зупинена, поки не відновиться баланс сил». Якщо лінію не зупиняти, то може виникнути перевиробництво (хто за нього заплатить?), захаращення складів і тимчасових сховищ на Лінії (може вилитися в протиріччя з пожежною безпекою), плутанина (не можна сказати частини працівникам Лінії, щоб вони зупинилися, а іншої частини, щоб прискорилися, віддати зворотний наказ буде на багато складніше).
Як правило, «шийку» — проблема Лінії, але якщо до вас будуть питання, то в запасі у вас вже є надісланий звіт менеджменту з цією статистикою. У цьому випадку будь-які питання «змінять тон» і стануть лише одним: «Ви можете що-небудь зробити?». Відповідь, швидше за все, буде ховатися в параметрах, які ви завчасно винесли в окремий файл.
На Лінії так само можуть виникати і сторонні проблеми, які взагалі ніхто не передбачив. Зазвичай їх вирішують оперативно. Але ряд з них може мати накопичувальний характер. Щоб уникнути «критичної маси» на вашому сайті попросіть внести в процес крок, який буде вимагати від інженера раз на день/тиждень відправляти вам весь набір логів з лінії – це ваші звіти і «інженерний журнал» кроку 12 Е. Аналіз цих даних дозволить вам швидко виявити проблеми, пропущені на всіх стадіях тестування та впровадження.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.