Вчимося на помилках в організації контролю якості

Привіт, Хабр! Мене звати Ілля Кудінов, і я працюю QA-інженером в компанії Badoo. Три роки тому я почав відвідувати різні IT-конференції і розповідати про процеси і технології, використані нами при контролі якості. І звичайно ж, після кожної доповіді я спілкувався зі слухачами, цікавився, як вони працюють. У цій справі мене завжди мотивували відгуки виду «Раніше ми працювали ось так, але, послухавши твій доповідь, ми побачили, як можна зробити краще», а ще краще — коли люди не копіюють наші прийоми, а придумують щось самі, іноді навіть більш цікаві варіанти. Таких історій у мене накопичилося багато, і я хочу поділитися з вами деякими з них (всі імена і назви вигадані, будь-які збіги з реальними особами є випадковістю). Може бути, щось з цього допоможе вам побачити напрямок розвитку вашого власного проекту — і це буде найбільшою нагородою для мене! Зрозуміло, буду радий після цього вислухати і ваші історії — у коментарях або особистих повідомленнях.

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

Візуалізації думок та ідей будуть допомагати ось ці три товариша, знайомтеся:


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

Втім, з метою спрощення мови, «тестувальник» теж зійде, але тільки якщо ви говорите це з належною повагою.

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

насправді роль тестувальника в проекті в кінцевому рахунку є нітрохи не менш важливою, ніж роль розробника. Бьерн Страуструп (дат. Bjarne Stroustrup) в своїй книзі «Мова програмування C++» писав: «Програма, яка не пройшла тестування, не працює». Навіщо вам потрібні програмісти, продукти яких ніколи не будуть працювати? Тестувальник — не раб розробника, великодушно видає завдання типу «перевір, поки я розкладаю на прод». Навпаки, розробник і тестувальник спільними зусиллями досягають поставленої мети — випустити продукт до призначеного терміну в максимально високій якості. Саме для цього і створюється відділ контролю якості. Але… як його організувати?


QA-відділ

Отже, компанія «ФОЛІАНТ ОСІБ» вирішила займатися розробкою програмного забезпечення. Вона підійшла до цієї справи грунтовно, навіть зважилася на створення QA-відділу! Скільки потрібно набрати туди людей, якщо у нас вже є 12 розробників? Класичний підхід підказує, що приблизне співвідношення робочої сили повинно бути таким: 1 QA-інженер на 3-4 розробників. Сказано — зроблено! Наймаємо трьох інженерів і вважаємо себе великими молодцями.
Проект починає розвиватися, до QA-відділу висуваються все нові і нові вимоги. Ось ми вже достатньо подорослішали, щоб виробляти релізи не просто викладенням gzip-архіву на продакшн, а шляхом добре побудованого і налагодженого деплой-процесу. Хто буде цим займатися? Віддамо це нашого фахівця у відділ контролю якості!
Функціоналу стає все більше — тестувати регресію все складніше. Один з наших тестувальників має досвід розробки? Відмінно! Нехай він тепер займається розробкою автотестів! Добре ми придумали, так?
Що ми отримали в результаті такого чудового плану? Тестуванням завдань наших дванадцяти розробників постійно тепер займається тільки один з QA-інженерів. Цікаво, чому чергу на тестування почала зростати і наші відмінно організовані релізи регулярно затримуються?

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


Дивіться, інша маленька компанія — «ЩЕБЕТАЛКА»! У неї дуже великі і серйозні плани. Починають вони з малого: чотири розробника, пара менеджерів і один (дуже гордий) тестувальник. Час проходить, бізнес йде в гору, кількість замовлень на розробку все збільшується і збільшується. Щасливі та задоволені результатом керівники проекту оголошують розширення штату. Для початку наймемо ще одного продакт-менеджера, нехай генерує більше вибухових ідей. Запитів на нові фічі стає все більше? Терміново набираємо нових розробників!
Ого, більше користувачів? Більше прибутку? Хлопці, ми йдемо вірною дорогою — наймаємо ще розробників, хай засипле наш проект фічами! Як же це все прекрасно! Але що ж це? Чому стало більше багів? Чому користувачі незадоволені? Адже ми найняли більше людей, чому ми відстаємо від графіків? Ах, наш нещасний тестувальник, ми зовсім про нього забули!

Урок: відділ контролю якості варто розвивати паралельно відділу розробки. Можливо, навіть з випередженням. Складно боротися з конкурентами і доставляти користувачам новаторський функціонал, якщо ви не можете забезпечити проектом належну якість.


