Що таке тестування у чому його суть

Що таке тестування і як воно влаштоване

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

Навіщо тестувати програми

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

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

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

Як проходить тестування ПЗ

Суть процесу порівняно реального поведінки програми з очікуваним. Розробник або тестувальник вводить дані в різних комбінаціях та форматах та перевіряє, чи відповідає результат очікуванням.

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

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

Тестування – це складно?

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

Типові помилки під час тестування

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

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

Типи тестування

Функціональне та нефункціональне

Завдання функціонального тестування – перевірити коректність роботи всіх функцій у програмі та оцінити код на відповідність вимогам та специфікаціям.

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

Чи може користувач ввести свої логін та пароль
Чи правильно система визначає допустимі та неприпустимі спроби входу на сайт
Чи правильну сторінку бачить користувач у разі вдалої чи невдалої спроби входу на сайт
Чи може користувач вийти із системи.

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

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

Функціональне та нефункціональне тестування допомагають оцінити програму з різних сторін і, за умови дотримання умов перевірки, гарантувати, що вона відповідає і функціональним вимогам, і стандартам продуктивності.

Статичне та динамічне

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

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

Інші види тестування

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

Що тестують на різних етапах розробки

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

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

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

Приймальне тестування. Завершальний етап, що проводиться замовником програми. Його мета – перевірити, що система відповідає вимогам та очікуванням.

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

Як проходить тестування

Тестування, як і будь-який інший процес у розробці, проходить у кілька етапів. Ось основні з них:

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

Принципи успішного тестування

Ось кілька принципів, які допоможуть зробити тестування ефективнішим:

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

Висновок

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

Що таке випробування?

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

Більшість джерел, відповідаючи питанням «Що таке тестування?» трактують його так:

Тестування - Це процес пошуку помилок у програмному продукті.
Тестування - Це перевірка додатка на відповідність вимогам.
і т.д.
Всі ці визначення невірні. Вони відображають лише одну мету тестування.

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

У тестуванні є 3 цілі:

Верифікація (Verification)
Валідація (Validation)
Пошук помилок (Error detection)

Нагадаємо двома словами:

Верифікація — Доведене об'єктивними результатами дослідження підтвердження того, що певні вимоги було виконано.

Валідація — Доведене об'єктивними результатами дослідження підтвердження того, що вимоги до очікуваного конкретного використання програми були виконані

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

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

Тому правильне визначення тестування відповідно до ISTQB звучатиме так:

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

Це, звичайно, правильно, але щось дуже «багато букв».
Я волію говорити набагато коротше:

Тестування — це верифікація, валідація та пошук помилок.

Автор: Клер Реклесс (Claire Reckless)

Якби вам довелося відповісти на запитання "Що таке тестування?", що ви сказали б? Це поняття досить важко впхнути в пару-трійку коротких речень.

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

З чого складається тестування

Розслідування

Розслідування визначається як "спостереження або вивчення шляхом близького спостереження та систематичного вивчення" [1].

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

Дослідження

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

Дослідницьке тестування визначається як одночасне навчання, тест-дизайн та прогін тестів [2]. Тестувальник досліджує додаток, дізнається нову інформацію, навчається, знаходить щось нове для тестування по ходу справи. Він може займатися цим поодинці або парі з іншим тестувальником (а може, і розробником).

Тестування не повинно сприйматися як прогін списку готових тестів або тест-кейсів, що дають твердий "pass/fail' результат. Якщо у вас є юзер-сторі або набір вимог, звичайно, важливо мати їх на увазі. Однак критерії приймання буває корисно переформулювати як "Критерії відмови". Коли критерії приймання не задоволені, продукт не прийнятий, але якщо вони в порядку, це не означає, що в програмному забезпеченні немає багів.

Перевірки та верифікація повинні поєднуватися з дослідженням та розслідуванням, а також питаннями в дусі "Що буде, якщо…", на які ви можете не знати відповіді, поки не спробуєте, та відповіді на які не покриті готовими кейсами.

Зниження ризиків

Одна з причин, з якої ми тестуємо, – пошук дефектів, ризиків та іншої інформації про продукт, яка дозволяє нам діяти, щоб кінцевий користувач не постраждав. Ми можемо:

Виправляти баги.
Переоцінити та змінити початкові вимоги.
Допомогти користувачеві продукту.
Створити документацію користувача.
Донести інформацію про проблеми до зацікавлених осіб.

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

Цінність

Тестування – це цінна частина розробки ПЗ, але його часто недооцінюють через його непередбачувану та креативну природу.

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

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

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

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

Ідеї
Вимоги
Дизайн
Припущення
Документацію
Інфраструктуру
Процеси.

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

Комунікація

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

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

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

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

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

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

Потенційна нескінченність

По суті, ми завжди тестуємо лише вибірку. Кожен нетривіальний продукт має непредставну кількість параметрів з великою кількістю можливих значень. Звідки знаєте, що тестуєте важливі значення? Ми не можемо протестувати все.

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

З чого тестування не складається

Простота

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

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

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

Автоматизованість

"Ручні випробувачі нам більше не потрібні - ми можемо автоматизувати все!" Всі ми бачили ті чи інші варіації цієї фрази у Твіттері, на форумах та у статтях. Тестування – це дослідницька, детективна діяльність, її неможливо замінити автоматизованими перевірками. p align="justify"> Комп'ютер технічно не здатний досліджувати продукт так, як це робить людина.

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

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

Підвищення якості

Тестувальники не роблять нічого, щоб безпосередньо покращувала якість продукту. Проганяючи тест, ми не впливаємо на код – отже, якість ПЗ залишається незмінною. Тільки після того, як розробники виправляють баги, якість може змінитися. Ми не можемо "втестувати" якість продукту.

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

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

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

Фіксована діяльність, що не вимагає уяви, підпорядковується суворим правилам

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

Не існує кращих практик тестування, які застосовуються в будь-яких проектах. Ви повинні з'ясувати, що найкраще працює у вашому контексті та у вашій області.

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

Життєво необхідно для успіху продукту

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

Ніколи не закінчується

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

Частина роботи тестувальника – це прийняття рішень, що саме тестувати, та розуміння наслідків цих рішень та пов'язаних з ними ризиків.

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

Тестування – це багато, багато іншого

Я перерахувала лише деякі аспекти того, що таке тестування. Ця стаття могла б бути значно довшою! Немає єдиного визначення, що мається на увазі під тестуванням, а впхнути в одну пропозицію все те, чим займаються тестувальники просто неможливо! Якщо пошукати визначення тестування в Інтернеті, можна натрапити на фрази на кшталт "пошук багів у додатках" – але, як ми вже з'ясували, це не тільки не стільки пошук багів.

Посилання: