Що роблять QA інженери?

Jitesh Gosai, Principal Tester at BBC

У статті Що таке QA інжиніринг? я почав формувати деякі основи того, що таке інженер з якості:

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

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

Що таке QA інженер?

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

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

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

Соціально-технічне системне мислення

З теорії соціально-технічних систем | Університет Лідса:

…будь-яку організаційну систему можна зрозуміти та вдосконалити лише тоді, коли “соціальні” та “технічні” аспекти об’єднані та розглядаються як взаємозалежні частини складної системи.

Системне мислення

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

Теорія соціотехнічних систем

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

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

Теорія складності

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

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

Таким чином, якість — це емерджентна поведінка складних програмних систем.

Якість емерджентна

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

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

Але як інженери з якості допомагають командам будувати якість на початковому етапі, якщо якість можна побачити лише постфактум?

Створення здоровіших систем за допомогою мислення, що навчається

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

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

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

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

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

Будівництво якості від самого початку

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

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

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

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