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

Лектор:Биковець Артем Тарасович

Лекція 1. Життєвий цикл ПЗ

date: 2016-09-08 10:20:00 +0300

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

SDLC

Продукт:

                      SDLC (Software Development Life Cycle)

+---------------+     +----------------------------------+     +-------------------------+
|    Idea       | 💡  |             Analysis             |  📚 | Architecture and design | 📄
+---------------+ --> +----------------------------------+ --> +-------------------------+ -->--+
| Product Owner |     | Business Analyst; System Analyst | SRS | System Architect        |      |
+---------------+     +----------------------------------+ BRD +-------------------------+      |
                                                                                                |
+-----------------------------------------------------------------------------------------------+
|
|     +------------+     +---------+       +-----------+ new +--------------+
| 📄  | Development|build| Testing |report | Bugfixing |build| Verification | RC Build
+---> +------------+ --> +---------+ ----> +-----------+ --> +--------------+ -->---+
      | Developers |     | QC / QA |       | Developer |     |              |       |
      +------------+     +---------+       +-----^-----+     +-------+------+       |
                                                 |                   |              |
                                                 +-------------------+              |
                                                                                    |
+-----------------------------------------------------------------------------------+
|
|     +--------------------+        +---------+     +---------+     +----------+
|     | Acceptance Testing |        | Release |     | Support |     | DEATH 💀 |
+---> +--------------------+ -----> +---------+ --> +---------+ --> +----------+
      |                    |        |         |     |         |     |          |
      +--------------------+        +---------+     +---------+     +----------+
  • SRS – System Requirement Specification
  • BRD – Business Requirement Documentation
  • QC – Quality Control – валідує / верифікує постфактум
  • QA – Quality Assurance – забезпечує якість продукту протягом усього життєвого циклу, здійснюючи превентивні заходи
  • SDET – Software Development Engineer in Test – займаються тесуванням на рівні кода (whitebox testing), написання unit-тестів, інтеграційних систем, підтримкою CI-систем та дрібним багфіксингом
  • Acceptance Testing – тестування на відповідність вимогам на передрелізній стадії

SDLC по факту можна вважати розширеною моделлю Waterfall

Waterfall

                  Waterfall
^
|  ------+
|   IDEA |  🐞
|        +----------+
|          Analysis |
|                   +-----+
|                     DEV |
|                         +---------+
|                           Testing |
|                                   +---------+
|                                     Release |     time
+--------------------------------------------------->

Баг 🐞 на етапі аналізу випливе надто пізно – на етапі тестування і його виправлення займе надто багато часу.

  • Verification – перевірка на відповідність формальним критеріям (очікуваний результат завжди строго визначений)
  • Validation – перевірка на адекватність (суб’єктивне)

Самостійне опрацювання

  • Спіральна модель
  • V-модель

Лекція 3. Види тестування

date: 2016-09-22 10:20:00 +0300

Види тестування

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

Найпростіше види тестування розглядати у розрізі класифікацій.

  • За способом виконання тесту

  • Manual – повністю ручне

  • Auto

  • Semi-auto – вимагає участі тестувальника, але в основному тести проганяються автоматично.

  • За стадією проведення

  • Alpha – проводиться всередині команди розробки

  • Beta – проводиться тестувальниками зі сторони. Тестувальниками тут можуть бути як спеціально навчені QA, так і замовник або якась цільова група користувачів.

  • Beta++ – всі подальші тестування.

  • За доступом до внутрішнього влаштування системи

  • Black box. Для тестування не використовуються знання про внутрішнє влаштування системи. По-факту перевіряється правильність залежності виводу від вводу.

  • Gray box. Використовуються незначні деталі внутрішнього влаштування системи. Наприклад, при реєстрації користувача перевіряється наявність відповідного запису в БД, перевіряється, що певні запити були відправлені на сервер.

  • White box. Тестування безпосередньо по коду.

  • За виконанням коду

    Я не знаю зачем вообще эта классификация есть ©

  • Static. Тестування без запуску продукту, якість якого перевіряється. Наприклад, тестування вимог.

  • Dynamic. Тестування із запуском продукту.

  • За направленістю тестового сценарію

  • Positive. Перевіряються сценарії ,описані в вимогах.

  • Negative. Перевіряється поведінка системи у випадках, не описаних в документації.

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

  • За об’єктом тестування
  • Functional. Тестування функціоналу системи.
  • Security
  • Non-Functional
    • UI/GUI
    • usability (UX)
    • Performance
    • Load – перевірка здатності системи витримувати ті чи інші навантаження
    • Stress – перевірка того, як система працює при навантаженнях, що перевищують очікувані.
    • Stability
    • Recoverability – здатність системи відновлюватися після помилок та поломок.
    • Volume – перевірка на те, які об’єми дискового простору використовує система.
    • l10n (localization), i18n (internationalization)

