Меню

6 основни умения, които всеки тестер (главно по-свеж) трябва да притежава

6 basic skills that every tester should have

Опитайте Нашия Инструмент За Премахване На Проблемите

Софтуерното тестване или QA е най-добрата платформа за новодошлите да влязат в ИТ индустрията въпреки погрешните схващания, че това е по-малко или по-ниско платена работа.

Най-важното умение, от което изпитващият се нуждае, е възможност за намиране на грешки . И ако сте човекът, който обича да открива грешки, тогава ще обичате и ще растете в тази област.

как да използвам assert в c ++

Като казах това, има малко повече умения, които могат да ви помогнат да намерите грешки и да работите по-добре с QA процесите.

Това е статията, която ще покаже процеса на осигуряване на качеството, както се следва в повечето компании, и ще даде разяснения на нови тестери относно тестването.

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

основни умения за тестване

Нека да започнем.

Какво ще научите:

# 1. Документация

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

Също така, уверете се, че виждате стойността на процеса на документиране. Предимствата са много - те ви помагат да проследявате промените в изискванията, да проследявате стъпките на теста, да регистрирате работата си и т.н.

Препоръчително четиво=> Защо документацията е важна при тестването на софтуер

# 2. Подготовка на теста

От всички налични документи следното не може да бъде пренебрегнато. Те също се наричат ​​документи за доставяне и свързват разбирането на клиента, разработчика и тестера.

а) План за тестване: Начертава потока от тестове от началото до края .

Тестовият план описва обхвата и дейностите на фазата на тестване. Създаден от QA ръководството, екипът трябва да допринесе и да бъде в течение за всичко, което е записано в плана за тестване.

Някои екипи имат няколко нива на тестови планове: генерален план и фазови планове.

Планът за изпитване трябва да съдържа:

  • Име и версия на проекта
  • Идентификатори на тестовия план - Създател, номер на проект, дата на създаване и др.
  • Въведение - Преглед на проекта, цел и ограничения
  • Референции - Списък с референции, използвани като вход (уверете се, че използвате точните и най-новите версии)
  • Тестови елементи - Модули, версия, обхват, извън обхвата и т.н.
  • Цялостен подход на теста / Тестова стратегия - Инструменти за използване, процес на проследяване на дефекти, нива на тестване за изпълнение и т.н.
  • Критерии за успешно преминаване / неуспех - Указания за изпълнение на теста
  • Критерии за спиране и възобновяване
  • Резултати от теста - Тестови случаи, протоколи от тестове, доклад за грешки, показатели на теста и др.
  • Подробности за тестовата среда
  • Екипен списък с информация за точка за контакт. за всеки модул или тип тестване
  • Тестови оценки - Време и усилия. Подробностите за бюджета са поверителни и няма да ги намерите тук
  • Рискове и планове за смекчаване
  • Одобрения
  • Други насоки

Прочетете също=>

б) Тестови сценарии:

Едноредов указател за „какво да тествате“ въз основа на всяко изискване и обикновено се документира и проследява чрез електронни таблици.

Повечето от тях съдържат:

  • Име на модул / компонент / функция (вход, администратор, регистрация и др.)
  • Идентификаторът на сценария е за справка (напр. TS_Login_001)
  • Описание на сценария - „Какво да тествате“ Например: Проверете дали входът позволява на потребителите с валидни идентификационни данни да влизат успешно
  • Важност на сценария - Приоритизиране в случай на недостатъчно време - Високо / Средно / Ниско
  • Идентификационен номер - За проследимост

Допълнителна информация=>

в) Тестови случаи:

Точните тестови случаи дават точни резултати от теста. Електронните таблици все още са популярната среда за писане на тестови случаи, особено за начинаещи, въпреки че някои компании адаптират инструментите за управление на тестове. Основата за писане на тестови казуси е документът SRS / FRD / Req. Но това не е достатъчно често, така че ще трябва да използвате много предположения и дискусии с BA / Dev екипи.

Писане на ефективни тестови случаи е най-важната квалификация, която изпитващият трябва да притежава. Обикновено всички тестови случаи се категоризират като положителни / отрицателни. Положителен тест дава валидни данни и получава положителни резултати. Отрицателен тест дава невалидни входове и получава точното съобщение за грешка.

За повече информация относно тях проверете:

