QA питання по теорії

«Spiral Model» (спіральна модель)

«Спіральна модель» схожа на інкрементного, але з акцентом на аналіз ризиків. Вона добре працює для вирішення критично важливих бізнес-задач, коли невдача несумісна з діяльністю компанії, в умовах випуску нових продуктових лінійок, при необхідності наукових досліджень і практичної апробації. Спіральна модель передбачає 4 етапи для кожного витка: планування; аналіз ризиків; конструювання; оцінка результату і при задовільній якості перехід до нового витка. Ця модель не підійде для малих проектів, вона резонна для складних і дорогих, наприклад, таких, як розробка системи документообігу для банку, коли кожен наступний крок вимагає більшого аналізу для оцінки наслідків, ніж програмування.

низу вгору (Bottom Up Integration)

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

Об'ємне тестування (Volume Testing)

Завданням об'ємного тестування є отримання оцінки продуктивності при збільшенні обсягів даних в базі даних програми.

Тестування стабільності або надійності (Stability / Reliability Testing)

Завданням тестування стабільності (надійності) є перевірка працездатності програми при тривалому (багатогодинному) тестуванні із середнім рівнем навантаження.

Матриця відповідності вимог Traceability matrix

Матриця відповідності вимог - це двовимірна таблиця, яка містить відповідність функціональних вимог (functional requirements) продукту і підготовлених тестових сценаріїв (test cases). У заголовках колонок таблиці розташовані вимоги, а в заголовках рядків - тестові сценарії. На перетині - відмітка, що означає, що вимога поточної колонки покрито тестовим сценарієм поточного рядка. Матриця відповідності вимог використовується QA-інженерами для валідації покриття продукту тестами. МВВ є невід'ємною частиною тест-плану.

Операційне тестування (Release Testing)

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

Еквівалентний Поділ (Equivalence Partitioning - EP)

Наприклад є діапазон допустимих значень від 1 до 10, ви повинні вибрати одне вірне значення всередині інтервалу, скажімо, 5, і одне невірне значення поза інтервалом - 0.

«Waterfall Model» (каскадна модель або «водоспад»)

Одна з найстаріших, передбачає послідовне проходження стадій, кожна з яких має завершитися повністю до початку наступної. У моделі Waterfall легко керувати проектом. Завдяки її жорсткості, розробка проходить швидко, вартість і термін заздалегідь визначені. Каскадна модель буде давати відмінний результат тільки в проектах з чітко і заздалегідь визначеними вимогами і способами їх реалізації. Немає можливості зробити крок назад, тестування починається тільки після того, як розробка завершена або майже завершена. Продукти, розроблені за цією моделлю без обґрунтованого її вибору, можуть мати недоліки (список вимог не можна скорегувати в будь-який момент), про які стає відомо лише в кінці через сувору послідовності дій. Вартість внесення змін висока, так як для її ініціалізації доводиться чекати завершення всього проекту. Проте, фіксована вартість часто переважує мінуси підходу. Виправлення усвідомлених в процесі створення недоліків можливо, і, за нашим досвідом, вимагає від одного до трьох додаткових угод до контракту з невеликим ТЗ. Коли використовувати каскадну методологію? Тільки тоді, коли вимоги відомі, зрозумілі і зафіксовані. Суперечливих вимог немає. Немає проблем з доступністю програмістів потрібної кваліфікації. У відносно невеликих проектах.

Системне тестування (System Testing)

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

Принципи тестування