Також виділяють такі види тестування:

  • Regression testing. Тестування того, що вже було протестовано. Проводиться у випадку, коли змінюють старий код, або нові зміни можуть поламати існуючий функціонал.
  • Exploratory Testing.
  • Smoke testing. – швидке тестування основних моментів ритичного функціоналу.
  • Sanity testing. – швидке і глибоке тестування якогось невеличкого шматочку функціоналу
  • Acceptance testing

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

  • Однозначність.

    Требования должны быть одинаково понятны вам, ребеёнку і старушке, впадающей в маразм.

  • Повнота Вимоги повинні повністю і детально описувати функціонал.

  • Неперетин

  1. Одна сутність повинна бути писана в одній вимозі
  2. Різні вимоги не повинні протирічити одне одному
  • Адекватність
  • Testability (хз, як перекласти) Здатність з вимоги зрозуміти як перевіряти її виконання.

Лекція 4. Тест-дизайн

date: 2016-10-06 10:40:55 +0300

Тест-дизайн – такой инструмент, который помогает не писать тесты ради тестов.

Test liifecycle

  1. Analysis
  2. Test planning
  3. Test Design – стадія проектування, написання тестової документації
  4. Test Execution – стадія виконання тестів
  5. Acceptance Testing
  6. Test Closure Activities – згортання тестових активностей – почистити після тестів
  7. Testing Reportig

Test Design Techniques

Інколи виникає бажання якось поміряти ефективність тестів. Існують такі метрики:

  • code coverage $$ {code\ coverage} = \frac{lines\ of\ code}{strings\ covered\ by\ tests} \cdot 100 \% $$
  • requirements coverage – покриття вимог теста

Методи:

  • Equivalent partitioning – метод класів еквівалентності. Суть полягає у розділенні вхідних даних на групи (класи еквівалентності), для яких сценарій виконання буде одним і тим же. Тоді достатньо перевірити по одному сценарію з кожного класу еквівалентності і по одному сценарію за межами того класу еквівалентності. Основне призначення цього методу – тестувати швидше і робити менше непотрібних дій.

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

    Есть условный PornHub. Допустим, на входе пользователя спрашивают его дату рождения. Если есть 18, то показывать ему взрослый контент, если нет – то не показывать. В этом случае тестированием граничных значением будет проверка разных случаев, когда пользователю ровно 18 лет.

  • Вточнити границі

    a < 1000 ===> b=5

    a:[1000;5000] ===> b=10

    a>5000 ===> b=15

  • Визначити величину “кроку” між сусідніми значеннями

    a-n, a, a+n, b-n, b, b+n

  • State-transition technique – аналіз переходів станів системи. Якимось чином малюєте / виписуєте всі стани системи і позначаєте “зеленими стрілочками” всі можливі переходи. Коли це візуалізовано, на кожен стан пишуться тести, потім пишуться позитивні тести на кожну зелену стрілочку і негативні тести на кожну відсутню стрілочку (там де переходів бути не повинно).