А ось у компанії «ТЫНДУКС» всі процеси вже давно поставлені. У неї чималий відділ розробки і цілком відповідний йому відділ тестування. Розробники та QA-інженери сидять в різних приміщеннях, розділених великим холом, і недобро переглядаються через щілини прочинених дверей.
Завершивши роботу над завданням, розробник з усією люттю, доступної при натисканні на кнопку Assign в Jira, кидає задачку на тестування. Тестувальник недовірливо дивиться на задачку, з огидою відкриває її і через кілька секунд з гідною заздрощів люттю повертає завдання на доопрацювання з поясненням: «У вас помилка в коментарі!» Здавалося б, при такому завзятті до роботи якість повинна бути на висоті. Напевно, вона там і є. Але ми цього ніколи не дізнаємося, тому що при такому підході завдання добереться до продакшену приблизно… ніколи.

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

Тут варто зауважити, що в деяких випадках подібний підхід все ж доречний. У «промисловій розробці (наприклад, при підтримці софта, що використовується на літаках) якість і відповідність процесів може ставитися вище швидкості, і це правильно. Напевно, я б не хотів літати на літаках, тестованих і розробляються працівниками невеликих «ультрасучасних і швидко» стартапів.


QA-процес

І ось QA-відділ організований. Чим він буде займатися? Правильно, контролем якості. Але як цей процес буде влаштований?

Будь-QA-процеси завжди будуються навколо балансування між якістю і швидкістю. Абсолютна якість недосяжно (якщо ви зі мною будете сперечатися — сподіваюся, ви розробляєте літаки), тестувати завдання миттєво теж неможливо. Де ж знайти цю рівновагу? Тут кожна команда може придумати своє рішення. Для когось це Continious Integration, хтось віддає перевагу строго регламентованим і спланованим релізам — і можна просто підглянути процеси, поставлені вашими сусідами по гаражу.

Як QA-процеси вбудовуються в процеси розвитку проекту? Давайте поділимо їх на три етапи: продакт-дизайн, розробка і тестування. Два молодих стартапу підійшли до цього питання зовсім по-різному: компанія «БОДУНЫ» щільно зв'язала QA-інженерів з кожним з них, а «МАЙЖЕ.РУ» залишила їм тільки тестування. Хто з них правий? Як кажуть, істина може бути десь посередині.
Що ми отримуємо з кожним новим етапом QA-процесу? Якість. Що ми втрачаємо? Швидкість. Якими ж етапами контролю якості можна жертвувати?

Тестуванням? НЕМАЄ.

Контролем якості при розробці? Звучить важливо. Ні, звичайно не потрібно, щоб тестувальник сидів за плечем у розробника і боляче щипав його кожен раз, коли той забуває поставити крапку з комою. Є багато інших способів допомогти розробникам дотримуватися певний рівень якості. Вдало налагоджена система контролю версій, різні хуки і скрипти для перевірки коректності коду, написання юніт-тестів (тут, правда, QA може виступати тільки в ролі наглядача з батогом і пряником), зручна система code review — все це в ділянці відповідальності відділу контролю якості.

Контролем продакт-дизайну? Ну… У «промисловій розробці існує цілий напрям контролю якості — тестування та аналіз ТЗ. Це допомагає уникнути логічних і архітектурних помилок на початкових етапах розвитку кожного проекту — і катастрофічно віддаляє можливість початку розробки.
Напевно, у молодому стартапі це зайві заходи. Висока інтеграція різних відділів один з одним дозволить всім учасникам проекту (і розробникам, і тестувальникам) побачити подробиці проекту, визначити шорсткості і донести до менеджменту корисні (і не дуже) ідеї. До того ж, у нашому світі динамічних проектів і Agile-методології ТЗ часто змінюється вже під час розробки (і навіть після релізу, в кінці кінців), так що має сенс дозволити продакт-менеджерів виражати себе безконтрольно і вже потім вносити свої пропозиції та поправки.

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


Дивіться, розробник компанії «БУБЛ» віддав своє завдання на тестування і абсолютно впевнений, що побачить її знову тільки у разі повернення на доопрацювання. І що ж, на етапі тестування беруть участь тільки QA-інженери? Зовсім не обов'язково. Звичайно, при виявленні кожної неясності можна відразу ж повертати задачку, але це цілком може виявитися звичайним непорозумінням, а завдання при цьому зависне в якихось проміжних статусах. Тому (і не тільки тому, звичайно) спілкування і взаємодію в процесі тестування — безцінне. У разі виявлення дивних і незрозумілих моментів завжди можна сісти разом з розробником і спробувати розібратися. З одного боку, якщо це поведінка помилкою не є, то можна розібратися в алгоритмі і уникнути всіх затримок з переходом статусу. А якщо це виявляється несподіваною помилкою, то таке вивчення може допомогти розробникові вирішити проблему з ходу, а не дістатися до переоткрытой завдання через кілька днів і намагатися з нуля збагнути, що ж там відбувалося.

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


