QA Kickstart: 7-дневный тренинг для начинающих

  • Определение тестирования и его роли в разработке ПО
  • Основные виды тестирования: функциональное, нагрузочное, регрессионное и др.
  • Жизненный цикл разработки ПО и позиция тестирования в нём
  • Инструменты и технологии, используемые в тестировании
  • Створення тест-кейсів та тест-сьютів
  • Використання трекінгових систем для управління дефектами
  • Створення тестових планів та звітів
  • Работа с Agile-методологіями розробки

Вступление до основ тестирования ПО

Створення тест-кейсів та тест-сьютів

Test-Case


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

Матриця покриття

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

Test-Suite

Test-Suite (Тест-сюїт) – це колекція тест-кейсів, які групуються разом з метою організації та керування тестуванням. Він може містити набір тест-кейсів, які перевіряють певну функціональність, модуль або сценарій взаємодії.

Давайте переглянемо презентацію

або відкрити у новій вкладці  Google Презентація

Для отримання додаткового матеріалу потрібно перейти за посиланням 
Google Drive
Google Drive

Test Case ID: TC001
Test Case Title: Login Functionality – Valid Credentials
Priority: High

Preconditions:

  1. The application is installed and running properly.
  2. Valid user credentials (username and password) are available.

Test Steps:

  1. Open the application login page.
  2. Enter a valid username in the “Username” field.
  3. Enter a valid password in the “Password” field.
  4. Click on the “Login” button.
  5. Verify that the user is successfully logged in and redirected to the home page.
  6. Check that the accurate user name or profile picture is displayed on the home page.
  7. Verify that all the expected elements or sections for an authenticated user are visible and functional.
  8. Perform any specific actions available to an authenticated user (e.g., create a new post, send a message).
  9. Logout from the application.
  10. Verify that the user is successfully logged out and redirected to the login page.

Expected Results:

  1. The login page should open without any errors.
  2. The valid username should be entered accurately.
  3. The valid password should be entered accurately.
  4. Clicking on the “Login” button should initiate the login process.
  5. After successful login, the user should be redirected to the home page.
  6. The accurate username or profile picture should be displayed on the home page.
  7. All expected elements or sections for an authenticated user should be visible and functional.
  8. Any specific actions available to an authenticated user should work as expected.
  9. Logging out from the application should be successful.
  10. After successful logout, the user should be redirected to the login page.

Метод "Еквівалентні значення"

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

Метод "Граничні значення"

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

Метод "Умовні комбінації"

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

Метод "Структуроване тестування"

 цей метод використовується для тестування на основі структури програмного коду. Він дозволяє забезпечити високу покриття коду тестами та виявити можливі помилки на ранніх етапах розробки. Метод включає такі підходи, як тестування рішень прийняття рішень (decision testing), тестування границь (boundary testing), тестування ітерацій (loop testing) та інші.

Метод "Тестування залежностей"

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

Метод "Стрес-тестування"

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

Метод "Автоматизоване тестування"

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

Метод "Специфікаційне тестування"

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

Метод "Тестування з використанням випадкових величин"

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

Метод "Тестування з використанням регресійного аналізу"

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

Для отримання додаткового матеріалу потрібно перейти за посиланням 
Google Drive

Використання трекінгових систем для управління дефектами

Для отримання додаткового матеріалу потрібно перейти за посиланням 
Google Drive

або відкрити у новій вкладці  Google Презентація

Створення тестових планів та звітів

Створення тестових планів

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

 

Створення звітів про тестування

  1. Виконання тестових сценаріїв: Виконайте заплановані тестові сценарії та документуйте результати. Запишіть як успішно пройдені тести, так і виявлені проблеми або дефекти.
  2. Визначення статусу тестів: Після виконання тестів визначте їх статус, наприклад, пройдено успішно, неуспішно або з блокуванням. Це допомагає відстежувати загальний прогрес тестування.
  3. Документація дефектів: Запишіть всі виявлені дефекти або проблеми з відповідним описом, кроками відтворення, пріоритетом, відповідальними особами та іншою додатковою інформацією.
  4. Аналіз результатів: Проаналізуйте зібрані дані та зробіть висновки про якість програмного забезпечення, виявлені проблеми, їх пріоритети та загальну відповідність вимогам.
  5. Створення звітів: Підготуйте звіти про тестування, включаючи огляд виконаних тестів, статус, виявлені дефекти, рекомендації та іншу важливу інформацію. Звіти повинні бути зрозумілими та зручними для подальшого аналізу та прийняття рішень.

 