Протестуємо світлофор. Маємо такі стани:

  1. “зелений чоловічок” + “червоний водій”
  2. “зелений чоловічок миготить”
  3. “червоний чоловічок” + “червоний або жовтий водій”
  4. “червоний чоловічок” + “зелений водій”
  5. “зелений чоловічок миготить” + “червоний або жовтий водій”

Переходи: 1 --> 2 --> 3

  • Error Guessing – написання тестових сценаріїв на базі вгадування потенційних вразливостей та помилок.

    Чтобы найти баг, ты должен думать как баг

  • Exploratory

  • Pair-wise testing – Тестування унікальних пар. pairwise.org

OS win, mac, lin
Browser chrome, firefox, safari
DB db1, db2, db3
Locale EN, DE, UA
Total: 81 different env

Суть у тому, щоб не перебирати усі варіанти, а щоб перебрати таку кількість варіантів, щоб у них була кожна унікальна пара

OS Browser DB Loc
Win chrome db1 en
Win firefox db2 de
Win safari db3 ua
Mac chrome db2 ua
Mac firefox db3 en
Mac safari db1 de
Lin chrome db3 de
Lin firefox db1 ua
Lin safari db2 en

Таким чином замість 81, ми отримали 9 вибірок

Лекція 5. Тест-план

date: 2016-10-13 10:56:04 +0300

Існує стандарт для тестової документації: IEEE829

(Title, Author, Date created, Date modified, Content, Revision history)

  1. Introduction
  2. Features to be tested
  • launch app
  • open doc
  • save changes
  • fonts
  • …
  1. Features not to be tested
  2. Test Items – тут декомпозиція того, що ми будемо тестувати. Розглядаємо пункти Features to be tested дуже детально. Наприклад:
  • launch app
    • launch app on iPhone
    • launch app on Android
    • launch app on Linux
    • …
  • open doc
    • open doc with double click
    • open doc from within app
    • …
  • …

  1. Test approaches. Детальний опис того, яким чином буде проводитися тестування:

    Для кожного білда ми проводитимо smoke-testing. Щоб пришвидшити його, використовуємо автотести на Selenium Web-Driver. Тестуємо black-box способом. Потім додатково проганяємо unit-tests …

  2. Pass/Fail item criteria (acceptance criteria) I.E.

  • Tested on no less than 3 platforms;
  • All req are covered with all positive and no less than 2 negative tests
  • All defects with Blocker, Critical priority are fixed
  • No more than 2 medium priority defects
  • No more than 5 minor priority defects
  • …
  1. Suspension/Resumption criteria – умови призупинення/продовження тестування.
  2. Environmental needs
  3. Staff and training needs
  4. Tester’s tasks – Задачі тестувальника. Це більше як список обов’язків, яким, якщо що, можна прикрити 5ту точку.
  5. Test deliverables
  • test plan
  • test case
  • test report
  • list of bugreports
  • test automation framework
  • …

  1. Schedule – графік, що коли треба робити.

    stage dates
    analysis 12/10/16
    test planning nov 2016
    test design …
    test execution …
    regression …
    acceptance 1/2/2017 - 20/2/2017
    reporting …

  2. Responsibilities

    Who What Responsibilities
    Zhora manual QA test design, manual testing
    Vasya middle QA manual testing, reports
    Sergey QA Automation …

  3. Approvals

    Name Position Date Sign
    Vlad PO now vlad

  4. Risks Risks and how to deal with them.

  • Accepts
  • Transfer
  • Mitigate
  • Avoid

Лекція 6. Тестова документація

date: 2016-10-27 10:20:00 +0300

Тестова документація:

  1. Test plan
  2. Test report
  3. Test-case
  4. Checklist

Test-case

Test-case – документ, що містить послідовність кроків для перевірки одного критерію.

