Меню

6 основних навичок, якими повинен володіти кожен тестер (головним чином, більш свіжий)

6 basic skills that every tester should have

Спробуйте Наш Інструмент Для Усунення Проблем

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

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

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

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

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

базові навички тестування

як витягти торрент-файли за допомогою 7zip - -

Давайте почнемо.

Що ви дізнаєтесь:

№1. Документація

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

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

Рекомендуємо прочитати=> Чому документація важлива при тестуванні програмного забезпечення

№2. Підготовка до тесту

З усіх доступних документів не можна нехтувати наступним. Вони також називаються документами, що доставляються, і вони об'єднують розуміння клієнта, розробника та тестувальника.

а) План випробувань: Діаграмує хід тестування від початку до кінця .

План випробувань відображає обсяг та діяльність етапу випробування. Створена керівництвом QA, команда повинна внести свій внесок і бути в курсі всього, що написано в плані тестування.

Деякі команди мають декілька рівнів планів випробувань: генеральний план та фазові плани.

План випробувань повинен мати:

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

Також читайте=>

чим відкрити файли jar

б) Сценарії випробувань:

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

Більшість із них містять:

  • Ім'я модуля / компонента / функції (вхід, адміністратор, реєстрація тощо)
  • Ідентифікатор сценарію є довідковим (наприклад, TS_Login_001)
  • Опис сценарію - „Що перевірити”, наприклад: перевірити, якщо вхід дозволяє користувачам із дійсними обліковими даними успішно входити
  • Важливість сценарію - Розставити пріоритети у випадку недостатнього часу - Високий / Середній / Низький
  • Ідентифікатор вимоги - для простежуваності

Подальше читання=>

в) Тестові кейси:

Точні тестові кейси дають точні результати тестування. Електронні таблиці все ще є популярним середовищем для написання тестових кейсів, особливо для початківців, хоча деякі компанії адаптують інструменти управління тестами. Основою для написання тестових кейсів є документ SRS / FRD / Req. Але цього буває недостатньо, тому вам доведеться використовувати багато припущень та обговорень з командами BA / Dev.

Написання ефективних тестових кейсів - це найважливіша кваліфікація, яку повинен мати тестувальник. Зазвичай усі тестові випадки класифікуються як позитивні / негативні. Позитивний тест дає достовірні дані та отримує позитивні результати. Негативний тест надає недійсні дані та отримує точне повідомлення про помилку.

Щоб отримати додаткову інформацію про них, перевірте:

Деякі загальні атрибути, які мають усі тестові приклади:

  • Ідентифікатор сценарію - взято з документа тестового сценарію
  • Ідентифікатор тесту - для унікальної ідентифікації та відстеження. Наприклад: TC_login_001
  • Опис тесту - Коротке пояснення випробуваного стану тесту
  • Кроки для виконання - Докладні покрокові інструкції щодо тестування
  • Дані тесту - Дані, що надходять на етапи тесту
  • Очікуваний результат - результат очікуваний
  • Фактичний результат - відповідь AUT під час запуску тесту
  • Стан - Передача / Помилка / Немає запуску / Неповна / Заблокована - описує результат тесту
  • Коментарі - До додаткових деталей
  • Виконав - ім’я тестувальника
  • Дата виконання - дата запуску тесту
  • Ідентифікатор дефекту - дефект реєструється у випадку тесту, у разі провалу тесту
  • Деталі конфігурації - ОС, браузер, платформа, інформація про пристрій (необов’язково)

Рекомендуємо прочитати=>

інструменти збору вимог, що використовуються бізнес-аналітиками

№3. Процес тестування - Які тести виконувати?

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

Наприклад: Якщо це портал Інтернет-торгівлі, то стрес-тестування та тестування навантаження є обов’язковими. Однак деякі типи тестів, які не можна пропускати:

No4. Тестування на частковій стадії розробки

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

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

№5. Звіт про помилку

На практиці, це найважливіший документ про якість, який ви коли-небудь створювали.

Нижче наведені поля, які повинен містити хороший звіт про помилки:

  • Ідентифікатор дефекту - Зазвичай серійний номер
  • Опис дефекту - Однорядкове пояснення проблеми
  • Розташування - Модуль / область AUT, де виявлена ​​проблема
  • Номер збірки - № збірки версії та коду.
  • Кроки для відтворення - Список кроків, які ведуть вас до проблеми
  • Серйозність - встановіть рівень для опису серйозності проблеми - низький, середній, високий, блокатор тощо.
  • Пріоритет - встановлюється розробниками для визначення порядку, в якому буде виправлено дефект (P1, P2, P3 тощо. P1 - найвищий)
  • Призначено - Власнику дефекту на той момент часу
  • Повідомляє - ім’я тестувальника
  • Статус - різний статус, який відображає стадію життєвого циклу помилки
    • Нове - Про помилку знайдено та щойно повідомлено
    • Відкритий - перевірено лідером контролю якості
    • Присвоєно - надіслано керівництву розробника для призначення відповідному розробнику
    • In Progress / Робота в процесі - Dev почав над цим працювати
    • Виправлено / вирішено - розробник закінчив працювати над цим
    • Підтверджено / закрито - команда контролю якості перевірила і виявила помилку виправленою
    • Повторне тестування - Команда QA не погоджується з дозволом Dev і надалі прогресує помилку для переробки
    • Дублікат - подібна помилка вже існує
    • Відкладено - допустима помилка, але її буде виправлено в наступних версіях
    • Недійсний - Немає помилки або не відтворюється, або недостатньо інформації

Подальше читання=>

№6. Процес виходу

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

Переконайтеся, що ви всі їх вичитуєте та надсилаєте остаточні версії.

Також читайте=>

Висновок

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

Нарешті, кар’єра в тестуванні стала для мене абсолютною радістю, і я сподіваюся, що для вас теж.

Усього найкращого для вашої кар’єри!

Рекомендована література

^