У компанії «НАЛИНИИ» прекрасно побудований процес розробки. У розробників є повний набір інструментів для оптимізації процесів розробки та спрощення розподілу роботи. Вони користуються системами проджект-менеджменту і системами контролю версій: ніхто один одному не заважає і вся їхня робота завжди в цілісності й схоронності.
А ось у їхніх відділу контролю якості всі давно не так безхмарно. Історично склалося так, що релізи на тестування відправлялися їм у якості архівів, вкладених в пошту. Ну, хтось колись придумав, і всі звикли. Вони пишуть свою документацію на численних папірцях, розкиданих по всьому відділу (деякі особливо хитрі інженери завели справжній спільний Google Doc, але дуже бояться, що їх рано чи пізно спіймають і змусять все переписати на папірці). Дуже шкода, що ніхто не може проявити ініціативу і спробувати об'єднати використовувані технічні засоби!
Адже можна було б використовувати загальні репозиторії, загальні бази знань, інтегрувати один в одного системи баг-трекінгу, складання додатків і зробити все таким красивим, автоматизованим і цілісним… Але немає, на жаль, розробникам довелося б для цього відвикати від звичного flow і навіть (!) розробляти і налаштовувати щось нове. Але ні, листами якось зручніше…

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


Тестувальники компанії «КРУПНОЖЕСТЬ» завжди працюють за суворим тест-кейсів. Заборонена будь-яка свобода дій — і не дай бог хтось дозволить собі пропустити бодай один пункт в тест-плані! Відсутня позначка у чек-листі рівносильна злочину і карається читанням «Війни і Миру» вголос перед усім відділом. Окремі інженери цілими днями займалися виключно підтримкою цієї документації, а кожен тестувальник був зобов'язаний складати кейси для кожного порушеного ним функціоналу. Звичайно, якість була на висоті! Спочатку… З'ясувалося, що на продакшені почали з'являтися баги. Баги на продакшені, Карл! При перевірці чек-листів з'ясувалося, що цей функціонал перевірявся, та відповідальний тестувальник з самим невинним виглядом активно киває головою: перевіряв, перевіряв! А потім з'ясувалося, що деякі компоненти продукту не перевірялися вже роками просто тому, що вони не знайшли собі місця в тест-документах. Керівника відділу змусили писати звіт і пояснювальну щодо того, що відбувається в чотирьох томах зі змістом.
Напевно, було б краще, якщо б тестувальники при роботі думали своєю головою, а не дотримувалися суворих вказівок. Мали б загальний джерело інформації, але не у вигляді «Що робити», а у вигляді «Як це працює». Звичайно, це може негативно вплинути на швидкість тестування, адже кожен раз буде необхідно досліджувати фічу або (не дай бог!) спілкуватися з іншими тестерами і (!) розробниками, щоб зрозуміти, що треба б тут перевіряти.

Урок: загальна документація, що дозволяє визначити, що варто тестувати тієї чи іншої задачі — добре. Докладні інструкції і кейси… напевно, не дуже. (розробники літаків — забудьте, що зараз прочитали. Будь ЛАСКА!)


У компанії «ПРИНТЕЛ» дуже цінують поділ праці. Кожен тестувальник прив'язаний до того чи іншого функціоналу і компоненту — і він прекрасно знає, що і як має сенс у ньому тестувати. Якість і швидкість на висоті, компанія йде до успіху. А потім один з QA-інженерів виграє в лотерею і їде жити на Канари. Решта перезирнулися і спробували розібратися в тому, що він за собою залишив. Ніхто нічого не зрозумів, і тестували абияк, поки не був знайдений новий інженер на місце щасливчика. Всі зітхнули від полегшення… Поки не з'ясувалося, що в мріях який був лікарем і всі його записи велися дещо незрозумілим почерком. Розробка компонента встала майже цілком до тих пір, поки новачок не зміг освоїтися в ньому з нуля.

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


QA-інженер компанії «КРАБЫРАДЫ» нарешті закінчив роботу над складної системної завданням, на яку він витратив не один робочий день. Він простежив за її відправкою на продакшн, зітхнув вільно і пішов пити пиво з друзями. Чи Правильно він чинить? Я так не думаю.
Навіть якщо у його компанії є серйозний відділ моніторингу, цілодобово червоними очима спостерігає за десятками і сотнями графіків та метрик, йому може знадобитися чимало часу, щоб локалізувати раптово виникла з нізвідки помилку або падіння активності. От було б здорово, якби хтось міг їм допомогти, чи навіть просто не допустити того, щоб їм довелося шукати причини цього безладу…
А адже той самий інженер міг випити сьогодні всього на одну пінту «Гіннеса» менше, зате врятувати чимало людино-годин (і, можливо, грошей компанії), якщо б витратив деякий час на вивчення поведінки продакшену після релізу. Вивчити логи помилок, перевірити тренди тих графіків, які описують стан порушених у задачі компонентів. Так, іноді баги добираються до продакшену. Виною тому може бути людський фактор, відмінності в оточенні або навіть просто одна з тих мільйонів user story, які генерують справжні користувачі.