Структура документу:

  1. IDEA – власне, мета test-case. Наприклад:

    Проверить, как едет себя дверь комнаты 2-13 при попытке открыть её, не открыв замок

  2. Title – коротка назва документу. У зв’язку з тим, що у проектах зазвичай достобіса test-cases, є сенс якось осмислено і структуровано заповнювати це поле.

    2-13MDoorLockedOpen

  3. Pre-condition (optional) – описує дії, або умови, які не є частиною тесту, але є необхідними для його виконання

    1. The door is locked
    2. User is outside the room

  4. Steps – кроки тесту

    1. Подойди к двери
    2. Проверни дверную ручку по часовой
    3. Потяни дверь на себя
    4. Посмотри состояние двери

  5. Expected result

    Дверь не открылась и осталась целой

  6. (optional) Post-conditions – кроки для “чистки” після тесту

Однією з переваг test-case є простота створення bug-report

Checklist

Формат checklist:

ID Tester actions System Response (Expected result)
1 Open the home page Welcome text is displayed on top [menu][user][payments][settings] menu items are present Banner is displayed…
2 Click on [User] menu item Window with buttons [Log In] and [Sign Up] is displayed on screen
3 Click on [Sign Up] button “Registration: Step1” screen is opened; bla bla bla fields are displayed
4 Click on [Menu] >> Save as >> Save as pdf …
… … …

Лекція 7. Баг-репорт

date: 2016-11-10 10:49:37 +0200

Визначення

Bug Report
документ, який описує дефект у застосунку.
Дефект/Баг
невідповідність фактичного результату очікуваному.

Алгоритм поведінки при виявленні дефекту

  1. Занотувати, що відбулося
  2. Зробити скріншот або зняти невеликий скрінкаст; логи
  3. відтворити (двічі або тричі) – щоб зрозуміти, як часто відтворюється
  4. Комунікація з командою (може хтось щось про це знає)
  5. Пошук дуюблікатів у баг-трекері
  6. Локалізація дефекту (аналіз потенційних факторів, які впливають на відтворюваність багу)
  7. Пишемо Summary (заголовок/title). Хороший Summary відповідає на 3 питання:
  • Що?
  • Де?
  • Коли?
  1. Пишемо Issue Description і заносимо в баг-трекер

Приклад

Summary:
    Changes in HTML doc currently opened is not saved
    when [Save] button is clicked in Text Edit app

Environment:
    OS: any (MacOS, Win)
    Browser: Chrome, Firefox, Safari, Opera, IE (version any)

Build (version):
    Text Edit v1.1.23b

Priority: Medium / Major (пріоритет з точки зору бізнеса)
Severity: Medium (пріоритет з технічної точки зору)

Description:

    Pre-condition (optional):
        существует файл формата HTML, который коректно открывается
        в браузере и он сейчас открыт в браузере в система

    Steps To Reproduce:
        1. Launch text editor
        2. Open any html file that was previously opened in browser
        3. Make any changes in content HTML document;
        4. Save changes in document
        5. Reload page in your browser
        6. Observe the result on screen in your browser

    Actual result:
        Changes are not saved, previous version of HTML doc is displayed.

    Expected Result:
        The document is displayed without any corruptions
        and shows changes made during steps

    Additional info:
        if user closes browser and then click on [Save] button
        in Text Edit app - changes saved successfully.

Лекція 8. Веб-тестування

date: 2016-11-17 10:58:13 +0200

На передній план виходять

  • кросбраузерне тестування

    Наявність декількох різних браузерів (IE, Chrome, Firefox, Edge, Opera, Safari …) зумовлює необхідність перевірки коректності роботи функціоалу на різних браузерах

  • тестування продуктивності (performance testing)

    Передача даних по мережі сильно впливає на швидкодію.

  • тестування безпеки (security testing)

Авторизація/автентикація, передача авторизаційних даних по мережі, права доступу на сервери/до БД/тощо, налаштування файрволів…

Одним із засобів, що використовується для автоматизації веб-тестування є Selenium IDE