Shift Left: шифтуємо вліво на реальних прикладах

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Одна з моїх перших статей на DOU, написана більше трьох років тому, про TestOps. Я тоді знайшов трохи часу, щоб порефлексувати і відповісти собі на питання: хто я? Що я роблю? Як класифікувати свою роботу?

І дійшов висновку, що роблю багато речей, які не притаманні типовим активностям QA-інженера чи Test Lead. Натомість займаюсь розробкою, налаштуванням пайплайнів, конфігурацією середовищ, моніторингом... тобто типовими активностями DevOps.

І сам собою у мене в голові виник термін TestOps — методологія, спрямована на пришвидшення процесів розробки й тестування за рахунок щільної взаємодії QA з Dev та Ops, і за нагоди, виконання їхніх активностей, якщо це є bottleneck.

Я погуглив, і, на диво, такий термін в інтернеті траплявся не те щоб часто. Зате ми з Михайлом Чубом накопали статей з Shift Left та Shift Right тестуванню — активності, які чудово вписуються в концепцію TestOps! І нам дуже закортіло популяризувати термін і підхід загалом. У своєму резюме я серед основних навичок, до речі, маю TestOps 🙂

У коментарях багато писали типу «Гей, нащо новий термін? QA і так мають забезпечувати якість на всіх етапах життєвого циклу!». Тільки от етапів стало стільки, що одна людина фізично може все не вивезти, тож настає питання про розділення праці.

Я дуже рекомендую ознайомитись з оригінальною статтею, але сьогодні маю натхнення поговорити про Shift Left. Багато хто пише, що це зміщення фокусу тестування на ранні етапи розробки ПЗ. Але це лише концепція — як її використати на практиці? Я знову знайшов у собі трохи сил на рефлексію і вирішив написати низку практичних порад — що саме треба робити, шифтуючи вліво. Поради ви можете використати вже! Без реєстрації та СМС (цей жарт ще не застарів?).

Підемо просто за водоспадом, бо, як виявилось, тестові активності можна не просто «змістити вліво», а взагалі починати їх якомога раніше на кожному етапі розробки ПЗ.

Планування

Roadmap (дорожня карта) — те, що ви не помічаєте, коли воно є, але дуже помітно, коли його нема. Коли я був просто інженером, у моїй команді завжди працювали досвідчені менеджери, які стежили, щоб у нас був план і ми його дотримувались.

Коли я сам став тест-менеджером, в одному з нових проєктів я побачив, що номінально дорожня карта продукту розписана на три роки вперед, але фактично стейкхолдери не можуть сформулювати конкретні вимоги до компонентів продукту. А тому декілька разів на спринт приходять на мітинги, що видати порцію рандомних побажань в стилі «колись для цієї фічі буде скрин, і я хочу, щоб кнопочки тут були зелені». Тобто фічі нема, прототип не працює, але кнопочки, бляха, зелені! І до того ж демо просять регулярно й дуже дивуються, що ми не можемо показати цілісні фічі, бо «Там же все очевидно» ©.

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

Це наша задача — спланувати роботу та зробити процес розробки й тестування комфортним. Тож не зволікайте і не думайте, що все налагодиться саме собою. Дійте проактивно!

GTD (Get Things Done) — у вас ніколи такого не було, що в розмові з іншими QA ви чуєте, що вони використовують дуже крутий процес чи інструмент, і думаєте: «От би і нам таке». Але ви не можете це впровадити, бо ваші процеси вже зав’язані на інший стек технологій, тули куплені, купа роботи зроблена, люди звикли і «Ти шо, найрозумніший всьо мінять? Роками працювало — не чіпай».

Пам’ятаю, я розмовляв з одним інженером, який жалівся, що втомився бекапити код в архіви і деплоїти білди на сервер руками за ssh. Я питаю: а як же git? Білд-сервер налаштувати? На що отримав відповідь, що команда таких радикальних змін не сприйме. Та і замовник консервативний і платить за фічі, а не за оновлення процесів.

