Тестування програмного забезпечення – це неймовірно складна та інтенсивна сфера, в якій компанії та незалежні розробники прагнуть вдосконалити свої продукти за допомогою різноманітних методів тестування.
Одним з найпоширеніших методів, які компанії використовують для тестування, є тестування “чорного ящика” – техніка, яка створює дистанцію між розробниками та тестувальниками для отримання точних результатів та усунення упередженості.
Дізнайтеся більше про те, що таке тестування “чорного ящика”, як провести тестування “чорного ящика”, а також про деякі переваги впровадження тестування “чорного ящика” в розробці програмного забезпечення з цього детального посібника.
Що таке тестування чорних скриньок?
Тестування “чорної скриньки” – це процес тестування системи або програмного забезпечення без попереднього знання того, як вона працює зсередини. Це стосується не лише незнання самого вихідного коду, але й того, що ви не бачили жодної проектної документації, пов’язаної з програмним забезпеченням. Тестувальники просто надають вхідні дані та отримують вихідні дані, як це робив би кінцевий користувач. Хоча це просте визначення тестування “чорної скриньки”, воно описує загальну систему.
Мета тестування “чорного ящика” полягає в тому, щоб змусити користувачів взаємодіяти з програмним забезпеченням у більш природний спосіб, ніж зазвичай, не маючи жодних упереджень, які випливають з того, що вони вже знають про програмне забезпечення.
У цій методології люди, відповідальні за виконання тестів, відрізняються від тих, хто розробляв програмне забезпечення, що створює поділ між цими двома командами.
1. Коли і чому потрібно проводити тестування “чорного ящика” при тестуванні програмного забезпечення?
У циклі розробки є кілька етапів, на яких тестування за допомогою “чорного ящика” є ідеальним, причому більшість тестувань за допомогою “чорного ящика” відбувається наприкінці розробки, незадовго до релізу.
Це включає в себе такі методи, як тестування прийнятності для користувачів, під час якого програмне забезпечення передається членам цільової аудиторії як форма тестування перед випуском. Це більш відоме як бета-тестування і є ідеальним інструментом для компанії, оскільки більший вплив означає, що люди з більшою ймовірністю знайдуть потенційні помилки в програмному забезпеченні.
Робота з методологією “чорної скриньки” наприкінці циклу розробки є обов’язковою, оскільки саме до цієї версії користувач має найбільше шансів отримати доступ. Ви можете використовувати тестування “чорного ящика” для окремих функцій, але це суперечитиме меті тестування.
2. Коли не потрібно проводити тестування “чорних скриньок
На ранніх стадіях розробки тестування “чорного ящика” має дуже мало сенсу. Коли компанія створює базову функціональність свого програмного забезпечення, вона використовує тестування білого ящика, щоб розробник міг бачити, в якому місці коду виникають проблеми.
Також немає потреби в тестуванні “чорної скриньки”, коли програмне забезпечення є відкритим кодом або відносно простим веб-інструментом, або призначене для допомоги в проектах кодування третіх осіб, оскільки існує відносно голий користувальницький інтерфейс, і користувач може отримати доступ до вихідного коду програми в будь-якому випадку. Якщо ви очікуєте, що користувач отримає доступ до вихідного коду, тестування чорних скриньок втрачає свою основну мету.
3. Хто бере участь у тестуванні “чорних скриньок”?
Існує багато ролей, пов’язаних з процесом тестування “чорних скриньок”, деякі з них залежать від характеру компанії, що проводить тестування.
До важливих ролей, пов’язаних із залученням до процесу тестування “чорних скриньок”, відносяться наступні:
– Тестер
Тестувальник відповідає за виконання ручних тестових кейсів у компанії, написання ретельних тестових кейсів, які детально досліджують додаток, перш ніж виконувати їх і звітувати про результати. Ця роль існує в основному в ручному процесі тестування, а автоматизовані системи виконують цю роль там, де є автоматизація тестування.
– QA Analyst
QA-аналітик відповідає за програмування тестових кейсів у процесі QA, в першу чергу, коли компанія використовує процес автоматизації QA-тестування.
Процес включає в себе як розробку ретельних тестових кейсів, що забезпечують високий рівень функціональності, так і виконання тестових кейсів з отриманням результатів після завершення.
– Розробник
Особа, відповідальна за розробку програмного забезпечення, яке тестує команда QA. Розробник отримує зворотній зв’язок від команди тестувальників і відповідно оновлює програмне забезпечення, працюючи як частина команди розробників, але перебуваючи в постійному зв’язку з тестувальниками.
– QA Manager
QA-менеджер є лідером команди забезпечення якості і відповідає за управління всіма завданнями, які виконують тестувальники.
Це включає в себе організацію графіку тестування, складання списку справ для співробітників і вирішення будь-яких конфліктів у команді. Вони також пояснюють, що таке тестування “чорних скриньок” під час тренінгів для нових працівників.
– Керівник проекту
Особа, відповідальна за якість кінцевого проекту, керівник проекту, контролює процес тестування, а також розробку, гарантуючи, що клієнт отримає програмний пакет, який відповідає всьому брифу.
Переваги тестування чорних скриньок
Використання тестування чорного ящика у вашій роботі над розробкою має кілька суттєвих переваг. Чим більше ви знаєте про ці переваги, тим більше ви можете їх використати, отримавши якомога більше переваг від техніки.
Деякі з основних переваг використання тестування за допомогою “чорної скриньки” у забезпеченні якості включають в себе наступні:
1. Немає потреби в технічних знаннях
Підхід “чорної скриньки” означає, що вам не потрібні технічні знання під час розгляду заявки.
Мета тестування “чорного ящика” – перевірити, як додаток працює для кінцевого користувача, а звичайний користувач у більшості ситуацій не має жодних просунутих технічних знань. Це може знизити вартість тестування, допомагаючи організації виявляти більше помилок за менші кошти, стаючи більш фінансово ефективною.
2. Точно змоделюйте користувача
Кінцева мета процесу тестування “чорної скриньки” – зрозуміти, які проблеми виникають з додатком, коли користувач взаємодіє з ним на щоденній основі.
Деякі види тестування “чорного ящика”, які зосереджені на відтворенні поведінки користувача, моделюють його поведінку з високим ступенем точності. Особливо це стосується тестування прийнятності для користувача, в якому кінцеві користувачі відчувають продукт, не просто моделюючи або імітуючи поведінку користувача, а фактично впроваджуючи його.
Точне моделювання допомагає виявити будь-які помилки, які впливають на реальні робочі процеси користувача.
3. Можливість краудсорсингу тестування
Тестування за допомогою “чорної скриньки” є дуже доступною формою тестування завдяки відносно низьким вимогам до кваліфікації.
Це означає, що компанії можуть не тільки наймати тестувальників з нижчим рівнем технічних навичок, але й використовувати краудсорсинг для тестування завзятих клієнтів. Це стає все більш поширеним явищем в ігровій індустрії, коли компанії пропонують реліз раннього доступу, оновлюючи гру з часом, щоб вирішити проблеми, які виявляють користувачі.
Знайти баги в цьому випадку набагато простіше, оскільки всі функції отримують набагато вищий рівень впливу.
Проблеми тестування “чорних скриньок
Окрім переваг тестування за допомогою “чорної скриньки”, є кілька основних проблем, які вам потрібно буде врахувати. Усвідомлення цих викликів означає, що ви можете адаптуватися до них, підвищуючи рівень вашого тестування, зменшуючи шкідливі наслідки, які може мати тестування “чорної скриньки”.
Деякі з цих викликів включають
1. Важко знайти причини проблеми
Одним з основних недоліків тестування за допомогою “чорного ящика” є те, що може бути складніше знайти причину проблем, коли тестувальники не мають доступу до вихідного коду.
Хоча вони можуть описати, що це за помилка і коли вона виникає, вони не можуть вказати, яка частина вихідного коду викликає проблеми і чому.
Тестувальники можуть дещо пом’якшити цю проблему, якщо будуть ретельно вести нотатки, а детальні повідомлення про помилки від розробника також дадуть додаткову інформацію для будь-яких майбутніх оновлень.
2. З автоматизацією складніше
Оскільки ви активно намагаєтеся відтворити спосіб взаємодії користувача з програмним пакетом, може бути надзвичайно складно автоматизувати процес тестування “чорної скриньки”.
Першою причиною цього є той факт, що тестувальник не має доступу до вихідного коду, що ускладнює написання точного тестового кейсу. Це поєднується з тим фактом, що тестування розроблено так, щоб максимально відтворити людську поведінку, а автоматизація спеціально розроблена так, щоб діяти роботизовано.
Ви можете збалансувати цю проблему, автоматизувавши більше рутинних завдань і поєднуючи автоматизацію з ручним тестуванням, де це можливо.
3. Проблеми з масштабним тестуванням
Вищезгадані проблеми з автоматизацією означають, що тестування у великих масштабах є більш складним. Масштабне тестування надає компаніям набагато більше даних про програмне забезпечення, а це означає, що помилки легше знайти і відтворити.
Пріоритетність ручного тестування означає, що може бути складніше організувати тестування у великих масштабах. Деякі компанії протидіють цьому, використовуючи систему “відкритої бета-версії”, в якій кожен, хто зацікавлений у продукті, може допомогти з тестуванням перед випуском і підтримати компанію, надаючи відгуки про ранні збірки на добровільних засадах.
Характеристики тестів “чорної скриньки
Існує кілька основних характеристик тестів “чорного ящика”, які відрізняють тестування від будь-якої іншої форми забезпечення якості програмного забезпечення.
Ці характеристики включають в себе:
1. Відсутність попередніх внутрішніх знань
Тести “чорної скриньки” не вимагають попередніх внутрішніх знань про програмне забезпечення. У деяких випадках це може бути складно, оскільки тестувальники мають певне уявлення про аспекти програмного забезпечення, яке вони тестують, і деякі функції, які вони шукають, але в широкому розумінні це означає, що вони не можуть бачити внутрішню документацію будь-якого типу.
Простіше кажучи, якщо інформація буде видима кінцевому користувачеві в магазині додатків або на сторінці завантаження веб-сайту, то тестувальник зможе її побачити.
2. Окремі тестувальники та розробники
Етапи тестування та розробки виконуються різними людьми в умовах тестування “чорного ящика”. Ця диференціація відбувається через брак знань у тестувальників, оскільки розробники знають вихідний код через те, що саме вони відповідальні за його розробку.
Компанії підходять до цього по-різному, залежно від конкретної ситуації: деякі з них звертаються до зовнішніх організацій для проведення тестування, а великі компанії мають спеціальні відділи тестувальників, які виконують цю роботу.
3. Тестування на пізніх стадіях
Це стосується етапу розробки, на якому відбувається тестування. Тести “чорних скриньок” спираються на відносно просунуту версію існуючої програми з комплексним інтерфейсом користувача, який забезпечує повну навігацію по програмному забезпеченню і доступ до інтерфейсу кожної функції.
Це означає, що тести “чорного ящика” можливі лише на деяких пізніх стадіях процесу тестування, коли все це вже розроблено. Хоча інтерфейс і елементи керування можуть змінюватися з часом, вони повинні існувати в тій чи іншій формі, щоб дозволити тестам чорного ящика отримати доступ до функціоналу.
Що ми перевіряємо в тестах “чорного ящика
Тестування “чорної скриньки” досліджує конкретні аспекти програмного пакету, надаючи додаткову інформацію в деяких областях програмного забезпечення, що призводить до оновлень, які підвищують загальну якість життя.
Деякі з основних частин програмного пакету, які тестувальники перевіряють під час тестування “чорного ящика”, включають в себе:
1. Функціональність
Деякі розробники використовують тестування “чорного ящика” як засіб гарантування того, що програмне забезпечення працює так, як задумано, для когось, хто не володіє відповідними знаннями.
Переважна більшість людей, які використовують будь-яке програмне забезпечення в комерційних цілях, роблять це, не маючи жодного уявлення про внутрішню роботу програмного забезпечення, тому тестування з такими знаннями означає, що ви знаєте обхідні шляхи для будь-яких існуючих проблем.
Таке ретельне тестування функціональності гарантує, що кожен користувач отримає найкраще з того, що може запропонувати додаток, а не зіткнеться з помилками, невидимими при тестуванні за допомогою білого ящика.
2. Інтерфейс користувача
Інтерфейс користувача відноситься до всіх способів, якими користувач практично взаємодіє з додатком, щоб змусити його виконати ряд завдань. Це включає в себе меню, з якими працює користувач, конкретні кнопки, які присутні в додатку, і брендинг, який існує у всьому програмному забезпеченні.
Розробники витрачають більшу частину свого часу на те, щоб переконатися, що сам додаток працює так, як вони очікують, а це означає, що користувацькому інтерфейсу приділяється менше уваги.
Тестування “чорного ящика” надає тестувальникам лише користувацькі функції програмного забезпечення, приділяючи більше уваги користувацькому інтерфейсу, ніж на більшості інших етапів тестування.
3. Перформанс
Окрім нормального функціонування та гарного вигляду, спосіб, у який додаток працює, має важливе значення для того, щоб задовольнити клієнтів.
Продуктивність – це кілька факторів, включаючи швидкість реакції програми на введення даних користувачем і ресурси, які вона використовує на конкретному пристрої.
Завдяки таким форматам тестування, як наскрізне тестування, що вивчає всі функції програмного забезпечення, розробники можуть бачити, скільки пам’яті використовує додаток і які з функцій створюють найбільше навантаження на відповідні пристрої, що дає змогу керувати ефективністю та оновленнями, пов’язаними з продуктивністю, у наступних версіях програми.
Проясняю деяку плутанину:
Тестування “чорної скриньки” проти “білої скриньки” та “сірої скриньки
Тестування “чорної скриньки” – це концепція, яка звучить подібно до тестування “сірої скриньки” та “білої скриньки”, але за своєю суттю вони суттєво відрізняються одна від одної. Їх плутанина може спричинити серйозні проблеми з комунікацією в процесі розробки, сповільнити процес оновлення та зробити його менш ефективним.
Читайте далі, щоб прояснити деякі плутанину навколо різних типів “коробкового тестування”, чим вони відрізняються один від одного і коли слід використовувати кожен з них.
1. Що таке тестування “білої скриньки”?
Тестування “білої скриньки” іноді називають “тестуванням у скляній скриньці”, і це означає процес тестування, коли тестувальник має повний доступ до всієї інформації, що лежить в основі програмного забезпечення. Це включає доступ до вихідного коду та проектної документації, а також до клієнтського брифу пакета.
Наприклад, якщо тестувальник працює на ранніх стадіях процесу розробки, перевіряючи одну функцію, можливість бачити вихідний код цієї функції означає, що він може негайно знайти причину проблеми.
Один з найкращих моментів для використання тестування “білого ящика” – це переважно внутрішні завдання. Це стосується ранньої розробки функціональної частини додатку, причому ідеальним варіантом є швидке виправлення помилок, оскільки немає сенсу заплутувати код, коли ви не імітуєте користувацький досвід. Тестування білого коду також використовується в системах з відкритим вихідним кодом, оскільки в цих випадках вихідний код доступний для всіх користувачів.
Які відмінності між тестуванням білого та чорного ящиків?
Основна функціональна відмінність між тестуванням “чорного ящика” і тестуванням “білого ящика” полягає в рівні доступу тестувальника до програмного забезпечення, але це має набагато більш суттєвий вплив на такі аспекти тестування, як час проведення.
Тестування “чорних скриньок” більш послідовно використовується на пізніших етапах процесу, коли продукт наближається до запуску, а на базових етапах розробки прозорість і оперативність тестування “білих скриньок” є перевагою. Якщо розглядати тестування “чорного ящика” та “білого ящика”, то вони також відрізняються за рівнем необхідної експертизи, оскільки тестування “білого ящика” вимагає досвіду в кодуванні та розробці, щоб бути більш ефективним.
2. Що таке тестування “сірої скриньки”?
Тестування в сірій скри ньці – це форма тестування, в якій користувач має певне розуміння коду, але не має повного доступу до нього. Це передбачає наявність вихідного коду функції, яка тестується, або доступ до частини проектної документації, щоб користувач розумів загальну мету програмного пакету.
Наприклад, якщо тестувальник перевіряє лише одну з функцій програмного пакету, йому може бути надано доступ до вихідного коду цієї частини програми.
Компанії переважно використовують тестування сірої скриньки, коли перевіряють, як додаток інтегрується зі стороннім інструментом. Вони можуть мати доступ до вихідного коду лише для однієї частини процесу, що обмежує їхню здатність проводити ретельне тестування “білої скриньки”. Натомість вони бачать вхідні та вихідні дані сторонньої інтеграції, а також вихідний код, який відповідає за інтеграцію.
Тестувальники використовують його, щоб оцінити, чи виникають проблеми через програмне забезпечення, сторонні додатки або інтеграцію між ними.
Які відмінності між тестуванням “чорної скриньки” та “сірої скриньки”?
Основна відмінність між тестуванням “чорної скриньки” та “сірої скриньки” знову ж таки полягає в рівні доступу до інформації, причому тип програмного забезпечення, що тестується, є одним з основних факторів, що розрізняють типи тестування.
Тестування “сірих скриньок”, як правило, включає сторонні інструменти, такі як хмарні сховища даних або зовнішні засоби обробки, в той час як системи “чорних скриньок”, як правило, є єдиним цілісним блоком. Багато тестів “чорної скриньки” безперервно проводяться третіми сторонами, в той час як інтегровані додатки не мають іншого вибору, окрім як працювати за методологією тестування “сірої скриньки”.
3. Висновок: Тестування “чорної скриньки” проти “білої скриньки” та “сірої скриньки
Зрештою, існують фундаментальні відмінності між тестуванням у “чорному”, “сірому” та “білому” ящиках, які залежать від того, чи надається команді тестувальників інформація за лаштунками.
Тестування “чорного ящика” та “білого ящика” є крайніми точками цього спектру, а тестування “сірого ящика” охоплює все, від вільного доступу до всього, окрім стороннього вихідного коду, до можливості бачити лише код, що стоїть за певною функцією.
Всі ці методи тестування відіграють важливу роль у сфері тестування програмного забезпечення, тому необхідно приділити час і увагу їх вивченню та ефективному застосуванню.
Типи тестів “чорної скриньки
Існує три основні типи тестування “чорної скриньки”, які охоплюють усі види тестування, що проводяться компанією за допомогою методології “чорної скриньки”. Це вони:
1. Функціональне тестування
Функціональне тестування охоплює все, що стосується механічної роботи програми. Це передбачає забезпечення правильної обробки даних, надання користувачам можливості входу з правильними обліковими даними, а також обробку інформації та вхідних даних відповідно до очікувань.
Тестування функціональності є одним з найважливіших аспектів процесу і включає в себе як локальну функціональність програми, так і те, як вона взаємодіє із зовнішніми інструментами і програмами, такими як хмарні сервіси або інструменти єдиного входу.
2. Нефункціональне тестування
Нефункціональне тестування – це тестування, яке досліджує будь-який аспект програмного забезпечення, який не має прямого відношення до функціональності програми. Це передбачає встановлення того, чи є додаток зручним і зрозумілим для користувачів, сумісним з широким спектром пристроїв і операційних систем, а також того, як він працює при значних рівнях навантаження (хоча в деяких випадках це може переходити в функціональне тестування).
Це відбувається переважно наприкінці процесу розробки, коли додаток повністю скомпільовано.
3. Регресійне тестування
Після оновлення тестувальники переглядають додаток, щоб переконатися, що він виконує заплановану функцію і не має небажаних побічних ефектів, які можуть призвести до регресу програми.
Це називається регресійним тестуванням і є фундаментальною частиною перевірки готовності додатку до виходу на ринок.
Регресійне тестування використовується після кожного оновлення, щоб переконатися, що як функціональні, так і нефункціональні аспекти програми відповідають стандарту, досягнутому раніше.
Методи тестування “чорних скриньок
Коли ви проходите процес тестування “чорної скриньки”, існує широкий спектр методів, які ви можете застосувати для покращення стандартів вашої роботи. Деякі з найбільш важливих методів тестування чорних скриньок, які ви використовуєте в середовищі забезпечення якості, включають в себе наступні:
1. Парне тестування
Парне тестування – це форма тестування, яка фокусується на перевірці кожної окремої комбінації вхідних даних, яка можлива в програмному забезпеченні.
Наприклад, якщо числа від одного до десяти є всіма допустимими записами в одному стовпчику, а всі символи алфавіту – в іншому, попарне тестування перевірить кожну можливу комбінацію від 1A до 10Z. Це форма тестування, яка може зайняти у користувача багато часу і зусиль, що робить його одним з методів, найбільш відкритих для потенційної гіперавтоматизації. Це надзвичайно ретельна перевірка, яка виявляє будь-які потенційні проблеми з введенням даних.
2. Аналіз граничних значень
Багато програмних продуктів покладаються на введення даних, причому ці дані мають певні межі, в яких, як очікується, повинен працювати клієнт.
Наприклад, система, призначена для обчислення чисел від 1 до 100, може не впоратися зі значеннями 0 або нижче, або вище 100.
Аналіз граничних значень передбачає тестування цих границь, введення чисел на границях і навколо границь, які тестує програма, щоб перевірити, чи є помилки на межі очікуваного робочого діапазону програмного пакету. Це насамперед корисно в системах, що базуються на обчисленнях, і може допомогти розробникам або скоригувати межі, або знайти причину будь-яких проблем.
3. Тестування державного переходу
Багато програм варіюються між різними “станами” або “режимами” і вимагають переходу від одного етапу цього процесу до іншого. Правильна робота цих переходів означає, що сайт функціонує так, як очікує користувач, і не відбувається ніяких несподіваних затримок.
Тестування переходів між станами – це форма тестування, яка досліджує всі переходи між станами в програмному забезпеченні, гарантуючи їх функціональність і забезпечуючи впевненість у тому, що користувач проходить через роботу програмного забезпечення без будь-яких непередбачуваних переривань.
Тестування чорних скриньок у життєвому циклі розробки програмного забезпечення
Тестування “чорної скриньки” – це дисципліна, яка в основному використовується наприкінці життєвого циклу розробки програмного забезпечення. Це включає в себе все – від тестування способу взаємодії користувачів з програмним забезпеченням до надання повного бета-доступу, причому тестування “чорного ящика” розпочинається, коли вся функціональність працює як очікувалося.
Це економить багато часу і зусиль у порівнянні з тестуванням за допомогою білого ящика, яке вимагає високого рівня знань, і найкраще застосовується тоді, коли вам не потрібна команда розробників, щоб негайно вносити зміни в роботу системи.
Ручне чи автоматизоване тестування відеореєстраторів?
Тестування програмного забезпечення буває двох різних форматів: ручне тестування є традиційною формою, яка передбачає використання тестувальників на кожному етапі процесу. Це суперечить автоматизованому тестуванню, яке використовує зростаючий рівень штучного інтелекту та машинного навчання для виконання завдань без будь-якого втручання людини.
Читайте далі, щоб дізнатися більше про те, що таке ручне та автоматизоване тестування, які виклики стоять перед кожним з них, і яке з них є ідеальним для компанії.
1. Ручне тестування “чорної скриньки” – переваги, виклики, процес
Ручне тестування “чорних скриньок” – це процес самостійного проведення тестування “чорних скриньок” із залученням співробітників для виконання всіх завдань, а не використання платформи автоматизації як частини інструментарію компанії.
Деякі з основних переваг використання ручного тестування при розробці програмного забезпечення полягають у тому, що ви маєте більшу гнучкість щодо способу завершення тестування, а також у тому, що розробники можуть отримати більш ретельний зворотній зв’язок, який є якісним за своєю природою.
Однак є кілька природних проблем, з якими стикається процес ручного тестування. Перша з них полягає в тому, що ручне тестування може зайняти багато часу, оскільки люди повільніше виконують свої завдання, ніж автоматизовані програми.
Інша причина – це більша ймовірність помилок, оскільки люди можуть помилитися або зробити щось у неправильному порядку. Це може в кінцевому підсумку призвести до неточностей у даних тестування.
Ручне тестування – це процес, який починається з вивчення очікувань компанії від додатку перед написанням тестових кейсів, які кидають виклик цьому брифу, виконанням тестових кейсів і звітуванням про результати команді розробників.
2. Автоматизація тестування чорних скриньок – переваги, виклики, процес
Автоматизовані тести – це тести, які компанія виконує на програмному пакеті, заповнюючи тестові кейси за допомогою автоматизованої системи. Вони використовують сторонні платформи для автоматизації програмного пакету, причому будь-які автоматизовані кроки виконуються за спеціально підготовленими тестовими кейсами.
Основна перевага автоматизації тестування чорних скриньок – це швидкість, оскільки автоматизовані програми займають набагато менше часу для кожного окремого запуску тесту. Це призводить до значного виграшу часу на тестування, який ви можете витратити на розробку програми.
Ще однією перевагою є точність, оскільки хороший інструмент автоматизації щоразу виконує ті самі завдання в тому самому порядку.
Недоліки все ще можуть створювати проблеми для автоматизації тестування чорних скриньок, і однією з головних проблем є зосередженість на кількісних даних. Це чудово підходить для метрик, але означає, що в тесті на прийнятність для користувача можна отримати мало цінної інформації.
Також спостерігається відносна відсутність гнучкості в автоматизованому тестуванні, коли аналітикам доводиться кодувати абсолютно нові тестові кейси щоразу, коли вони хочуть внести зміни.
Процес автоматизації тестування починається з розробки серії тестових кейсів, які потім кодуються в системі перед виконанням тестів, які надають звіт про завершення.
3. Висновок: Автоматизація тестування вручну чи через відеореєстратор?
Зрештою, вибір між ручним та автоматизованим тестуванням “чорних скриньок” є складним і залежить від того, що ви шукаєте в системі.
Якщо ви шукаєте високоякісну інформацію, яку можна використати для внесення змін у дизайн для кінцевого користувача, ручне тестування є найкращим варіантом, тоді як автоматизоване тестування ідеально підходить для функціональних та продуктивних етапів процесу.
Подумайте про те, що ви шукаєте на кожному етапі процесу тестування, і ви зможете легко отримати дані, які допоможуть вам підвищити продуктивність.
Що потрібно для початку тестування “чорних скриньок”?
Перед початком тестування чорного ящика необхідно виконати деякі передумови, кожна з яких допомагає створити більш послідовний процес тестування.
Ось деякі речі, які необхідно мати перед початком роботи над тестуванням чорних скриньок:
1. Вимоги до програмного забезпечення
Вимоги до програмного забезпечення стосуються конкретних пунктів у проектному завданні, які програмне забезпечення має виконати. Це може включати цілий ряд речей: від необхідності виконання певного набору завдань до певного вигляду та відчуття під час використання.
Маючи таку інформацію, ви отримуєте кілька конкретних цілей, до яких потрібно прагнути під час тестування, а тестувальники створюють графік і план тестування, що призводить до більш узгодженого набору результатів, які інформують розробників про проблеми з програмним забезпеченням.
У деяких компаніях, оскільки це тест “чорної скриньки”, розробники обмежують доступ тестувальника до брифу.
2. Скомпільоване програмне забезпечення
Перш ніж тестувати програмне забезпечення, команда забезпечення якості повинна мати доступ до нього. Зазвичай розробники надають найновішу версію програмного забезпечення, а команда отримує вигоду від того, що має повністю скомпільовану версію програмного забезпечення для проведення тестів.
Наявність останньої версії означає, що тести включають найновіші виправлення, а це означає, що вони дають точне уявлення про те, як працює програмне забезпечення.
3. Цілі тестування
Тестувальники, як правило, підходять до періоду тестування з певними конкретними цілями. Ці цілі тестування визначають, що саме тестуватимуть у найближчий період, чи то прийнятність для користувача, чи то наскрізну функціональність, чи то завершення тестування на проникнення.
Менеджери з контролю якості, як правило, мають такі цілі, а наступний етап тестування, як правило, залежить від того, над чим працювала команда розробників і на які частини програмного забезпечення ці розробки впливають.
Процес тестування “чорної скриньки
Процес тестування “чорних скриньок” є відносно точним, і компанії виграють, якщо будуть дотримуватися етапів процесу якомога точніше. Процес тестування “чорних скриньок” включає в себе різні етапи:
1. Планування тестування
Почніть процес тестування “чорного ящика” зі складного процесу планування. Це передбачає обговорення всіх індивідуальних цілей, які ви ставите перед тестом, специфічних аспектів програмного забезпечення, яке ви вивчаєте, і ресурсів, які ви виділяєте на тестування.
Більш ретельне планування означає, що кожен знає, що він повинен робити і коли він повинен це робити, включаючи методи, задіяні в тестуванні.
2. Написання тестових кейсів
Написання тестових кейсів – наступний етап процесу. Тестовий кейс – це серія кроків, які необхідно виконати в тесті, причому більш детальні тестові кейси забезпечують більший рівень узгодженості для користувача.
В автоматизованому процесі тестування це також передбачає кодування тестового кейсу в будь-якому інструменті автоматизації, який ви плануєте використовувати.
Перевірте всі ваші тестові кейси, щоб переконатися, що вони ретельні і чітко описують кроки, які потрібно виконати.
3. Виконання тестового кейсу
Після того, як ви підготували тестові кейси, починайте їх виконувати. При використанні автоматизації це може бути відносно простим завданням, яке включає в себе запуск програми і очікування результатів. Ручне тестування покладається на співробітників, які виконують тестові кейси багаторазово, причому більше повторень призводить до отримання більш послідовних і якісних даних.
Виконуйте кожен тестовий кейс якомога ретельніше, оскільки чим точніше ви виконуєте тестові кейси, тим більше шансів, що дані будуть корисними для команди розробників.
4. Підсумковий звіт
Етап фінального звітування відноситься до тієї частини процесу, коли команда тестувальників звітує перед розробниками.
Почніть з простого узагальнення зібраної інформації, а потім додайте до неї всі показники, які зібрали тестувальники. Це дає розробникам початкові вказівки щодо ідеального напрямку для наступної серії оновлень, перш ніж показувати їм повні дані, що дозволяє їм глибше зрозуміти проблеми.
Найкращі практики для тестування чорних скриньок
Незалежно від галузі, в якій ви працюєте, дотримання найкращих практик є обов’язковим для будь-якої компанії. Найкращі практики – це низка моделей поведінки та методів, які компанія отримує вигоду від використання у своїй щоденній роботі, підвищуючи ефективність компанії та покращуючи стандарти програмного забезпечення, яке вона використовує.
Деякі з цих практик, які допомагають компанії підвищити якість тестування “чорних скриньок”, включають в себе наступні:
1. Зосередьтеся на розвитку навичок
Якщо ви керуєте компанією, яка одночасно працює над кількома програмними продуктами, подумайте про те, щоб зосередитися на розвитку навичок і спеціалізацій тестування. Чим більше часу ви витрачаєте на спеціалізацію та розвиток відповідних навичок, тим більше у вас шансів викорінити будь-які проблеми, що існують у ваших продуктах.
Це поєднується з наймом людей, які мають відповідний набір навичок, але найбільше підходить для компаній, які майже постійно тестують програмне забезпечення, оскільки завжди є користь від застосування цих здібностей.
2. Збалансуйте робочі навантаження
Деякі команди тестування можуть бути дуже великими, з десятками, або навіть сотнями співробітників, які регулярно виконують тестові кейси.
Найкраща практика для отримання максимальної віддачі від цих співробітників – не поспішати і бути обережним, призначаючи людей на конкретні завдання. Вигорання має серйозні проблеми в індустрії розробки програмного забезпечення, але цього можна уникнути завдяки кращому управлінню робочим навантаженням.
3. Створити послідовні процеси
Компанії побудовані на процесах, які їхні співробітники виконують щодня, а процеси тестування включають те, як компанія пише тестові кейси, проводить дослідження та здійснює внутрішню комунікацію між відділами.
Послідовність у цих випадках є ключовим фактором, оскільки це означає, що люди швидше навчаються, коли приходять у компанію. Це призводить до швидшої адаптації та кращих результатів набагато швидше, ніж у компанії, яка не має узгодженості між своїми завданнями.
Якщо ви можете, створіть ці процеси таким чином, щоб залучити персонал до процесу прийняття рішень, оскільки це гарантує їхню згоду зі стратегією.
7 помилок та підводних каменів при впровадженні тестів “чорної скриньки
Помилки – це природно в будь-якій галузі, але знання про помилки до того, як у вас з’явиться можливість їх зробити, може заощадити вам багато часу і зусиль.
Деякі з найпоширеніших помилок і пасток, в які потрапляють тестувальники чорних скриньок, включають в себе наступні:
1. Відсутність визначеного обсягу тестування
Деякі організації починають тестування своїх продуктів без належного планування процесів, що є суттєвою помилкою.
Не спланувавши тестування, компанії можуть втратити контроль над його обсягом. Наявність узгодженого обсягу допомагає тесту мати правильний масштаб і ефективно досягати результатів.
Якщо ви не узгодите обсяг тестування до початку роботи, існує серйозний ризик того, що тестування буде занадто широким і займе занадто багато часу для отримання результатів, які будуть менш релевантними.
2. Поспішні процеси тестування
Тестування може здаватися процесом, який займає дуже багато часу, особливо з розлогими тестовими кейсами, призначеними для перевірки всього додатку. У деяких людей може виникнути спокуса поспішати зі здачею аналізів, особливо при повторному проходженні попередніх тестів. Це серйозна помилка. Поспіх при тестуванні може призвести до помилок у виконанні тестових кейсів, що погіршить цінність даних і, зрештою, означатиме, що вам все одно доведеться повторно виконувати ті ж самі тести.
3. Автоматизація без процесу верифікації
Автоматизація тестування в першу чергу фокусується на тому, щоб переконатися, що введення значення даних призведе до правильного результату в кінці процесу. Автоматизація цих тестів працює шляхом перевірки результатів автоматизованого процесу на відповідність очікуваним результатам.
Деякі тестувальники припускаються значної помилки, не обчислюючи значення самостійно, що означає, що вони не мають можливості перевірити, чи правильним є висновок, і потенційно не можуть знайти суттєві помилки у всій системі.
4. Невикористання гібридного тестування
Гібридне тестування – це баланс між автоматизацією та ручним тестуванням, оскільки обидва методи працюють таким чином, що ідеально покривають недоліки один одного.
Деякі організації, однак, вважають за краще зосередитися на одному з двох методів. Таким чином, ви відкриваєте своє тестування для серйозних проблем і неточностей.
Пройдіть гібридне тестування, щоб досягти кращого рівня збалансованості вашого тестування та максимально зменшити кількість помилок.
5. Не завершення регресійного тестування
Регресійне тестування має бути постійним процесом у будь-якій ефективній системі тестування програмного забезпечення, оскільки ця форма тестування визначає, чи не спричинили оновлення програмного забезпечення проблеми в інших частинах системи. Якщо ви не завершите регресійне тестування, це означає, що функції, які ви тестували на початку процесу, можуть давати збої, а ви про це навіть не здогадуєтесь.
Виконавши регресійне тестування, ви гарантуєте, що відправляєте високоякісний продукт, не докладаючи надмірних зусиль до процесу забезпечення якості.
6. Активне полювання на помилки
Дехто вважає, що мета тестування “чорного ящика” – знайти помилки в програмному пакеті та повідомити про них команді розробників, і хоча це один з аспектів, це не єдиний фокус. Тестування існує для того, щоб загалом покращити стандарт програмного пакету.
Занадто зосереджуючись на помилках у програмному забезпеченні, ви починаєте виходити за межі стандартних робочих процесів, виходити за рамки тестування та ігнорувати деякі з найбільш важливих проблем у програмному забезпеченні в обмін на полювання на потенційно несуттєві недоліки в коді.
7. Ігнорування інтуїції
У ручному тестуванні тестувальник відіграє важливу роль, тому що він має інтуїцію та знання коду, які направляють його до потенційних проблем та інформують про області, які слід перевірити під час роботи.
Однак дехто вирішує повністю ігнорувати цю інтуїцію під час роботи над тестовими кейсами. Занотовуючи все, що ви хочете перевірити, і перевіряючи це в новому тестовому кейсі, ви отримуєте повну вигоду від своїх технічних знань, одночасно завершуючи підготовлені тестові кейси.
Типи результатів тестування “чорних скриньок
Існує кілька типів результатів, які можна отримати в результаті тестування “чорного ящика”, і кожен з них надає унікальну інформацію для компанії, яка прагне внести відповідні оновлення в свою продукцію і підвищити якість обслуговування клієнтів.
Деякі з основних типів результатів тестів “чорного ящика” включають в себе наступні:
1. Якісні дані
Перша форма результату, яку ви можете отримати від тесту “чорної скриньки”, – це якісні дані. Це інформація, яка в першу чергу описує додаток і є результатом таких тестів, як наскрізне тестування та юзабіліті-тести.
Якісні дані, як правило, описують стандарт використання програми, обговорюють досвід роботи людей з додатком і пояснюють зміни, які тестувальник хотів би внести.
Створюючи ці дані, тестувальник зазвичай пише ретельний звіт, в якому наводить усі докази своїх тез, підтверджуючи якісні висновки додатковими функціями, такими як скріншоти того, на що він посилається.
2. Кількісні дані
Це стосується чітких числових даних у вигляді метрик, при цьому співробітники, які проводять тестування, або записують певні частини програми, або отримують числові дані з протоколу автоматизованого тестування.
Кількісна інформація, як правило, є більш корисною для надання розробникам конкретних виправлень, вказуючи на такі частини програми, як рівень її продуктивності, ефективність використання ресурсів та кількість помилок і проблем, які присутні у програмі.
Кількісну інформацію простіше аналізувати та оцінювати, ніж її описовий еквівалент, оскільки вона не потребує жодної інтерпретації.
3. Повідомлення про помилки
Повідомлення про помилки виникають, коли функціональність програмного забезпечення працює не так, як очікувалося. Це може бути пов’язано з апаратними або програмними проблемами, які зазвичай супроводжуються коротким описом проблеми на додаток до коду помилки.
Розробники створюють систему кодів помилок, щоб допомогти їм точно визначити, де саме в системі виникає проблема, з деякими ідеями для реалізації, включаючи використання першої цифри для визначення функції, яка зазнає проблеми, другої – для опису того, що саме не вдалося, і третьої – для вказівки причини проблеми.
Використання цієї системи кодів помилок означає, що розробники одразу знають, в чому полягає проблема, і можуть працювати над її вирішенням.
Приклади тестів чорних скриньок
Хоча теорія тестування за методом “чорної скриньки” є відносно простою, практична реалізація цього методу може бути складним процесом, особливо для тестувальника-початківця. Побачивши приклад тестування “чорного ящика” в дії, ви зможете краще організувати своє тестування.
Деякі приклади методів тестування “чорних скриньок”, що включають в себе кілька типів тестування і різний ступінь успішності, включають в себе наступні:
1. Неефективне тестування сприйняття користувачами
Компанія планує випустити свій продукт протягом найближчих тижнів, але ще не провела тестування на сприйняття користувачами. Додаток є навчальним посібником з в’язання для людей похилого віку.
Розробники прагнуть прискорити цей процес і швидко зібрати групу тестувальників, залучаючи до тестування виключно не в’язальниць, оскільки вони є більш доступною групою. Ця група не бачить жодних проблем з додатком і дає йому зелене світло для публічного релізу.
Через суперечливі рівні технічних знань між цими двома групами цільова аудиторія більш розгублена при використанні програмного забезпечення і не може отримати доступ до багатьох функцій. У відповідь на це компанія змушена завершити термінове оновлення.
Невдачі в тестуванні на кшталт цього демонструють важливість ретельної підготовки.
2. Успішне наскрізне тестування
Наскрізне тестування – це тестування, яке відбувається після того, як функціонал програми вперше повністю скомпільовано в один програмний пакет.
Компанія ретельно спланувала завершення наскрізного процесу тестування, найнявши ряд співробітників спеціально для виконання обов’язків з тестування, по два співробітники для кожного тестового кейсу.
Після ретельного процесу вони завершують свої тестові кейси та занотовують усі зібрані дані, а QA-менеджер збирає ці дані у цілісний звіт наприкінці тестування.
Розробники використовують цей звіт для планування наступної серії оновлень і змін у додатку, що значно покращують продукт.
3. Автоматизоване регресійне тестування
Розробник завершив серію оновлень свого програмного забезпечення, яке до цих оновлень працювало належним чином. Після оновлень команда тестувальників проходить процес регресійного тестування, зосереджуючись на автоматизації, і отримує автоматизовану платформу для завершення всієї базової функціональності.
Команда пише код для тестового кейсу і виконує тестові кейси, читаючи всі результати тестів і знаходячи потенційні проблеми.
Це запобігає виникненню проблем через те, що організація робить оновлення і не перевіряє, чи є в них проблеми.
Типи помилок і багів, виявлених за допомогою тестування “чорного ящика
Хоча помилки та баги – це не все в процесі тестування “чорного ящика”, вони є значною частиною того, як компанії проводять тестування.
Знання деяких основних типів помилок і багів у тестуванні чорного ящика може допомогти вам класифікувати будь-які проблеми, з якими ви стикаєтесь, і краще зрозуміти, чому вони виникають.
Деякі з основних типів помилок і багів, які можна виявити за допомогою тестування чорного ящика, включають в себе наступні:
1. Помилки юзабіліті
Помилки юзабіліті – це недоліки програми, які насправді не впливають на функціональність, але можуть спричинити проблеми для користувача, який намагається взаємодіяти з програмою.
Наприклад, якщо додаток має серйозний графічний збій, він все ще технічно функціонує, але без правильних іконок і тексту кінцевий користувач не може ефективно ним користуватися. Ці проблеми, як правило, пов’язані з дизайном програми і тим, як дизайн впливає на користувача, причому більш складні програми вимагають більше графіки, яка є більш складною, ніж у більш простих інтерфейсах.
2. Функціональні помилки
Функціональні помилки – це проблеми, які виникають, коли частина програми працює не так, як очікувалося.
Наприклад, якщо ви використовуєте програму для роботи з базами даних і намагаєтеся відсортувати інформацію за певною категорією, а потім виявляєте, що вона не працює. Це стосується як функцій, які взагалі не працюють, так і тих, які, здається, працюють, але роблять це неправильно.
Це можуть бути одні з найбільш значущих проблем для програми, що спричиняють користувачам значні незручності та погіршують репутацію розробника, оскільки продукт не працює так, як його рекламують.
3. Аварії
Коли частина програмного забезпечення виходить з ладу, існує фундаментальна проблема з програмним забезпеченням, яка зупиняє його роботу. Існує кілька різних форм збоїв, які можуть статися, в тому числі, коли програма повністю закривається або просто зависає на певному етапі процесу.
Збій – це одна з найсерйозніших проблем, яка може виникнути, оскільки не існує способу повернути програму до нормальної роботи, окрім як повністю закрити і знову відкрити її. Хоча деякі програми все ще мають процеси, що відбуваються у фоновому режимі, немає можливості взаємодіяти з програмним забезпеченням після цього моменту.
Загальні показники тестування чорних скриньок
Ручне тестування “чорних скриньок” чудово підходить для отримання якісних даних, але коли ви зосереджуєтесь на кількісних даних, вам потрібно знати метрики, які ви перевіряєте. Розуміння цих показників допоможе вам зрозуміти недоліки платформи та визначити пріоритетні напрямки для роботи.
Деякі з найпоширеніших метрик тестування чорних скриньок, які ви зустрічаєте у своїй роботі, включають в себе наступні:
1. Рівень помилок
Частота помилок може мати два значення: чиста кількість помилок, що трапляються за цикл тестування програмного забезпечення, або кількість помилок, що трапляються за годину тестування. Погодинні показники є кращими, оскільки вони відображають щільність помилок у програмному забезпеченні, а не просто вказують на кількість, при цьому великі програми можуть бути спотворені.
Розробники прагнуть обмежити кількість помилок у своїх додатках, оскільки чим менше помилок у програмному пакеті, тим кращим буде досвід використання системи клієнтом.
2. Час відгуку
Коли тестувальник хоче дізнатися більше про рівень продуктивності, який відчуває користувач, час відгуку є одним з основних аспектів, які слід враховувати. Це кількість часу, необхідного програмі для виконання завдання після того, як користувач ввів запит, причому довший час відгуку свідчить про відносно неефективну роботу програми. Високий час відгуку викликає занепокоєння, оскільки користувачі можуть втратити терпіння, якщо додаток працює занадто довго.
3. Задоволеність користувачів
Більшість метрик зосереджені на чистих цифрах, які генеруються програмним пакетом і тестуванням програмного забезпечення в тесті, але деякі метрики зосереджені на думці.
Наприклад, якщо компанія завершує бета-тестування, в якому беруть участь 1000 тестувальників, вона може зібрати дані про кількість задоволених людей і перетворити їх у відсотки. Це надзвичайно корисний показник, який слід мати наприкінці циклу, адже вищий рівень задоволеності користувачів свідчить про те, що програма подобається більшій кількості людей, а також про те, що вона з більшою ймовірністю матиме успіх у майбутньому.
Найкращі інструменти для тестування чорних скриньок
Тестування “чорного ящика” – це форма тестування, яка значною мірою залежить від наявності під рукою інструментів, як для автоматизації тестування “чорного ящика”, так і для організації інформації, яку ви отримуєте з ваших тестів.
Використання правильної комбінації інструментів може допомогти вам і вашій команді працювати набагато ефективніше і побудувати більш дієві процеси у всьому відділі забезпечення якості.
Ознайомтеся з деякими з найкращих інструментів тестування чорних скриньок нижче і дізнайтеся, як саме кожен з них може допомогти вам процвітати:
5 найкращих безкоштовних інструментів для тестування чорних скриньок
Невеликі компанії, що розвиваються, такі як незалежні розробники, не мають великого бюджету, з яким можна працювати при створенні свого програмного забезпечення. Це може спричинити низку проблем, включаючи пошук правильних інструментів для роботи.
Нижче наведено деякі з найкращих безкоштовних інструментів, доступних для незалежних розробників, які бажають покращити свої робочі процеси, не витрачаючи багато коштів:
1. БЕЗКОШТОВНА ВЕРСІЯ ZAPTEST
Безкоштовна версія ZAPTEST – це ідеальний вступ до автоматизації тестування програмного забезпечення. Цей інструмент спеціально розроблений для підтримки автоматизації будь-яких завдань, допомагаючи вам працювати швидше та ефективніше, незалежно від того, яке завдання ви виконуєте.
Безкоштовна версія ZAPTEST містить величезну кількість функціональних можливостей для підтримки автоматизації будь-якої програми… 1SCRIPT реалізує крос-браузерність, крос-пристрої, крос-додатки та паралельне виконання – це лише деякі з доступних функцій.
2. ДЖИРА
Безкоштовні версії JIRA є ідеальними інструментами для занотовування помилок, додавання деталей до тікетів та визначення пріоритетів під час спілкування з командою розробників.
Однак, замість того, щоб бути універсальним засобом автоматизації, він спеціалізується виключно на управлінні проектами в процесі тестування.
3. Selenium IDE
Додаток з відкритим вихідним кодом, який записує і відтворює автоматизацію тестування, є хорошим інструментом для перегляду того, що бачить платформа автоматизації при завершенні тесту.
Одним з недоліків Selenium є відносна відсутність просунутих функцій, таких як крос-платформна інтеграція автоматизованих завдань.
4. AutoHotkey
AutoHotkey – це повністю безкоштовна мова сценаріїв з відкритим вихідним кодом для Windows, яка допомагає користувачам створювати сценарії різного розміру, що виконують низку завдань після натискання однієї клавіші.
Хоча AutoHotkey добре підходить для автоматизації простих завдань, з деякими великими скриптами та вимогами до автоматизації можуть виникнути проблеми.
5. Аппій
Інструмент, який в першу чергу відмінно справляється з автоматизацією додатків для iOS, є ідеальною програмою для використання, якщо ви хочете покращити якість ваших мобільних додатків.
Найбільшим недоліком Appium є той факт, що ви обмежені дуже невеликим асортиментом продукції, що значно скорочує ваш доступний ринок.
5 найкращих інструментів для тестування корпоративних чорних скриньок
Безкоштовні інструменти – це добре, але підприємствам і великим компаніям потрібно мати більше можливостей для ретельного тестування свого програмного забезпечення. На щастя, деякі з найкращих інструментів тестування корпоративних чорних скриньок мають комплексну функціональність і допомагають компаніям отримати значну віддачу від інвестицій в процеси контролю якості.
Деякі ідеальні інструменти для тестування корпоративних чорних скриньок, в які варто інвестувати, включають в себе наступні:
1. ZAPTEST ENTERPRISE EDITION
Корпоративна версія ZAPTEST є одним з найбільш значущих інструментів автоматизації на ринку і може забезпечити до 10-кратного повернення інвестицій у ваш продукт.
Такі функції, як доступ до штатного експерта ZAP як віддаленої частини вашої команди та необмежені ліцензії гарантують, що ви зможете впровадити автоматизацію тестування за допомогою “чорних скриньок” без необхідності крутої кривої навчання та за фіксовану вартість незалежно від того, наскільки швидко ви зростаєте.
2. TestRail
TestRail – це платформа для тестування в реальному часі, яка об’єднує ваші тести з єдиною платформою управління проектами. Хоча це ідеальний варіант для централізації роботи з управління командою, функції автоматизації далеко не ідеальні для команди розробників, які прагнуть приділяти більше уваги автоматизованим тестам.
3. Опкі
Opkey – це платформа, яка фокусується на автоматизації без коду, що означає, що люди без наявних технічних знань можуть почати автоматизувати свої послуги з тестування.
Одним з головних недоліків Opkey є відсутність активної спільноти навколо програмного забезпечення, що може залишити вас у глухому куті при спробі автоматизації у новий для вас спосіб.
4. Перфекто.
Perfecto – це інструмент, який допомагає користувачам автоматизувати мобільні додатки без будь-яких серйозних проблем, працює на широкому спектрі пристроїв і зосереджується на наскрізному тестуванні.
Однак додаток працює на реальних пристроях, а не на віртуальних машинах, що додає ще одну велику вартість до і без того відносно дорогого інструменту тестування для обмежених платформ.
5. JIRA Enterprise
Окрім завершення автоматизації тестування, важливим залишається управління проектами, і саме тут на допомогу приходить JIRA. Enterprise JIRA має більше сховища і дозволяє більшій кількості користувачів отримати доступ до платформи, але може викликати потенційну плутанину через необхідність індивідуальних дозволів і доступу для кожного окремого користувача. Це займає багато адміністративного часу.
Коли слід використовувати
Інструменти “чорної скриньки” для Enterprise чи Freemium?
Для початку більшість компаній використовуватимуть безкоштовні інструменти “чорної скриньки”. Це має сенс з економічної точки зору, оскільки жоден розумний бізнес не хоче інвестувати в продукт, який він не до кінця розуміє, чи то з точки зору управління проектами, чи то з точки зору автоматизації.
Інструменти Freemium включають не лише повністю безкоштовні програми, але й безкоштовні версії корпоративних продуктів, які компанія використовує, коли вчиться впроваджувати інструмент у свої процеси.
Ідеальний час для організації оновити свій вибір інструменту до корпоративної версії – це коли компанія починає відчувати труднощі в процесах тестування через безкоштовність інструменту. Незалежно від того, чи це безкоштовний інструмент, який пропонує лише певну кількість ліцензій, чи певний обсяг тестування, в той момент, коли ви починаєте відчувати неефективність ваших процесів в результаті використання ваших інструментів тестування, вам слід перейти на корпоративну версію, яка відповідає всім вашим потребам.
Контрольний список для тестування відеореєстраторів, поради та підказки
Оскільки тестування “чорного ящика” є дуже складним методом тестування з великою кількістю можливостей для побудови ваших знань про програмний пакет, є кілька речей, на які вам потрібно звернути увагу.
Деякі важливі поради та підказки, які слід включити до контрольного списку тестування відеореєстраторів:
– Розуміння брифу
Перш ніж почати планувати тестування, переконайтеся, що ви розумієте більш широкий бриф на період тестування. Це включає в себе розуміння програмного забезпечення, наскільки вам це дозволено, і вивчення того, що саме ви будете тестувати.
– Вичитаний тестовий кейс
Спробуйте залучити всіх до тестування, щоб оцінити тестові кейси, які ви використовуєте в тестуванні “чорного ящика”. Чим більше людей побачать тестовий кейс перед реалізацією, тим більше у вас шансів усунути будь-які помилки.
– Складіть список справ, які потрібно зробити
Нетехнічна сторона підготовки до тестування “чорних скриньок” може бути настільки ж важливою, як і технічна. Плануючи, створіть послідовний список справ, в якому буде вказано, хто тестує яку частину програмного забезпечення і в який конкретний час. Це зменшує плутанину, потенційне вигорання та затримки, пов’язані з виконанням інших завдань.
– Негайно фіксуйте результати
Негайно записуйте всі результати, які генерує тест. Занадто довго чекаючи на ручні тести, ви можете неправильно запам’ятати проблеми, тому миттєві нотатки значно підвищують точність.
– Зв’язок з розробниками
Обговоріть з розробниками часові рамки та стратегію тестування, щоб вони розуміли, що відбувається і коли можна очікувати на роботу над новими оновленнями. Це включає в себе встановлення чітких процесів, за допомогою яких відділи взаємодіють один з одним.
– Дані, які можна використати для дій
Під час написання звіту переконайтеся, що всі дані, які ви надаєте розробнику, мають практичне значення. Це допомагає команді розробляти продукт, який відповідає на її проблеми, а не розробнику, який не розуміє, які зміни потрібно внести.
– Зрозумійте свої пріоритети
Як команда тестувальників, вашим пріоритетом є забезпечення того, щоб компанія надавала користувачам високоякісний продукт. Якщо тестування займає трохи більше часу, ніж очікувалося, пам’ятайте, що це вартий обмін на підвищення якості, яке відчуває клієнт.
– Знати ієрархію
В ідеальній компанії-розробнику розробники та тестувальники знаходяться на одному рівні ієрархії, маючи однаково важливий вплив на розвиток програмного забезпечення. Зрозумійте ієрархію у вашій організації та намагайтеся переконатися, що всі розуміють цінність якісного тестування.
– Ведіть послідовну документацію
Зберігайте копії всіх даних і звітів, які ви створюєте під час тестування. Ви можете відстежувати зміни в додатку, за які відповідає команда тестувальників, а також переглядати старі помилки, щоб побачити, чи не повторюються вони в наступних версіях.
Висновок
Тестування “чорного ящика” є однією з найважливіших частин процесу тестування програмного забезпечення. Він допомагає компаніям переконатися, що те, що вони відправляють, відповідає найвищим можливим стандартам, і використовує зміну перспективи, щоб запропонувати унікальну інформацію про те, як додаток сприймається і впроваджується зовнішнім користувачем.
Будь-яка компанія, яка не додає тестування “чорних скриньок”, як автоматизоване, так і ручне, до своїх процесів, втрачає можливість значно покращити якість своїх додатків. Тестуйте розумно, і ви пожнете плоди, коли ваші клієнти отримають доступ до вашого продукту.
Поширені запитання та ресурси
Незалежно від того, як багато ви знаєте про тестування за методом “чорної скриньки”, у вас може виникнути ще більше запитань, і ви захочете поглибити своє розуміння цього методу. Ознайомтеся з нашими поширеними запитаннями нижче, щоб дізнатися більше про тестування “чорних скриньок” і отримати доступ до низки ресурсів, які можуть розповісти вам більше про методологію.
1. Найкращі курси з автоматизації тестування відеореєстраторів
Існує кілька курсів з автоматизації тестування з використанням чорних скриньок, кожен з яких допомагає людям досягти різних стандартів тестування.
Деякі з найбільш авторитетних курсів з тестування чорних скриньок включають в себе наступні:
– “Тестування чорного та білого ящиків” від Coursera
– “Серія тестування програмного забезпечення Black-Box” від BBST
– “Вступ до методів тестування програмного забезпечення Black Box” від Udemy
– “Автоматизація тестування програмного забезпечення” від Лондонської школи нових технологій
– “Три ключові методи тестування чорних скриньок” від Udemy
2. Які 5 найкращих запитань на співбесіді при тестуванні “чорного ящика”?
Тестування програмного забезпечення – це висококонкурентна сфера, де на кожну вакансію претендує безліч кандидатів. Якщо ви отримаєте запрошення на співбесіду для участі в тестуванні “чорної скриньки”, ось деякі з питань, до яких ви, можливо, захочете підготуватися, щоб відповісти на співбесіді:
– Який досвід роботи з тестуванням “чорних скриньок” у вас є?
– Які основні відмінності між тестуванням “чорної скриньки” та “білої скриньки”?
– Чи є у вас досвід роботи з програмною автоматизацією на попередніх посадах?
– Чи можете ви розповісти нам про випадки, коли ви стикалися з труднощами на робочому місці, і як ви їх подолали?
– Як ви вважаєте, яке майбутнє чекає на тестування “чорних скриньок”, і як ваші навички підходять для довгострокової кар’єри в тестуванні програмного забезпечення?
3. Найкращі навчальні відео на Youtube про тестування чорних скриньок
YouTube є одним з найважливіших навчальних ресурсів, доступних для людей, які розвивають свої навички тестування програмного забезпечення, оскільки він надає безкоштовне джерело інформації, яку ви можете використовувати для розвитку своєї техніки.
Деякі з найкращих навчальних посібників, які варто переглянути, коли ви вивчаєте тестування чорних скриньок:
– “Вступ до тестування чорного та білого ящиків – Georgia Tech – процес розробки програмного забезпечення” від Udacity
– “Тестування чорного та скляного ящиків” від MIT OpenCourseWare
– “7 технік тестування чорних скриньок, які повинен знати кожен QA” від The Testing Academy
– “Тестування чорних скриньок | Що таке тестування чорних скриньок | Навчитися тестуванню чорних скриньок” від Intellipaat
– “Що таке тестування білих, сірих та чорних скриньок?” від ITProTV
4. Як підтримувати тести “чорної скриньки”?
Підтримка тестів чорної скриньки, незалежно від того, чи це ручні чи автоматизовані тести, полягає в тому, щоб звертати увагу на тести під час їх проведення та постійно шукати виправлення, якщо виникають проблеми.
Це включає в себе впевненість у тому, що будь-які тестові кейси проходять так, як ви очікуєте, кожного разу, і перевірку того, що автоматизовані інструменти виконують всі правильні кроки. Робіть це якомога частіше, щоб запобігти зниженню ваших стандартів, оскільки добре проведений тест “чорного ящика” дає максимально точні результати.
5. Найкращі книги про тестування чорних скриньок
Хоча тестування чорних скриньок і тестування програмного забезпечення в цілому є сферою, що постійно розвивається, є кілька книг, які залишаються актуальними і пропонують багато інформації про те, як покращити вашу роботу з тестування.
Деякі з найкращих книг про тестування чорних скриньок включають в себе:
– “Тестування “чорного ящика”: Методи функціонального тестування програмного забезпечення та систем” Борис Бейзер
– “Тестування програмного забезпечення: Принципи та практика” Шрінівасан Десікан, Гопаласвамі Рамеш
– “Основи тестування програмного забезпечення” Ральф Беріг, Стівен Браун, Едгар Гальван
– “Вступ до тестування програмного забезпечення”, Пол Амманн, Джефф Оффутт