Урок: QA-процес не припиняється відразу ж після релізу завдання на продакшен. Завжди має сенс постежити за поведінкою нового функціоналу, і вкрай важливо мати інструменти, які це дозволяють.


Тестувальник компанії «ЯБЛУЧКО» вперше в житті пропустив на продакшен прикрий баг. Напевно, він міг його виявити, якщо б витратив на це ще пару годин, але це вже сталося. Баг полагодили, але він встиг торкнутися користувачів. Компанія дуже незадоволена тестувальником. Розробник фічі незадоволений тестувальником. Він отримує стягнення і позбавляється премії, щоб неповадно було і надалі не щадив себе при тестуванні. Чи Правильно вчинила компанія? Я думаю, що ні.
QA-процеси не скасовують можливість появи дефектів — вони спрямовані на зниження ймовірності їх виникнення. І в цих процесах беруть участь всі порушені в проекті люди. І відповідальність за дефекти в рівній мірі лягає на всіх: на керівника, який недостатньо замотивировал і навчив своїх співробітників; на розробника, який допустив помилку; на тестувальника, який цю помилку пропустив. Навіть на тих інженерів, які покривали цей функціонал автотестами — адже їх тести могли зловити цей баг, але не змогли! Варто їх карати? Можливо, але тільки при системних проколах. Набагато корисніше буде провести глибоке вивчення причин події, організувати освітні семінари і всі можливі заходи, для того щоб знизити ймовірність виникнення подібних дефектів у майбутньому.

Урок: у виникненні дефектів винні всі беруть участь в проекті боку, не варто звинувачувати в його виникненні тільки тестувальника.


Автоматизація

У компанії «СЦОННИ» прийняли рішення почати розробку автоматизованих тестів. Один з тестувальників має навички програмування, і цю задачу віддали йому. Він писав тести, був задоволений своєю роботою і в якийсь момент покрив тестами майже весь продукт. Всі були раді, поки не помітили, що пішов в інший проект тестировщику не стали шукати заміну.
Подія перетворилося на тенденцію, і QA-відділ почав танути. Коли перелякані інженери прибігли до керівництва, то з посмішкою відповів: «У нас тепер такі чудові автотесты, навіщо нам нудні несучасні ручні тестувальники?» Пояснити їм нічого не вийшло, і все залишилося на своїх місцях. Справи йшли добре до тих пір, поки на продакшені не стало з'являтися все більше і більше помилок, і всі вони — в самому новому, ще не покритому тестами функціоналом. Керівництво усвідомило свою помилку, але було вже надто пізно… *гучний драматична музика*

Урок: автотесты є виключно допоміжним засобом контролю якості і жодним чином не замінюють собою ручне тестування.


А ось у компанії «ШАНТСУНГ» такої проблеми не відчували. Їх відділ автоматизації тестування був повністю відокремлений від відділу ручного тестування. «Автоматизаторы» навіть відчували себе представниками якоїсь більш високої касти і поблажливо спостерігали за тими, кого вони називали «ручниками». І було таке поділ, здавалося, зручно всім, поки не стали виникати проблеми. «Автоматизаторы» стали так глибоко занурені в підтримку сотень своїх тестів, що втратили всяку можливість розробляти щось нове (і дотримуватися поставлені KPI, звичайно), а «ручники» абсолютно не уявляли, що там відбувається у їх колег, і перестали покладатися на тести, перевіряючи вручну все те, що було тестами цілком покрито (але про це ніхто не знав!), і це суттєво зменшило користь від всього заходу.

Урок: набагато краще, коли з автотестами працюють всі представники QA-відділу. Нехай не всі з них будуть в змозі написати тест з нуля, але зробити так, щоб кожен інженер міг оцінити стан тестів в даний момент, зрозуміти причину їх провалів, поправити простеньку помилку або покрити тестом новий нескладний кейс, варто.


Замість післямови

Сподіваюся, що щось із того, про що я багатослівно писав, виявиться для вас корисним. Кому-то допоможе знайти шорсткості в процесах, іншим підкаже вихід із вже досліджуваної проблеми. Навіть якщо і не так, може, ви хоча б посміялися над тим, що я вам розповів. Або хоча б над моєю наївністю. Головне — зробити світ краще хоч щось, хоч трошки. Правда?
Джерело: Хабрахабр

0 коментарів

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