Або ж інший приклад: наймав я в команду Team Lead замість себе, і він мене питає, чи користуємось ми Teamscale? (не реклама). Я до цього навіть не чув про такий інструмент, а він допомагає мапити тест-кейси напряму на код! Тепер дуже хочу десь його спробувати 😀

Зазвичай люди використовують ті інструменти, до яких звикли у яких мають досвід. Тому першим кроком вліво має стати нетворкінг: саме спілкування з колегами, конференції, мітапи можуть стати для вас джерелом знань про цікаві тули, тренди та підходи. Другий крок — аналіз. Продумайте процес вашої роботи та які інструменти можна використати, щоб допомогти роботу робити: де спілкуватись (так, навіть месенджери важливі), де код писати, де зберігати, де документацію вести і задачі трекати, як все це між собою пов’язати для забезпечення traceability артефактів і чи ви зможете замінити / доповнити якісь інструменти за нагоди (чи є хоч банальний експорт даних)?

І оскільки ми шифтуємо вліво, цей аналіз має відбутися до початку роботи, а не під час, для латання дір на кораблі, що тоне. Якщо вам складно, найміть експерта-консультанта. Це не слабкість, а дорослий і виважений підхід (кажу це як експерт-консультант 😎).

Вимоги

Для кого працюємо? У багатьох інженерів (я не виняток) є проблема сприйняття вимог, яку можна влучно описати виразом «за деревами не бачу лісу». Ми так захоплюємось ідеями, як ми маємо запрограмувати чи протестувати вимоги, що не звертаємо уваги на їхню мету — вирішити проблеми користувачів. Я взяв собі за правило, аналізуючи вимоги, завжди питати: як би я це використав, якби сам працював із застосунком? Чи це буде зручно? Чи це зрозуміло?

В одному з проєктів замовник попросив зробити екран конфігу й розмістити на ньому десь 50 різних інпутів, чекбоксів, дропдаунів і кнопочок зі складною логікою деактивації певних елементів за активації інших, на три екрани. Бо він так бачить. А як я спитав, чи буде користувачам зрозуміло, що відбувається (оскільки я бачив подібний функціонал у вигляді мінімалістичної таблиці на пів екрану), замовник попросив до свого дизайну додати ще один, додатковий екран, де будуть показані результати конфігурації ¯\_(ツ)_/¯ Я б хотів не цього, але вже краще, ніж було.

Пріоритети. Зусилля мають бути адекватні до користі. Якщо замовник ПЗ хоче суперадмінку для налаштування своєї системи з крутим візуальним дизайном, гнучкістю і десятком графічних тем (десь на півроку роботи), а будуть користуватись цією адмінкою півтори людини, я б зекономив час та ресурси і рекомендував робити все простіше, сфокусуватись на більш важливих задачах. А до адмінки можна повернутись, як буде зайвий час.

Будьте експертами. Дуже часто ми робимо будь-яку дичину, яку від нас вимагають, бо «такі вимоги» чи «більшість людей хоче». Так-от, замовник часто не знає, як краще, бо його знання в дизайні застрягли десь у 90-х і тексти в стилі MS WordArt він вважає іконою стилю.

Уявіть ситуацію: приходить людина до лікаря і просить відрізати собі руку. «Але ж чому?» — питає лікар. На що отримує відповідь: «Бо в мене вухо болить і в інтернеті кажуть, що це єдиний спосіб лікування».

Наша задача — не критикувати ідеї замовників, а донести до них всі можливі варіанти рішення їхніх задач, пояснити плюси та мінуси і порадити найкращі (на вашу експертну думку). Щоб замовник ухвалив поінформоване рішення. Вам платять за те, щоб ви були експертами, тож будьте ними! І що раніше почнете, то краще.

А щодо «більшість хоче» — більшість зазвичай помиляється, бо більшість — не експерти і тим паче не візіонери. Свого часу «більшість» не бачила перспектив в смартфонах без клавіатури, але Apple зробила революцію з iPhone; «більшість» вважала комерційну космонавтику нерентабельною; «більшість» голосувала за Зеленського і Слуг Народу 😜

