Розробка програмного продукту та роль QA-спеціалістів на проєкті

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

В розробці програм бере участь безліч IT-фахівців: це програмісти, дизайнери, бізнес-аналітики, менеджери та безпосередньо QA-інженери. Останнім доводиться досить ретельно розбиратись із поставленими задачами, аналізувати вимоги, комунікувати з командою та замовником, відстоювати свою думку щодо покращення продукту та процесу розробки загалом. Робота QA багатогранна і справді цікава! 

Та перш ніж перейти до розʼяснення двох магічних букв QA (скорочено від quality assurance), спершу розглянемо поняття якості програмного продукту (software quality).

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

Якість (software quality) — це ступінь, з якою програмне забезпечення здатне відповідати заданим вимогам та задовольняти потреби користувачів.

Що ж таке забезпечення якості (quality assurance)? Це сукупність заходів, націлених на те, щоб випустити програмний продукт, який відповідатиме заданим критеріям якості. Тобто основна мета QA-спеціалістів — це випустити для користування якісний продукт. А от як саме це зробити — це вже ціла наука, що крім теоретичних навичок потребує ще й багато практики. Наразі поняття QA досить часто об’єднують чи ототожнюють із тестуванням, та насправді це не одне і те ж. 

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

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

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

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

Виділяють також поняття QC (quality control), яке теж є частиною процесу забезпечення якості. QC (або контроль якості) передбачає контроль дотримання вимог під час розробки програмного продукту. Тобто, як бачиш на зображенні нижче, до QA-активностей входить і тестування, і контроль якості продукту. 

Гаразд, підсумуймо зони відповідальності кожного з цих процесів:

• Тестування: ми перевірили, чи в програмі все працює, та надали про це інформацію;
• QC: ми проконтролювали, щоб усі учасники розробки дотримувались вимог, зібрали інформацію про стан програмного продукту;
• QA: ми проаналізували надану інформацію та сформували інструкцію, як покращити процес розробки та якість програмного продукту.

Поняття тестування та задачі, які виконують QA-фахівці

Зазирнемо ще трохи у процес розробки програм, щоб зрозуміти, де ж там є місце тестуванню і що воно передбачає.

До прикладу, є команда з розробки сайту apple.com. Вона складається з програмістів, дизайнерів та тестувальників. Усім відомо, що у вересні кожного року компанія Apple демонструє нові продукти (це зветься реліз (release)) і ці новинки виходять у продаж. Ще за декілька місяців до дати релізу, команді з розробки сайту ставлять задачу додати всі нові продукти на сайт і перевірити чи все працюватиме належно в день релізу. Спочатку дизайнери проєктують, як товари відображатимуться на сторінці, описують, які будуть кнопки та переходи між сторінками. Далі програмісти втілюють це в код і віддають на перевірку. На цьому етапі підключаються тестувальники, які повинні переконатись і підтвердити, що все працює згідно поставленими вимогами. Якщо щось працює некоректно, тоді програмісти або дизайнери допрацьовують ці елементи, віддають знову на перевірку, і тестування проводиться ще раз. Це може повторюватись нескінченну кількість разів (ітерацій), доки продукт не відповідатиме заданим критеріям якості, узгодженим від початку.

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

Отже, основні завдання та цілі тестування — це:

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

Та головне, пам’ятай, що тестування — це НЕ пошук помилок (багів)! Усі невідповідності (помилки, баги) в програмі, які були знайдені в процесі тестування, є лише результатом цього процесу, а не його метою.

Щоденні обов’язки та як виглядає типовий робочий день QA-спеціалістів

Уявімо, що ти розпочинаєш роботу в тестуванні чи як QA-спеціаліст_ка. Погляньмо, що тебе очікуватиме протягом робочого дня.

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

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

Після закінчення дзвінка усі повертаються до своїх обовʼязків. Тестувальники протягом дня займаються таким:

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

Кому підходить ця спеціальність

Звучить цікаво, але й важко! Що ж потрібно, щоб впоратись із такою роботою?

Нумо з’ясуємо, якими навичками повинні володіти тестувальники, та спростуємо деякі міфи стосовно цієї спеціальності. Перш за все, не варто лякатись усіх страшних на невідомих слів, які вживають у вакансіях (SQL, git, API тощо). Це всього лише технічні навички, які ти зможеш опанувати, витрачаючи декілька додаткових годин на день.

А от без чого тестувальникам точно не обійтись, то це:

