Існує 5 важливих пунктів, з якими обов'язково повинен ознайомитися тестувальник-початківець і застосовувати їх у своїй подальшій роботі та професійному середовищі. Це всього лише основні знання, їх слід закріпити в своїй свідомості і вивчати нову інформацію, структурувати її, прагнути до пошуку нових завдань та їх рішень.
Почнемо з найважливішого для кожної людини, який зв'язав свою професійну діяльність з тестуванням програмного забезпечення:
Потрібно прагнути до розуміння того, що кожна нова інформація, кожна нова думка – це частинка досвіду і знань, які тестувальник застосовує у своїй професійній сфері діяльності. Тому варто бути уважним до всього і дізнаватися щось нове кожен день. Краще скласти список або розподіл ресурсів і дій (можливо нових навичок та умінь), якими ви оволодієте в найближчому майбутньому.
Наприклад:
У той час як технічні навички та вміння QA повинні бути на високому рівні, не варто забувати і про професійні навички спілкування з інженерами і розробниками. Ці здібності, які часто не беруть до уваги фахівці з QA-тестування і HR-менеджери, можуть підняти звичайну команду на більш високий рівень або навпаки, зробити роботу з іншими кваліфікованими і досвідченими професіоналами справжнім жахом.
Отже, які ключові навички спілкування в сфері тестування потрібно розвинути, якщо хочете залишитися в QA і брати участь в будь-якій співбесіді? Ось короткий список найбільш недооцінених навичок в професії QA.
У світі QA немає двох однакових проєктів, тому незалежно від того, скільки разів ви стикалися з новими проєктами, завжди краще починати з наступних запитань:
Як цей додаток буде використовуватися?
Хто кінцеві клієнти?
Який піковий час використання?
Які найбільш поширені конфігурації браузера/апаратного забезпечення/ОС?
Якщо не почати з цих фундаментальних питань, ваші зусилля щодо забезпечення якості, ймовірно, приведуть до більшого ризику в додатку. Здатність ставити правильні запитання, знати, коли залишати свої запитання відкритими, а коли заглиблюватися в деталі, – це навички спілкування, необхідні для будь-кого в QA.
У всіх нас є думки, і нам всім подобається говорити. Навіть перш, ніж інша людина закінчить говорити, ми часто втручаємося, щоб запропонувати рішення. Вони можуть бути актуальними і добре продуманими, але вони не завжди вітаються.
Слухання – це навичка, і за всю кар'єру зустрічається не так багато людей, які слухають без перерви і дійсно чують те, що намагається сказати інша людина. Правильно почута і сприйнята інформація сприяє швидкому вирішенню проблем.
Як менеджеру QA або тестувальників, який відповідає за окремо взяте завдання, потрібно вміти перетворити QA-спіч в корисне і доступне до розуміння повідомлення. Воно повинно містити в собі інформацію про те, які завдання були вирішені і чи відповідають вони поставленим вимогам. Наприклад, замість презентації на 30 слайдів, де представлена повна діаграма перетворення дефектів, краще показати один слайд, в якому йдеться про бізнес-ризики, терміни і так далі. Так буде зроблена не тільки заява мовою, зрозумілою власнику проєкту або менеджеру проєкту, але й зусилля і досягнення команди будуть оцінені набагато вище.
Навіть в Agile і DevOps, де розробники, системні адміністратори і тестувальники повинні працювати пліч-о-пліч, між різними функціями часто бувають невидимі кордони. Кращий спосіб подолати це – сприяти спілкуванню.
Міжособистісні навички членів вашої команди, та й вас зокрема, також необхідні для успіху. Людина, яка ладнає з іншими, важлива для вашої команди і вас. Із такими людьми дуже легко налагодити комунікаційні процеси. Спілкуючись безпосередньо з розробником і запитавши, що він думав, коли писав певний фрагмент коду, можна отримати більш глибоке уявлення про програму, ніж годинами вивчаючи безліч документації і витрачаючи години на наради.
Протягом багатьох років значна кількість негативу протікає в сторону QA. Ми говоримо про те, коли зацікавлені сторони бізнесу роблять сильний тиск на кінцевий термін для команд QA, що підживлюється нескінченним цькуванням з боку розробників. Все це причина одного з найважливіших чинників: не завжди QA може постояти за себе в певних ситуаціях, коли мова йде про терміни проєкту, вічні релізи і дуже великий тиск з боку менеджерів проєкту та інших команд. Тестування – останній крок в процесі розробки, тоді як QA проходить через нього. Слід бути стійким у своїй позиції, відстоювати свої рішення і підкріплювати затвердження реальними фактами та аргументами. Варто уникати такої проблеми як пінг-понг QA (QA ping-pong), який означає, що один і той же тікет кілька разів маніпулюється QA і розробниками. Це може мати різні причини:
Перш ніж оголосити статус дефекту як невдалий і передати його розробнику, варто перевірити впливає ця проблема на подальші варіанти використання чи ні. Якщо ні, то можна продовжувати тестувати, щоб якомога раніше виявити більше помилок.
Кожен QA-інженер підбирає той набір інструментів в тестуванні, який буде пов'язаний безпосередньо зі специфікою роботи проєкту, з яким він працює в даний момент. Знання основних інструментів в тестуванні повинно стати базою для розвитку нових умінь і навичок початківця QA.
Ось невеликий список популярних інструментів, які застосовуються на різних етапах тестування:
Інструменти функціонального тестування:
Інструменти навантажувального тестування:
Інструменти управління тестуванням, а також системи відслідковування дефектів:
Вибір відповідного комплекту інструментів в тестуванні – це запорука успіху всього тестування. Також, знання різних інструментів і середовищ розробки дає швидку інтеграцію в процесі тестування і розробки програмного продукту.
Оскільки вичерпне тестування неможливе, методи тестування допомагають скоротити кількість тестових випадків, які необхідно виконати, збільшивши при цьому охоплення ПЗ тестами. Вони допомагають визначити умови випробувань, які в іншому випадку важко розпізнати. Існує 5 основних і часто застосовуваних методів, про які зобов'язаний знати кожен QA:
А тепер коротко про кожен із них:
Аналіз граничних значень (Boundary Value Analysis – BVA)
Якщо вхідну умову обмежено між значеннями x і y, тоді тестові випадки повинні бути розроблені з цими значеннями, а також зі значеннями, які вище і нижче x і y.
Класи еквівалентності (Equivalence class partitioning – ECP)
Еквівалентне розбиття на класи дозволяє розділити набір тестових умов на розділи, які слід вважати однаковими. Цей метод тестування програмного забезпечення ділить вхідну область програми на класи даних, з яких повинні бути розроблені контрольні приклади.
Тестування на основі таблиці рішень (Decision Table Based Testing – DTBT)
Таблиця рішень також називається таблицею причин і наслідків. Цей метод тестування програмного забезпечення використовується для функцій, які реагують на комбінацію вхідних даних або подій. Наприклад, кнопка «Надіслати» повинна бути активною, якщо користувач заповнив усі необхідні поля.
Тестування різних станів додатку (State Transition)
У цьому методі зміни вхідних умов змінюють стан тестованої програми. Ця методика тестування дозволяє тестувальнику перевірити поведінку. Він може виконати цю дію, ввівши різні умови введення в послідовності. У методі переходу між станами груп тестування надає позитивні і негативні вхідні значення тесту для оцінки поведінки системи.
Передбачення можливих помилок (Error Guessing)
Цей метод тестування програмного забезпечення заснований на вгадуванні помилки, яка може превалювати в коді. У цьому методі аналітик-тестувальник використовує свій досвід, досвід інших фахівців в даній сфері, щоб вгадати проблемну частину тестової програми. Техніка підраховує список можливих помилок або схильних до помилок ситуацій. Потім тестувальник пише тестовий приклад для виявлення цих помилок.
Методи тестування програмного забезпечення дозволяють розробляти кращі варіанти. Кожен початківець QA повинен освоїти всі методи із «золотої п'ятірки».
З огляду на нагальну потребу в дотриманні термінів розробки та готовності програмного продукту, тестувальники повинні вивчити методологію Agile & DevOps, оскільки вона підтримує спільні та ітеративні робочі моделі. У той час як методологія Agile допомагає зменшити витрати на використання часових ресурсів на тестовому проєкті, DevOps допомагає в міжфункціональній командній роботі, починаючи з розробки, аналізу та забезпечення якості, що дозволяє отримати високоякісний кінцевий продукт при більш швидкому виході на ринок.
Вивчення цих методологій усуває складність розуміння ролі кожного з учасників процесу розробки та тестування, дозволяючи командам приділяти пильну увагу поетапній розробці і постійним випускам нових релізів.
Дані принципи і основи – це актуальне вдосконалення взаємодії різних функціональних робочих груп в розрізі стислих термінів розробки та готовності програмного продукту.
Концепція життєвого циклу розробки систем застосовується до ряду конфігурацій апаратного і програмного забезпечення, оскільки система може складатися тільки з апаратного забезпечення, програмного забезпечення або їх комбінації. Цей цикл зазвичай складається з шести етапів: аналіз, проєктування, розробка і тестування, впровадження, документування та оцінка. Забезпечення якості відіграє важливу роль на кожному етапі SDLC, QA-фахівець повинен розуміти значення його впливу на кожен з етапів. Для початківців тестувальників одним із найважливіших ступенів до розуміння процесів в тестуванні є освоєння знань життєвого циклу розробки програмного забезпечення, розуміння своєї ролі на кожному етапі.
Якщо QA вводиться на кожному етапі SDLC, це дозволяє компанії перевіряти точність кожного окремого модуля програми. Цей метод допомагає виявити критичні дефекти в ПЗ на самому початковому етапі. Додаток має бути запрограмований таким чином, щоб він міг безперешкодно працювати в будь-якій ситуації. Якщо якість програми надзвичайно висока, вона може добре працювати при різних обставинах. Виконання операцій QA на кожному етапі SDLC через регулярні проміжки часу допомагає поліпшити функціональність, надійність, продуктивність та інші важливі атрибути якості додатку. Що ще більш важливо, компанії, які залежать від веб-додатків, не хочуть мати справу з такими проблемами, як час простою додатку, випадки, коли він не відповідає потребам, робить негативний вплив на клієнтів, має серйозні помилки або інші проблеми. Компанії, що надають послуги, повинні враховувати одну річ при розгляді QA, а саме, що тестування має проводитися не тільки для виявлення помилок в додатку, але і для оцінки компетентності додатку і цілі, для якої його було створено.
Тестування повинне бути ретельно сплановано і проведено по всьому SDLC для досягнення найкращих результатів, що в кінцевому підсумку допоможе зберегти вартість виправлення помилок на дуже низькому рівні. Але якщо QA НЕ буде розгорнуто під час SDLC і введено в кінці циклу, вартість виправлення помилок буде дуже висока, а іноді це може спричинити за собою непереборні витрати. Тестування програмного забезпечення не тільки грає важливу роль в SDLC для відповідності стандартам додатку, але також відбивається на репутації організації.
Одним з головних принципів для QA в знайомстві з програмним продуктом і його вивченні, є розуміння того, на якому етапі розробки знаходиться QA в даний момент.
QA-інженер – це фахівець в різних областях і сферах IT, який повинен удосконалювати свої навички кожен день, кожну годину, кожну хвилину. Наведені вище пункти не є вичерпними, адже в сфері IT неможливо дістатися до досконалості в якійсь галузі, доведеться вчитися все життя. Але ці п'ять пунктів будуть гарним стартом для тестувальника-початківця.