Не забувайте про NFR. За статистикою, більшість вимог до ПЗ — функціональні. Усі думають про те, що має робити продукт. І дуже часто ми забуваємо спитати про нефункціональні вимоги — як має працювати продукт? Як швидко? Як ефективно? Наскільки надійно? На яких пристроях / браузерах / ОС?

І згадують про них тоді, коли продукт уже готовий, але працює не так, як би того хотілося користувачам. І починаються хотфікси, костилі, кранчі. Турбуймося про якість заздалегідь!

Подбайте про майбутні покоління. Який би крутий, незамінний та інноваційний продукт ви не створювали, рано чи пізно його життєвий цикл завершиться і його потрібно буде замінити. Подумайте над тим, що буде потрібно для епічного фінального акорду — може це експорт усіх даних і конфігів в простий і зрозумілий формат? Можливо, саме ви будете розробляти нову версію, і така далекоглядність стане вам у пригоді 😉 Це хоч і не найпріоритетніша задача, але точно варта уваги.

Дизайн

І ось ми вже добрались до архітектури. Чи можна тут шифтувати вліво? Треба!

Робіть усе просто і явно. Мені дуже імпонує концепція Zen of Python. Наче нічого особливого, робіть добре й не робіть погано, але деякі пункти я взяв на озброєння і активно просуваю під час розробки:

• Будь-який продукт має робити всі дії явно. Ніяких прихованих чи неочевидних рухів. Якщо кнопка називається зберегти дані, вона має тільки зберегти дані. Якщо на додачу ви ще й Email комусь надішлете і відкриєте попап для реєстрації на сторонньому ресурсі, бо «ну ми ж зручніше намагаємось зробити». Про це або має бути повідомлено користувачу, або розбито на декілька дій. Якщо ваша програма щось завантажує, вона не має виснути — додайте хоч якийсь лоадер.
• Прості рішення кращі за складні. Якщо вам треба інпут з валідацією та автозаповненням і на його роботу потрібно кілька днів, зробіть спочатку просто інпут, щоб протестувати, а валідації й автозаповнення прикручуйте за нагоди.
• Помилки мають бути оброблені та інформативні, щоб користувачі не просто знали, що помилка сталась, а знали чому і (в ідеалі) що зробити, щоб її виправити.
• Якщо вам, користувачам, замовникам, аналітикам чи розробникам складно пояснити вимоги чи алгоритм реалізації — значить ми щось робимо не так.

Принципи розробки — в маси! Майже кожен розробник і автотестер може розказати вам про SOLID, DRY, KISS, <badass_principle_name> і як він використовує ці принципи під час написання коду. Але на рівень дизайну системи ці знання чомусь не масштабуються. Наприклад: S в SOLID означає Single responsibility — один клас виконує лише одну задачу. Але якщо ми створюємо мікросервіс, то нехай він робить і перше, і друге, і п’яте. Зрештою маємо не мікро, а таки собі макросервіс, монстр Франкенштейна, який важко підтримувати і тестувати.

Testable by Design. Завжди пам’ятайте: тестери, інженери підтримки й адміністратори — теж користувачі продукту, що розробляється. Продукт має бути зручний і для них. Якщо тестерам на етапі тестування потрібні maintenance API, щоб простіше сетапити дані для тестів — створіть відповідні задачі і реалізуйте. Ми не маємо витрачати десятки годин, щоб просто підготувати дані для пʼятихвилинного тесту. Це має бути ваша ініціатива. Якщо не попросите самі, вам не запропонують.

Якщо користувачі / замовники просять зробити складну функцію — запропонуйте одразу додаткову фічу з її перевірки. Наприклад, відеоредактор: перед тим, як запускати 10-годинний рендер, може згенерувати за запитом 5-секундне відео, щоб показати результат і внести правки, не витрачаючи час на невідомість.

