Чому QA інжиніринг?

Jitesh Gosai, Principal Tester at BBC

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

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

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

Спочатку автоматизація UI допомогла, і потреба в більшій кількості тестувальників зменшилася. Але швидкість, з якою змінювалося програмне забезпечення, також означала, що UI-тести повинні були змінюватися в тому ж темпі, і чим більше у вас було UI-тестів, тим більшою ставала ця проблема. Здавалося, що для того, щоб не відставати, вам потрібна ціла армія автоматизованих тестувальників.

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

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

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

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

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

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

Далі буде…

Джерело: Jitesh Gosai (оригінал допису)

Перекладено та адаптовано на основі оригіналу: редакція