← Academy Blog

Марафон підготовки 2022

Translated into:

Стартував марафон підготовки до тестів - QA трек - Binary Studio Academy 2022! Щотижневі питання з відповідями та пояснення чекають на нашому блозі.

  • [QA] Скільки тестів потрібно для досягнення 100% покриття рішень?
    function WhatIsGreater(a, b) {
      let result;
      if (a > b) {
        result = 'a is greater than b';
      }
      if (b > a) {
        result = 'a is less than b';
      } else {
        result = 'friendship :)';
      }
      return result;
    }

    a) Достатньо 1-го тесту
    b) Для повного покриття потрібно 2 тести
    c) Неможливо визначити необхідну кількість тестів через брак інформації
    d) Потрібно 3 тести

    Розгорнути правильну відповідь з поясненням

    To answer this question you need to know the basics of flowcharts. Flowcharts use special shapes to represent different types of actions or steps in a process.

    Process Code

    Завдяки блок-схемі ми зможемо наглядно побачити роботу нашого коду та проаналізувати скільки тестів потрібно для досягнення 100% покриття рішень (Decision/Branch coverage). Основна мета Decision/Branch coverage - охопити всі гілки хоча б один раз (true і false). Тобто потрібно знайти та покрити мінімальну кількість шляхів.

    Зображення нашого коду у вигляді блок-схеми:

    Our Code

    Таким чином, ми маємо 3 гілки, кількість тест кейсів для яких - 3:

    1. Перший - перевіряє що, якщо WhatIsGreater(2, 1), тоді в результаті виконання if (a > b) ми отримаємо 'a is greater than b'.
    2. Другий - дозволяє впевнитись що, якщо WhatIsGreater(1, 2), то программа пройде if (b > a), та в результаті буде 'a is less than b'.
    3. Третій тест кейс - перевіряє, що в інших випадках результат 'friendship :)'. Тобто, якщо параметри будуть однакові WhatIsGreater(2, 2), то отримаємо 'friendship :)'

    Для досягнення 100% покриття рішень нам потрібно 3 тест кейси.

  • [QA] Одна із частин роботи QA - тестування вимог. Проаналізуйте вимоги нижче. Як вважаєте, що з ними не так?
    1. Система повинна бути зручною та доступною.
    2. Має бути спосіб аутентифікації.
    3. Необхідно створити систему підтримки з чатом, контактною формою та допомогою для авторизованих користувачів.
    4. Неавторизований користувач може скористатись чатом та контактною формою.
    5. Студент увійде до системи, вказавши своє ім'я користувача або/та емейл, пароль та іншу відповідну інформацію.
    6. Час завантаження кожної сторінки мусить бути прийнятним.
    Розгорнути правильну відповідь з поясненням

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

    Під час тестування вимог ми мусим звертати увагу на:

    • однозначність вимог та їх повноту - кожен повинен розуміти вимоги однаково;
    • несуперечливість;
    • необхідність вимог та можливість їх реалізації;
    • можливість перевірки встановлених вимоги після їх реалізації.
    1. Система повинна бути зручною та доступною.

    Зручний для кого та що означає доступний? Вимозі бракує чіткості та однозначності. Різні люди по різному сприймають та тлумачать ці слова.

    1. Має бути спосіб аутентифікації.

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

    1. Необхідно створити систему підтримки з чатом, контактною формою та допомогою для авторизованих користувачів.

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

    1. Неавторизований користувач може скористатись чатом та контактною формою.

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

    1. Студент увійде до системи, вказавши своє ім'я користувача або/та емейл, пароль та іншу відповідну інформацію.

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

    1. Час завантаження кожної сторінки мусить бути прийнятним.

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

    Крім того, сторінка повинна завантажуватись у прийнятні терміни, а які прийнятні терміни? Прийнятні для кого?

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

  • [QA] В БД є таблиця Contact, де зберігаються: ім`я користувача, дата народження та місто, де користувач проживає.Weekly Challenge

    QA Table

    Завдання цього тижня:

    • Вивести ім'я (Name) та дату народження (BirthDate) всіх контактів (табл. Contact), у яких в імені друга літера "a". Вибірку відсортувати за зменшенням дати народження (BirthDate).
    • У таблиці Contact у контакта Lena змінити значення: BirthDate = 1987-10-08 та UsrCityLiving = Харків.
    • До таблиці Contact додати новий контакт: Name = Alex, BirthDate = 1986-10-08, UsrCityLiving = Київ.
    Розгорнути правильну відповідь з поясненням
  • [QA] Що таке верифікація?
    1. Перевірка, що програмне забезпечення реалізоване у відповідності із дизайном.
    2. Перевірка, що програмне забезпечення задовольняє вимоги та очікування замовника.
    3. Перевірка, що програмне забезпечення задовольняє вимоги та очікування користувачів.
    4. Перевірка, що програмне забезпечення реалізоване у відповідності з очікуваними вимогами.
    Розгорнути правильну відповідь з поясненням

    Давайте пригадаємо що таке Verification та Validation.

    Verification. Відповідає на запитання “Функціональність працює відповідно до вимог?”. Verification - процес оцінки системи і її компонентів з метою співставлення результатів поточного етапу розробки, початково сформованим умовам. Тобто, виконання заданих завдань, цілей, строків по розробці продукту та відповідність стандартам.

    Validation. Відповідає на запитання: “Чи очікуємо ми того, що очікує користувач?”. При процесі валідації переконуємось, що розроблене програмне забезпечення відповідає визначеним бізнес-вимогам та потребам користувачів.

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

  • [QA] На цьому тижні ми попрактикуємось у визначенні пріоритетів для тест кейсів. Терміни завершення тестування часто жорсткі. В таких випадках є ризик пропустити тестування деяких важливих функцій. Тому варто визначати пріоритет кожного тесту під час його документування.Weekly Challenge

    Об’єкт:

    Інтернет-магазин

    Статус:

    На етапі розробки, але вже готові: головна сторінка з товарами; каталог з категоріями товарів; картки для кожного товару з фото (з можливістю zoom); сторінки товару; пошук по товарам; фільтри (ціна, виробник); сортування за ціною; кошик з можливостями змінити кількість товару, видалити товар; сторінка оформлення замовлення; інтеграція з платіжною системою, надсилання на електронну скриньку листа з деталями замовлення.

    Вимоги замовника:

    • Користувач повинен бачити на головній сторінці інтернет-магазину акційні товари.
    • Прев’ю картки товару повинно містити:
      • фото
      • ціну
      • кнопку “У кошик”
    • Після натискання на картку, відкривається сторінка товару з:
      • описом
      • ціною
      • фото
      • можливістю додати товар у кошик.
    • У кошику користувач повинен мати змогу:
      • видалити товар
      • змінити його кількість
      • мати кнопку “Оформити замовлення”.
    • На сторінці оформлення замовлення повинні бути вибір типу оплати:
      • онлайн оплата карткою
      • накладений платіж
      • та один тип доставки - забрати у відділенні пошти.
    • Також на сторінці оформлення повинні бути наступні елементи:
      • поле “Email”
      • поле “Номер телефону”
      • кнопка “Придбати”.
    • Якщо користувач вибрав оплату карткою, то після натиску на кнопку “Придбати” система переадресовує його на сторінку оплати, де потрібно ввести дані банківської картки.
    • Після оформлення замовлення на електронну скриньку користувача повинен прийти лист з деталями замовлення.

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

    Класифікація визначення пріоритету тесту, якою ми будем користуватися:

    • Високий (High): Тести охоплюють критичну функцію програми, схильні до дефектів модулі та модулі, в які були внесені нещодавні зміни.
    • Середній (Medium): Тести включають негативні тестові сценарії. До цієї категорії включені перевірки полів, тестові приклади генерації повідомлень про помилки.
    • Низький (Low): Тести охоплюють функціональність програми, що залишилася (включаючи користувальницький інтерфейс і менш схильні до дефектів модулі).

    Розставте пріоритет наступним перевіркам:

    1. Відображення акційних товарів на головній сторінці.
    2. Відображення відповідної категорії товарів на сторінці вибраної категорії з каталогу товарів.
    3. Сортування за ціною.
    4. Відображення відповідних товарів на екрані користувача після пошуку.
    5. Фільтрація по ціні, виробнику.
    6. Можливість збільшити/зменшити фото у картці товара.
    7. Відображення опису товара, ціни.
    8. Додавання товара у кошик, видалення товара з кошику.
    9. Відповідність ціни товара у кошику тій, що зазначена у картці.
    10. Валідація полів “Email” та “Номер телефону” на сторінці оформлення замовлення.
    11. Перехід до сторінки онлайн оплати карткою.
    12. Перехід з кошика до сторінки оформлення замовлення після натискання на кнопку “Оформити замовлення”.
    13. Надходження на електронну скриньку листа з деталями замовлення на пошту після успішного замовлення товару та наявність у листі інформації про деталі замовлення.
    Розгорнути правильну відповідь з поясненням
  • [QA] Retesting чи Regression?

    Поміркуйте та дайте відповідь, які з цих тверджень відносяться до Retesting, а які до Regression:

    1. Мета цього теста полягає в тому, щоб переконатися, що додавання свіжого коду, удосконалення або виправлення помилок не спричиняє нестабільності чи компрометації функціональності програмного забезпечення.
    2. Під час цього тестування тестувальники перевіряють, що всі тестові випадки, які виявилися невдалими під час останнього виконання, пройшли після усунення дефектів.
    3. Це тестування не включає перевірку дефектів.
    4. Цей тип тестування гарантує, що зміни в коді не вплинуть на функціональність системи.
    5. Це тестування можливо автоматизувати.
    6. Цей тип тестування проводиться після усунення дефектів.
    7. Тестові випадки, які загалом провалилися, піддаються такому типу тестування.
    8. Тестові випадки, які проходять у загальному порядку, піддаються такому типу тестування.
    Розгорнути правильну відповідь з поясненням

    Retesting - вид тестування, під час якого перевіряють, що всі тестові випадки, які виявилися невдалими під час останнього виконання, пройшли після усунення дефектів.

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

  • [QA] Цього тижня завдання полягає у пошуку багів та створенні баг-репортів. На скрині зображена проста логін-форма. Користувач відкрив сайт перейшов до логін-форми, не ввів електронну адресу, але ввів пароль. Також переглянув відповідність символів паролю, натиснувши на іконку “Show”, а потім - скрив пароль. Weekly Challenge

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

    Register form

    Розгорнути правильну відповідь з поясненням
  • [QA] Під час тестування застосунку для здорового харчування було виявлено 200 критичних багів за перші 20 спринтів. За наступні 20 спринтів без зміни QA команди та підходу то тестування було знайдено 25 критичних багів, проте клієнти почали скаржитись на різні дефекти, які вони знаходили під час користування новими версіями. Який з принципів тестування наглядно спостерігається у наведеному прикладі?

    a) Повне тестування неможливе
    b) Парадокс пестициду
    c) Тестування залежить від контексту
    d) Відсутність помилок оманлива
    e) Користувачі завжди скаржаться

    Розгорнути правильну відповідь з поясненням

    Давайте пригадаємо 7 принципів тестування

    Тестування показує наявність дефектів, а не їх відсутність

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

    Вичерпне тестування неможливе

    Як би нам не хотілося вірити чи бажати, щоб це було правдою(!), протестувати ВСЕ – усі комбінації вхідних даних та передумов абсолютно неможливо. Для найпростішого функціоналу це реальніше, але таке тестування було б дуже не ефективним та надзвичайно коштовним.

    Раннє тестування економить час і гроші

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

    Дефекти групуються разом

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

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

    Контест використання застосунку буде визначати типи та види тестування. До прикладу cloud версія застосунку потребує тестування навантаження від тисяч користувачів, а от standalone версія, яка встановлюється користувачем у себе на комп’ютері - ні.

    Відсутність помилок є оманою

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

    Парадокс пестициду

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

    Вірна відповідь - парадокс пестициду :)

  • [QA] Завдання цього тижня орієнтоване на те щоб потренувати свої QA skills та вирішити досить просту, на перший погляд, задачу. Наша задача протестувати ліфт в багатоповерховому будинку з офісними приміщеннями. Всього в будинку 10 поверхів. Ліфт має вантажопідйомність до 500 кг.Weekly Challenge

    Підказка: очікуємо побачити застосування різних видів тестування.

    Розгорнути правильну відповідь з поясненням