Ну і звісно, логи — мій постійний біль. Або їх мало, або вони неінформативні, або вони дублюються чи мають неправильний рівень. Тест-інженери, якщо ви бачите, що вам не вистачає логів, — заводьте задачі на їхнє додавання. Якщо є зайві — заводьте задачі, щоб їх прибрати. Бо логи — це про підтримку системи, а підтримуваність — одна з восьми характеристик якості ПЗ. Будь-яка програма заслуговує бути якісною з усіх сторін!

Розробка і тестування

Якщо ви думаєте, що на цих етапах вже пізно рухатись вліво, то ніт — це ніколи не пізно 😀

Unit tests. Як тест-інженер і автоматизатор, я взяв за правило допомагати розробникам писати Unit-тести. З них код, з мене — дані. Для генерації даних я навіть сам писав алгоритми згідно з вимогами. І намагався не робити жодних припущень: не розумію на 100%, що мається на увазі — баг вимог і потребує уточнення. Це подвійна робота, зате в такому випадку алгоритм вдвічі краще проаналізований і протестований.

Integration. Типовий блокер багатьох Enterprise-розробок: ви зробили свою частину і чекаєте, поки вам нададуть сторонні сервіси для інтеграції, щоб виявити, що в інших виробників була інша версія вимог і тепер вам потрібно ASAP адаптувати API, щоб встигнути до дедлайнів. Або ви всі неправильно зрозуміли E2E-сценарій і треба все переробити. По-перше, завжди намагайтесь комунікувати з іншими командами (напряму, якщо це дозволено, або ж через замовника), щоб розуміти прогрес інших, що саме вони роблять і за якими вимогами. Просіть надавати вам хоч якісь чорнові версії інших систем для ранньої інтеграції. По-друге, створюйте моки і намагайтесь провести E2E самотужки. Це не панацея, але знали б ви, скільки помилок було виявлено і попереджено через вчасне тестування з моками.

Тестові дані. Дані — наше все! Навіть ідеально написане ПЗ може працювати не так, як хоче користувач, якщо він ввів криві дані, неможливу комбінацію, пропустив поле. Намагайтесь дістати та створити реалістичні й нереалістичні (corner case) тестові дані заздалегідь. І готуйте дані для системи в цілому. Не можу не згадати випадок, коли ми тестували банківську систему на сотнях тисяч даних, а в проді їх створили мільйони, і продуктивність значно просіла, незважаючи навіть на масштабування ресурсів. З тих пір намагаюсь генерувати дані в тестовані системи заздалегідь, щоб наблизити умови до реальних.

Усі ваші тестові наміри мають бути явними. Вимога робити все явно стосується не лише продукту. Пишіть тест-план: декларуйте, що і як будете тестувати, що вам потрібно для тестування, і вимагайте все, що потрібно. Щоб потім не жалітись, що тест-кейси готові, а тестового середовища вам злі DevOps не створюють.

Якщо у вас блокер в тестуванні — не чекайте, що воно якось само мине. Комунікуйте, пишіть листи, збирайте мітинги й контролюйте, чи розвʼязуються після комунікації проблеми. Бо часто буває, що провели десять мітингів, а проблему так ніхто і не розвʼязав.

Якщо ви чогось не знаєте — питайте.

Завжди робіть оцінку — скільки часу вам потрібно на тестування і які можуть виникнути ризики, що вплинуть на час тестування, щоб команда знала, коли можна очікувати результати вашої роботи.

Пишіть інструкції. Є таке поняття — bus factor. Чи зможе команда працювати без вас? Чи всі знають, що ви робили? Записуйте інструкції, в текстовому чи відеоформаті про те, як працює продукт, який ви тестуєте, діліться досвідом. Не чекайте, поки щось станеться чи вас явно попросять задокументувати все.

Summary

Майте здоровий глузд, критичне мислення, будьте проактивними і пам’ятайте, що розробка ПЗ — це командна робота.

Дякую, що дочитали! Якщо вам сподобалась стаття, кидайте копійчину на РЕБ для морпіхів.
Якщо не сподобалась, то теж кидайте 👇
🔗 Посилання на банку