Source: www.sealights.io

       Dev (Розробка) та QA (Забезпечення Якості) завжди були спрямовані на досягнення одних й тих самих цілей, але за допомогою різних інструментів, систем управління та способу мислення. Зараз усе змінилося. Відділи розробки Dev та QA (Забезпечення Якості) не тільки тісніше співпрацюють, але й роблять це з більш ранніх стадій SDLC (Software Development Life Cycle). Як результат, виникає потреба використання деякого набору інструментів, що ґрунтується на тій самій філософії, Dev та QA ними однаково володіли, і працювали за тими ж самими методологіями. Таким чином, чіткість межі між цими двома групами стає все розмитішою.

      Цей аспект має вагомі наслідки для розробки програмного забезпечення, тому важливо розуміти першопричини, чому це відбулося і як поглиблюватиметься з роками. Але, окрім того, ці зміни уособлюють революцію в розробці  від початку кодування, аж до випуску готового програмного продукту. Й вимагає принципового переосмислення ролі Тестування з точки зору: Як, Хто, Що, Де, Коли?

Чому це відбувається саме зараз?

      Ми є свідками фундаментальної зміни нашого повсякденного життя. Майже кожен сервіс переживає цифрове перетворення. Існує додаток для майже до кожної послуги. Як зазначив один із співзасновників Netscape Communications, Марк Андресен: “Програмне забезпечення поїдає світ!” У свою чергу, це цифрове перетворення, великою мірою вплинуло на те, як програмне забезпечення розробляється та вводиться в експлуатацію.

      Якщо б ми мали описати дану зміну одним словом, це слово було б ШВИДКІСТЬ. Agile Development, Continuous Delivery, DevOps та інші методології (а також інструменти їх підтримки)  це вагомі частинки цієї культури швидкості. Якість програмного продукту досі все ще має найважливіше значення, тому тестування ПЗ повинне включатися у процес розробки якомога раніше. Проектування тестування, дизайн, планування автоматизації  повинні розпочинатися з етапу вимог, а реальне тестування повинне починатися у дотичності від початку написання коду. Також швидші та частіші випуски програмного забезпечення вимагають скорочення циклів розробки, для отримання швидкого відгуку та відповіді.

      Для скорочення QA циклів, критичне значення має раннє використання автоматизованого тестування. Test-Driven Development (TDD) одна з методологій, яка саме дозволяє це здійснювати розробникам, окрім інших переваг методології. Однією із найбільших переваг практичної реалізації (TDD) є можливість досягнення грунтовно пропрацьованого дизайну Вашої аплікації / компонентів / послуг та вбудованих тестів для валідації дизайнерських і користувацьких user-stories. Розробникам (TDD) гарантує, що будь який написаний код додатку можна перевірити за допомогою Unit Tests, Component Tests, MicroServices і т. д., а потім продовжувати написання коду додатку. За умови що написаний досі код підлягає можливості тестування. Оскільки автоматизовані тести записуються швидко на початку процесу тестування, їх час виконання є порівняно коротким і прямо пов’язаний з простотою відтворення. Просто пам’ятайте про те, що прості коди випробувань повинні залишатися простими, інакше Ви отримаєте просто тести заради тестування, а не для пошуку дефектів.

Developers  vs QA: хто тестує, що і коли?

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

     І це є саме той відрізок, де у гру повинна вступати команда QA engineer -s (інженерів з якості). QA engineer завжди повинен турбуватися  про якість на глобальному цілісному рівні. Робота тестувальника складається із integration testing, functional testing, exploratory testing, імітації реальних користувацьких сценаріїв, та інших видів тестування, які є надзвичайно складними або непрактичними для автоматизованого тестування. Ще важливіше, на відміну від розробників, які тільки перевіряють свій власний код, команда інженерів з якості випробовує код, написаний багатьма людьми й шанси побачити приховані помилки значно вищі.

      Тим не менше, команди QA engineer -s (інженерів з якості) перебувають у досить-таки невигідному становищі, порівняно із розробниками. CI (Continuous integration) / CD (Continuous Delivery) та (TDD) зробили великий прорив у здатність розробників дотримуватися зростаючої частоти випуску, і в певній мірі також забезпечили якість на рівні тестування елементів.  Проте, вплив розробників на забезпечення якості є опосередкованим. Вони все ще пишуть і виконують тільки Unit тести, що і раніше, у коротких часових рамках з точно такими ж інструментами та методиками. Результатом цього є, в кращому випадку, впевненість у тому що програма працює, в гіршому  може відбитися спадом на загальному рівні якості.

Як забезпечується тестування якості?

     Для якісного тестування важливе якомога ширше покриття на відміну від Unit тестування. Щоб забезпечити це краще покриття від Unit тестування, покриття ділянок недоступних до функціонального тестування та user stories окрім автоматизації необхідне застосування нестандартного людського мислення.

      Розробникам потрібно сприйняти більш комплексне уявлення поняття якості, яка охоплює всю систему потреб, значення та вартості продукту для кінцевого користувача. В цьому розумінні індивідуально-відокремлене мислення не є сприятливим. Для цього розробники (а не лише тімліди групи розробників) повинні співпрацювати з продуктовими групами, щоб зрозуміти переваги клієнтів, очікування та сценарії користувачів. Щоб більшою мірою зрозуміти потреби користувачів необхідно вести документацію user-stories. Успіх QA engineer (інженера з якості) максимально повна інформація про користувачів, задоволення вимог замовника та повноцінне протестовування продукту.

      З іншої сторони, інженери з якості також повинні розвивати свої навики у області кодування, для кращого розуміння коду розробників, для ширшого покриття, для написання автоматизованих скриптів більш точних, детерміністичних та простих у підтримці. Хоча ці вимоги ще є не обов’язковими до виконання, та для багатьох компаній важливо бути по переду у всіх трендах і впроваджувати такі практики вже зараз. Ми вже навіть починаємо розглядати галузеву тенденцію в цьому відношенні, як деякі компанії надають значну премію інженерам з питань якості (QA engineer -s), що можуть кодувати.

      Таке зближення сфер  це ще одна Continuous Testing революція у тестуванні програмного забезпечення. Еволюція, яка призведе до більш високого попиту на швидкість без шкоди для якості.

Як налагодити Continuous Testing у компанії?

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

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

Related posts

Leave a Comment

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.