Хто відповідає за якість продукту: розробник чи тестувальник

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

Що таке якість продукту?

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

Згідно стандарту ISO 8402:1994 якість продукту – це сукупність характеристик ПЗ, які відносяться до здатності задовольняти існуючі потреби користувача та ті, що можуть виникнути в процесі використання. Іншими словами, це показник того наскільки продукт відповідає явним і неявним вимогам, які поставлено до нього.

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

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

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

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

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

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

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

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

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

Що потрібно на стороні тестувальників, щоб покращувати якість продукту?

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

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

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

Що потрібно на стороні розробника, щоб покращувати якість продукту?

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

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

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

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

Висновок

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