Більше інформації про тест-план

Для отримання додаткового матеріалу потрібно перейти за посиланням 
Google Drive

або відкрити у новій вкладці  Google Презентація

Работа з Agile-методологіями розробки

Скрам (Scrum)

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

Канбан (Kanban)

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

Екстримальне програмування (Extreme Programming, XP

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

 

Більше інформації про Agile

Для отримання додаткового матеріалу потрібно перейти за посиланням 
Google Drive

або відкрити у новій вкладці  Google Презентація

Відгадай

Відповіді надіслати в телеграм бот

Я створюються для перевірки,
Усі кроки, критерії – відповідки.
Виконуються послідовно, крок за кроком,
Щоб тестування було бездоганним і точним.
Що я таке?

Я – набір тестів, спрощений або складний,
До нього входять різні тест-кейси.
Дозволяють організувати й структурувати,
Тестування і його керувати.
Що я таке?

Мене створюють відповідно до потреб,
У мене можуть бути тест-кейси різних типів.
Я групую їх в залежності від мети,
І покращую ефективність тестування це відомо кожній людині.
Що я таке?

Надайте відповіді

Відповідайте своїми словами коротко. Відповіді надіслати в телеграм бот або в скайп групу

  1. Що таке тест-кейс і як він використовується в процесі тестування програмного забезпечення?
  2. Які основні компоненти входять до складу тест-кейсу?
  3. Які критерії повинні бути враховані при створенні ефективного тест-кейсу?
  4. Яким чином тест-кейси допомагають у покритті функціональності та вимог програмного забезпечення?
  5. Як організувати тест-кейси для більшого розуміння та легкого використання командою тестувальників?
  6. Які стратегії можна застосовувати для створення тест-кейсів у великих проектах?
  7. Як вибрати найважливіші тест-кейси для включення до тест-сьюту?
  8. Як оцінити покриття тест-кейсами і як впевнитися, що всі аспекти програмного забезпечення враховані?
  9. Чи можна автоматизувати виконання тест-кейсів і як це може збільшити ефективність тестування?
  10. Які кращі практики та методології можна використовувати для створення та управління тест-кейсами і тест-сьютами?

Написати тест-кейси

Створіть google doc та надайте доступ на перегляд  ваших тест-кейсів.
Відправити посилання в телеграм бот або в скайп.

Вимоги до форми контакту на веб-сторінці: https://theconnectedshop.com/pages/contact-us

  1. Функціональні вимоги:

    • Форма контакту повинна містити наступні поля: ім’я (від 2-50 символів), електронна пошта, номер телефону, повідомлення(від 2-250 символів).
    • Всі поля, крім номера телефону, є обов’язковими для заповнення. При спробі відправити форму зі звільненими обов’язковими полями, система повинна надати попередження та не допустити відправку.
    • Для поля електронної пошти, система повинна перевірити правильність формату електронної пошти та попередити користувача про некоректно введений електронний адрес.
    • Після успішної відправки форми, система повинна показати підтвердження та надіслати автоматичний лист на вказану електронну адресу користувача з підтвердженням отримання повідомлення.
  2. Нефункціональні вимоги:

    • Дизайн форми повинен бути зручним та інтуїтивно зрозумілим для користувачів.
    • Всі поля форми повинні бути видимими та доступними для користувача навіть на мобільних пристроях.
    • Форма повинна бути захищена від спаму та ботів, наприклад, за допомогою CAPTCHA або інших анти-спам заходів.
    • Відправлені повідомлення повинні зберігатися у базі даних з можливістю відновлення та відстеження історії комунікації з клієнтами.
    • Час відповіді системи на відправку форми має бути прийнятним та не перевищувати 10 секунд.
  3. Вимоги до безпеки:

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

День 1

Вступление до тестирования

Начать обучение

День 2

Типы тестирования

Начать обучение

День 4

Тестирование веб-приложений

Начать обучение

Мы также присутствуем в социальных сетях! Подписывайтесь на нас и получайте последние новости, акции, скидки, бесплатные тренинги и участие в марафонах.
Будем рады видеть вас в нашем сообществе!

Курсы

Авторское право © 2023 Школа подготовки тестировщиков