Принцип 1 - Тестування демонструє наявність дефектів (Testing shows presence of defects) Тестування може показати, що дефекти присутні, але не може довести, що їх немає. Тестування знижує ймовірність наявності дефектів, що знаходяться в програмному забезпеченні, але, навіть якщо дефекти не були виявлені, це не доводить його коректності. Принцип 2 - Повне тестування недосяжне (Exhaustive testing is impossible) Повне тестування з використанням всіх комбінацій вводів і передумов фізично неможливо, за винятком тривіальних випадків. Замість вичерпного тестування повинні використовуватися аналіз ризиків і розстановка пріоритетів, щоб більш точно сфокусувати зусилля по тестуванню. Принцип 3 - Раннє тестування (Early testing) Щоб знайти дефекти якомога раніше, тестування повинно бути розпочато якомога раніше в життєвому циклі розробки програмного забезпечення або системи, і повинно бути сфокусовано на певних цілях. Принцип 4 - Скупчення дефектів (Defects clustering) Зусилля тестування повинні бути зосереджені пропорційно очікуваній, а пізніше реальної щільності дефектів по модулях. Як правило, більша частина дефектів, виявлених при тестуванні або спричинили за собою основну кількість збоїв системи, міститься в невеликій кількості модулів. Принцип 5 - Парадокс пестициду (Pesticide paradox) Якщо одні й ті ж тести будуть проганяти багато разів, в кінцевому рахунку цей набір тестових сценаріїв більше не буде знаходити нових дефектів. Щоб подолати цей «парадокс пестициду», тестові сценарії повинні регулярно рецензуватися і коригуватися, нові тести повинні бути різнобічними, щоб охопити всі компоненти програмного забезпечення, або системи, і знайти якомога більше дефектів. Принцип 6 - Тестування залежить від контексту (Testing is concept depending) Тестування виконується по-різному в залежності від контексту. Наприклад, програмне забезпечення, в якому критично важлива безпека, тестується інакше, ніж сайт електронної комерції. Принцип 7 - Помилка про відсутність помилок (Absence-of-errors fallacy) Виявлення і виправлення дефектів не допоможуть, якщо створена система не підходить користувачеві і не задовольняє його очікуванням і потребам.

Цілі тестування

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

«Agile Model» (гнучка методологія розробки)

У «гнучкої» методології розробки після кожної ітерації замовник може спостерігати результат і розуміти, задовольняє він його чи ні. Це одна з переваг гнучкої моделі. До її недоліків відносять те, що через відсутність конкретних формулювань результатів складно оцінити трудовитрати і вартість, необхідні на розробку. Екстремальне програмування (XP) є одним з найбільш відомих застосувань гнучкої моделі на практиці. В основі такого типу - нетривалі щоденні зустрічі - «Scrum» і регулярно повторювані зборів (раз в тиждень, раз на два тижні або раз на місяць), які називаються «Sprint». На щоденних нарадах учасники команди обговорюють: звіт про виконану роботу з моменту останнього Scrum'a; список завдань, які співробітник повинен виконати до наступних зборів; труднощі, що виникли в ході роботи. Методологія підходить для великих або націлених на тривалий життєвий цикл проектів, постійно адаптуються до умов ринку. Відповідно, в процесі реалізації вимоги змінюються. Варто згадати клас творчих людей, яким властиво генерувати, видавати і випробувати нові ідеї щотижня або навіть щодня. Гнучка розробка найкраще підходить для цього психотипу керівників. Внутрішні стартапи компанії ми розробляємо по Agile. Коли використовувати Agile? Коли потреби користувачів постійно змінюються в динамічному бізнесі. Зміни на Agile реалізуються за меншу ціну через часті інкрементів. На відміну від моделі водоспаду, в гнучкою моделі для старту проекту достатньо лише невеликого планування.

«V-Model»

Успадкувала структуру «крок за кроком» від каскадної моделі. V-образна модель застосовна до систем, яким особливо важливо безперебійне функціонування. Наприклад, прикладні програми в клініках для спостереження за пацієнтами, інтегроване ПО для механізмів управління аварійними подушками безпеки в транспортних засобах і так далі. Особливістю моделі можна вважати те, що вона спрямована на ретельну перевірку і тестування продукту, що знаходиться вже на початкових стадіях проектування. Стадія тестування проводиться одночасно з відповідною стадією розробки, наприклад, під час кодування пишуться модульні тести. Коли використовувати V-модель? Якщо потрібне ретельне тестування продукту, то V-модель виправдає закладену в себе ідею: validation and verification. Для малих і середніх проектів, де вимоги чітко визначені і фіксовані. В умовах доступності інженерів необхідної кваліфікації, особливо тестувальників.

Приймальне тестування (Acceptance Testing)

Формальний процес тестування, який перевіряє відповідність системи вимогам і проводиться з метою: • визначення чи задовольняє система приймальним критеріям; • винесення рішення замовником або іншою уповноваженою особою приймається додаток чи ні.

Передбачення помилки (Error Guessing - EG)

Це коли тест аналітик використовує свої знання системи і здатність до інтерпретації специфікації на предмет того, щоб «вгадати» за яких вхідних умовах система може видати помилку. Наприклад, специфікація каже: «користувач повинен ввести код». Тест аналітик, буде думати: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код? ", і так далі. Це і є передбачення помилки.

Причина / Наслідок (Cause / Effect - CE)