Някои от често срещаните атрибути, които имат всички тестови случаи са:

  • Идентификатор на сценария - Взето от документа на тестовия сценарий
  • ID на тестовия случай - за уникална идентификация и проследяване. Например: TC_login_001
  • Описание на теста - Кратко обяснение на тестваното състояние на теста
  • Стъпки за изпълнение - Подробни инструкции стъпка по стъпка как да тествате
  • Тестови данни - Данни, предоставени на тестовите стъпки
  • Очакван резултат - Резултат, както се очаква
  • Действителен резултат - отговор на AUT при стартиране на теста
  • Състояние - успешно / неуспешно / без изпълнение / незавършено / блокирано - описва резултата от теста
  • Коментари - До допълнителни подробности
  • Изпълнено от - името на тестера
  • Дата на изпълнение - дата, на която се изпълнява тестът
  • Идентификатор на дефекта - Дефект, регистриран срещу тестовия случай, в случай на неуспех на теста
  • Подробности за конфигурацията - OS, браузър, платформа, информация за устройството (по избор)

Препоръчително четиво=>

# 3. Процес на тестване - Какви тестове да извършите?

Има огромен брой видове тестове, но не всички от тях могат да бъдат извършени на този AUT. Времето, бюджетът, естеството на бизнеса, естеството на приложението и интересът на клиента са ключовите играчи при избора на това какви тестове да се направят на приложението.

Например: Ако това е портал за онлайн търговия, тогава стрес тестовете и тестовете за натоварване са задължителни. Някои от видовете тестове обаче, които не бива да се пропускат, са:

# 4. Тестване на етапа на частично развитие

Като цяло, при средно ниво и стартиращи компании, има ограничено време и ресурси. Тук тестерите може да започнат своя процес на тестване преди интеграцията на модула, което означава, че може да правим тестове за интеграция на модули и посредници.

Важно е да се отбележи, че резултатите от тези етапи не могат да бъдат отчетени като точни, така че може да се наложи да планирате цялостен тест за черна кутия, след като всичко е готово за работа. Пренебрегването на тази част може да се окаже скъпо и тестването е неефективно.

# 5. Доклад за доклад за грешка

Ръчно, това е най-критичният документ за осигуряване на качеството, който някога ще правите.

По-долу са полетата, които трябва да има добър доклад за грешка:

  • Идентификационен номер на дефект - Обикновено сериен номер
  • Описание на дефекта - едноредово обяснение на проблема
  • Местоположение - Модул / област на AUT, където е открит проблемът
  • Номер на компилация - Версия и код на компилация.
  • Стъпки за възпроизвеждане - Списък на стъпките, които ви водят до проблема
  • Тежест - Задайте ниво, за да опишете сериозността на проблема - Нисък, среден, висок, блокиращ и т.н.
  • Приоритет - зададен от разработчиците за определяне на реда, в който ще бъде отстранен дефектът (P1, P2, P3 и др. P1 - най-висок)
  • Възложено на - Собственик на дефекта към този момент от времето
  • Съобщено от - Име на тестера
  • Състояние - Различен статус, който представлява етапа на жизнения цикъл на грешките
    • Ново - Грешката е намерена и току-що е съобщена
    • Отворено - Утвърдено от QA олово
    • Присвоено - изпратено до водещия за разработчици за възлагане на съответния разработчик
    • In Progress / Работа в процес - Dev започна да работи по нея
    • Поправено / Решено - Разработчикът е приключил да работи по него
    • Проверено / затворено - Екипът на QA е тествал отново и е открил грешката
    • Повторно тестване - Екипът на QA не е съгласен с резолюцията на Dev и допълнително прогресира грешката за преработка
    • Дубликат - Подобна грешка вече съществува
    • Отложено - валидна грешка, но ще бъде коригирана в по-късните версии
    • Невалидно - Няма грешка или не е възпроизводимо или няма достатъчно информация

Допълнителна информация=>

# 6. Процес на излизане

Отпиши ме и изпращането на окончателна документация е задачата на QA Lead / Manager. Въпреки това, екипът трябва да представи горепосочените документи (Тестов сценарий, Тестово дело и документ за дефекти) за окончателни прегледи и одит.

Уверете се, че сте коригирали всички и изпратите окончателните версии.

Прочетете също=>

Заключение

Това е процесът, на който бях свидетел и преживях от първа ръка, когато бях тестер и се надявам, че това ви е дало някои полезни насоки.

И накрая, кариерата в тестването беше абсолютна радост за мен и се надявам да бъде и за вас.

Всичко най-добро за вашата кариера!

Препоръчително четене

^