• уважність та скрупульозність;
• готовність довго робити одну і ту ж задачу (витримувати монотонність);
• вміння аналізувати інформацію;
• допитливість (але не надокучливість!);
• вміння самостійно шукати відповіді на свої запитання;
• знання англійської мови (так-так, зараз усе важче знайти першу роботу без бодай базового знання англійської).

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

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

Як зрозуміти, що цей фах для тебе

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

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

Ми поговорили про особистісні якості тестувальників і кар’єрні можливості. А тепер кілька слів про те, чим керуються всі тестувальники світу (якими б посидючими джунами чи харизматичними тімлідами вони не були).

Принципи тестування та чому важливо їх дотримуватись

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

1. Тестування показує наявність помилок, а не те, що їх немає. Навіть, якщо під час тестування не було знайдено жодної помилки, це не означає, що вони взагалі відсутні і ми дарма зробили свою роботу. Пригадаємо, що основна ціль тестування — це переконатись, що все працює згідно з вимогами.
2. Протестувати все повністю неможливо. Кількість перевірок навіть для функції реєстрації нового користувача на сайті може сягати нескінченності. Завжди потрібно виставляти пріоритети і тестувати лише найважливіші сценарії. Особливо це матиме значення в умовах виділеного обмеженого часу на тестування.
3. Чим раніше починаємо тестування, тим краще. На етапі дизайну вже можна зафіксувати помилки ще до того, як цей дизайн попаде до розробників. Пам'ятай, чим раніше в процесі розробки знайдена помилка, тим дешевше та простіше її виправити. Найгірше — це коли помилку знаходить кінцевий користувач і не може належно використовувати програмний продукт (відповідно компанія може понести як фінансові, так і репутаційні втрати).
4. Кластеризація помилок — це принцип, який свідчить, що якщо була знайдена помилка в одній частині функціонала, є велика ймовірність, що в тому ж функціоналі містяться й інші помилки, і саме там тестування потрібно провести ретельніше.
5. Парадокс пестициду означає, що потрібно оновлювати та регулярно переглядати наявні тести. Тести, які пишуть тестувальники, — це наживка для помилок. Якщо користуватись одним і тим самим набором та не оновлювати дані, такі тести згодом перестануть “ловити” помилки.
6. Тестування залежить від контексту. Коли тестуємо нове програмне забезпечення для проведення операцій на серці, то підхід до побудови тестування буде відрізнятись від тестування оновлень для сайту Netflix.
7. Відсутність помилок — не гарантія успішного продукту. Навіть все протестувати, все зробити згідно з вимогами та виправити усі знайдені помилки — це не означає, що таким продуктом будуть користуватись. Тому важливу роль відіграє саме робота QA-спеціалістів, які можуть проаналізувати та вказати на те, що для розробки продукту потрібно змінити вимоги, або надати пораду, як краще було б впровадити той чи інший функціонал.

Отже, ми ознайомилися з поняттям якості програмного продукту, різницею між QA, QC та тестуванням, розібрали основні обовʼязки тестувальників та 7 основних принципів тестування. Так тримати! Наступного уроку поговоримо про вимоги та різні види тестової документації, з якою працюють QA-фахівці. 

‍

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

Отже, щоб знайти свій ідеальний борщ (персональну кар’єру) треба:

По-перше, спробувати різні борщі та дізнатись, які з них тобі до смаку: зелений (QA Manual), пісний (UI/UX дизайн), з грибочками (Front-End розробка) чи якийсь інший? Ти вже це робиш, проходячи цей курс.

Для цього проведи рефлексію над прочитаним матеріалом: 

1. Чи збігається твоє уявлення про роботу тестувальника із тим, що описано у цьому уроці?

2. Чи сформувалось уявлення про роботу тестувальника після проходження уроку?

3. Чи з’явилось бажання попрактикуватись у цій галузі? Якщо так, чекаємо на тебе у наступному уроці. Якщо ні, спробуй поцікавитись іншими напрямами. В цьому курсі ми розповідаємо про:

• проєктний менеджмент в ІТ;
• UI/UX дизайн;
• фронтенд-розробку;
• python-розробку.

4. Які аспекти професії тестувальника тебе найбільше зацікавили? 

5. Чи допоміг цей урок зрозуміти, які навички необхідні для фаху тестувальника?

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

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

А для цього зроби ось такі кроки:

1. Пройди ось цей тест, що визначить яка з 16 персоналій твоя*. 
2. Після цього прорефлексуй, наскільки отриманий результат здається тобі точним. Чи справді ця персоналія про тебе? Чи було там зазначене те, що ти і так знаєш про себе? Можливо щось було нове?

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