Це, як правило, введення комбінацій умов (причин), для отримання відповіді від системи (Наслідку). Наприклад, ви перевіряєте можливість додавання клієнта, використовуючи певну екранну форму. Для цього вам необхідно буде ввести кілька полів, таких як «Ім'я», «Адреса», «Номер Телефону» а потім, натиснути кнопку «Додати» - ця «Причина». Після натискання кнопки «Додати», система додає клієнта в базу даних і показує його номер на екрані - це «Наслідок».

Димове тестування (Smoke Testing)

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

Чек-лист (check list)

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

Тест дизайн

це етап процесу тестування ПО, на якому проектуються і створюються тестові випадки (тест кейси), відповідно до визначених раніше критеріями якості та цілями тестування. Ролі, відповідальні за тест дизайн: • Тест аналітик - визначає «ЩО тестувати?» • Тест дизайнер - визначає «ЯК тестувати?»

Стадії розробки ПО

це етапи, які проходять команди розробників ПЗ, перш ніж програма стане доступною для широко кола користувачів. Розробка ПО починається з початкового етапу розробки (стадія «пре-альфа») і триває стадіями, на яких продукт допрацьовується і модернізується. Фінальним етапом цього процесу стає випуск на ринок остаточної версії програмного забезпечення ( «загальнодоступного релізу»). Програмний продукт проходить наступні стадії: • аналіз вимог до проекту; • проектування; • реалізація; • тестування продукту; • впровадження та підтримка. Кожній стадії розробки ПО присвоюється певний порядковий номер. Також кожен етап має свою власну назву, яке характеризує готовність продукту на цій стадії.

Повне тестування (Exhaustive Testing - ET)

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

Тестування зручності користування (Usability Testing)

це метод тестування, спрямований на встановлення ступеня зручності використання, навченості, зрозумілості і привабливості для користувачів продукту, що розробляється в контексті заданих умов. Сюди також входить: Тестування інтерфейсу користувача (англ. UI Testing) - це вид дослідницького тестування, виконуваного з метою визначення, чи зручний деякий штучний об'єкт (такий як веб-сторінка, для користувача інтерфейс або пристрій) для його передбачуваного застосування. User eXperience (UX) - відчуття, яке відчувається користувачем під час використання цифрового продукту, в той час як User interface - це інструмент, що дозволяє здійснювати інтеракцію «користувач - веб-ресурс».

Дефект (баг bug)

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

Верифікація (verification)

це процес оцінки системи або її компонентів з метою визначення чи відповідають результати поточного етапу розробки, умовам сформованим на початку цього етапу. Тобто чи виконуються наші цілі, терміни, завдання по розробці проекту, визначені на початку поточної етапу. Процес оцінки відповідності продукту явним вимогам (специфікаціям) і є верифікація (verification). Verification - 'is ​​the system correct to specification?'

SOAP проти REST

це реалізація абсолютно чітких інтерфейсів обміну даними між різними додатками, які написані не тільки на різних мовах, але і розподілені на різних вузлах мережі. - SOAP (Simple Object Access Protocol) - по суті це трійка стандартів SOAP / WSDL / UDDI - REST (Representational State Transfer) - XML-RPC (XML Remote Procedure Call)

Веб-сервіси

це реалізація абсолютно чітких інтерфейсів обміну даними між різними додатками, які написані не тільки на різних мовах, але і розподілені на різних вузлах мережі. - SOAP (Simple Object Access Protocol) - по суті це трійка стандартів SOAP / WSDL / UDDI - REST (Representational State Transfer) - XML-RPC (XML Remote Procedure Call)

«RAD Model» (rapid application development model або швидка розробка додатків)

RAD-модель - різновид інкрементної моделі. У RAD-моделі компоненти або функції розробляються декількома висококваліфікованими командами паралельно, ніби кілька міні-проектів. Тимчасові рамки одного циклу жорстко обмежені. Створені модулі потім інтегруються в один робочий прототип. Синергія дозволяє дуже швидко надати клієнту для огляду щось робоче з метою отримання зворотного зв'язку і внесення змін. Модель швидкої розробки додатків включає наступні фази: Бізнес-моделювання: визначення переліку інформаційних потоків між різними підрозділами. Моделювання даних: інформація, зібрана на попередньому етапі, використовується для визначення об'єктів і інших сутностей, необхідних для циркуляції інформації. Моделювання процесу: інформаційні потоки пов'язують об'єкти для досягнення цілей розробки. Збірка програми: використовуються кошти автоматичного складання для перетворення моделей системи автоматичного проектування в код. Тестування: тестуються нові компоненти і інтерфейси. Коли використовується RAD-модель? Може використовуватися тільки при наявності висококваліфікованих і вузькоспеціалізованих архітекторів. Бюджет проекту великий, щоб оплатити цих фахівців разом з вартістю готових інструментів автоматизованого складання. RAD-модель може бути обрана при впевненому знанні цільового бізнесу і необхідності термінового виробництва системи протягом 2-3 місяців.

«Incremental Model» (инкрементная модель)

В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули. Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система. Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. Когда использовать инкрементную модель? Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени. Требуется ранний вывод продукта на рынок. Есть несколько рисковых фич или целей

Великий вибух ( «Big Bang» Integration)

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

Модульне тестування (Unit Testing)

Компонентне (модульне) тестування перевіряє функціональність і шукає дефекти в частинах додатка, які доступні і можуть бути протестовані по-окремо (модулі програм, об'єкти, класи, функції і т.д.).

Інтеграційне тестування(Integration Testing)

Перевіряється взаємодія між компонентами системи після проведення компонентного тестування.

Зверху вниз (Top Down Integration)

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

Cтатичне і динамічне тестування

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

Функціональні види тестування

Функціональне тестування (Functional testing) • Тестування безпеки (Security and Access Control Testing) • Тестування взаємодії (Interoperability Testing) • Регрес • ретест • Smoke-test

Конфігураційне тестування (Configuration Testing)

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

Тестування установки (Installation testing)

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

Тестування програмного забезпечення

перевірка відповідності між реальною і очікуваною поведінкою програми, що здійснюється виконанням наборів тестів, обраному певним чином. Техніка контролю якості, що включає в себе планування робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) і аналізу отриманих результатів (Test Analysis).

Тестування на відмову і відновлення (Failover and Recovery Testing

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

Функціональне тестування

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

«Iterative Model» (ітеративна або итераціона модель)

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

Тестування навантаження (Load Testing)

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

Тестовий випадок (Test Case)

це артефакт, що описує сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації функції яку тестують або її частини. PreConditions Список дій, які призводять систему до стану придатного для проведення основної перевірки. Або список умов, виконання яких говорить про те, що система знаходиться в придатному стані для проведення основного тесту. Test Case Description Список дій, які переводять систему з одного стану в інший, для отримання результату, на підставі якого можна зробити висновок про відповідність реалізації, поставленим вимогам. PostConditions Список дій, які переводять систему в почтковий стан (стан до проведення тесту - initial state) Види Тестових Випадків: Тест кейси поділяються за очікуваним результатом на позитивні і негативні: • Позитивний тест кейс використовує тільки коректні дані і перевіряє, щоб додаток правильно виконував функцію, що викликається. • Негативний тест кейс оперує як коректними так і некоректними даними (мінімум 1 некоректний параметр) і ставить за мету перевірку виняткових ситуацій (спрацьовування валідаторів), а також перевіряє, що викликана додатком функція не виконується при спрацьовуванні валідатора.

Якість програмного забезпечення (Software Quality)

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

Тестування взаємодії (Interoperability Testing)

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

Техніки тест дизайну

• Еквівалентний Поділ (Equivalence Partitioning - EP) • Аналіз Граничних Значний (Boundary Value Analysis - BVA) • Причина / Слідство (Cause / Effect - CE) • Передбачення помилки (Error Guessing - EG) • Повне тестування (Exhaustive Testing - ET)

Вимоги до вимог

• Коректність • Однозначність • Повнота набору вимог • Несуперечність набору вимог • Верифікованість (тестопригодності) • Трасируваність • Зрозумілі

Підходи до інтеграційного тестування

•Знизу вгору (Bottom Up Integration) • Зверху вниз (Top Down Integration) • Великий вибух ( «Big Bang» Integration)

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

1. Аналіз 2. Розробка стратегії тестування і планування процедур контролю якості 3. Робота з вимогами 4. Створення тестової документації 5. Тестування прототипу 6. Основне тестування 7. Стабілізація 8. Експлуатація

Рівні Тестування

1. Модульне тестування (Unit Testing) 2. Інтеграційне тестування (Integration Testing) 3. Системне тестування (System Testing) 4. Операційне тестування (Release Testing). 5. Приймальне тестування (Acceptance Testing)

У чому різниця між regression testing і re-testing?

Re-testing - перевіряється виправлення багів Regression testing - перевіряється те, що виправлення багів не вплинуло на інші модулі ПО і не викликало нових багів.

SQL

UPDATE tbl_name SET col_name1=expr1 [, col_name2=expr2, ...] [WHERE where_definition] INSERT INTO tbl_name (col1,col2) VALUES(15,col1*2) DELETE FROM table_name [WHERE where_definition]

Пов'язані зі змінами види тестування(Тестування після змін)

Димові тестування (Smoke Testing) • Регресійне тестування (Regression Testing) • Повторне тестування (Re-testing) • Тестування збірки (Build Verification Test) • Санітарне тестування або перевірка узгодженості / справності (Sanity Testing)

Нефункціональні види тестування

Всі види тестування продуктивності: - тестування навантаження (Performance and Load Testing) - стресове тестування (Stress Testing) - тестування стабільності або надійності (Stability / Reliability Testing) - об'ємне тестування (Volume Testing) • Тестування установки (Installation testing) • Тестування зручності користування (Usability Testing) • Тестування на відмову і відновлення (Failover and Recovery Testing) • Конфігураційне тестування (Configuration Testing)

Дослідницьке / ad-hoc тестування

Найпростіше визначення дослідницького тестування - це розробка і виконання тестів в один і той же час. Що є протилежністю сценарного підходу (з його зумовленими процедурами тестування, неважливо ручними або автоматизованими). Дослідницькі тести, на відміну від сценарних тестів, не визначені заздалегідь і не виконуються в точній відповідності з планом. Різниця між ad hoc і exploratory testing в тому, що теоретично, ad hoc може провести будь-хто, а для проведення exploratory необхідно майстерність і володіння певними техніками. Зверніть увагу, що певні техніки це не тільки техніки тестування.

Тестування збірки або Build Verification Test

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

Санітарне тестування (Sanity Testing)

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

Аналіз Граничних Значень (Boundary Value Analysis - BVA)

Якщо взяти приклад вище, в якості значень для позитивного тестування виберемо мінімальну і максимальну межі (1 і 10), і значення більше і менше межі (0 і 11). Аналіз Граничний значень може бути застосований до полів, записів, файлів, або до будь-якого роду сутностей які мають обмеження.

Стресове тестування (Stress Testing)

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

Валідація (validation)

процес визначення відповідності розроблюваного програмного забезпечення між очікуваннями і потребами користувача, вимогам до системи. Мета процесу валідації — переконатися, що специфічні вимоги для програмного продукту виконано, і здійснюється це за допомогою: 1.розробленої стратегії і критеріїв перевірки всіх робочих продуктів; 2.обговорених дій з проведення валідації; 3.демонстрації відповідності розроблених програмних продуктів вимогам замовника і правилам їхнього використання; 4.узгодження із замовником отриманих результатів валідації продукту. Validation - 'is ​​this the right specification?'.

Повторне тестування(re-testing)

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

Регресійне тестування(Regression Testing)

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

Тест план (Test Plan)

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

Вимоги

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

Тестування безпеки

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

Життєвий цикл бага

• Новий (New). Тестувальник знайшов баг, дефект успішно занесений в «Bug-tracking» систему. • Відкрито (Opened). Після того, як Теcтувальник відправив помилку, вона або автоматично, або в ручному режимі призначається на людину яка повиненна її проаналізувати (зазвичай Project Manager). Залежно від рішення менеджера проекту, баг може бути: - Відкладений (Deferred). Виправлення цього бага не несе цінності на даному етапі розробки або по іншим, відстрочує його виправлення причин. - Відхилено (Rejected). З різних причин дефект може і не рахуватися дефектом або вважатися неактуальним дефектом, що змушує відхилити його.- Дублікат (Duplicate). Якщо описана помилка вже раніше була внесена в «Bug-tracking» систему, то статус такої помилки змінюється на «дублікат». • Призначено (Assigned). Якщо помилка актуальна і повинна бути виправлена ​​в наступній збірці (build), відбувається призначення на розробника який повинен виправити помилку. Коли наявність дефекту незаперечно, його шлях може привести до наступних статусів: • Виправлено (Fixed). Відповідальний за виправлення бага розробник заявляє, що усунув дефект. Залежно від того, виправив чи розробник дефект, дефект може бути:Перевірено (Verified). Тестувальник перевіряє, чи дійсно відповідальний розробник виправив дефект, або все-таки розробник безвідповідальний. Якщо бага більше немає, він отримує даний статус. - Повторно відкритий (Reopened). Якщо побоювання тестувальника виправдані і баг в новому білді виправлені - він все так же зажадає виправлення, тому заново відкривається. • Закритий (Closed). В результаті певної кількості циклів баг все-таки остаточно усунутий і більше не потребуює уваги команди - він оголошується закритим.