Ръководство за осигуряване на качеството на софтуера

Осигуряване на качеството

Осигуряването на качеството (известно като QA) е начинът, чрез който продуктът в разработка се проверява, за да се увери, че работи както трябва. Действителните методи, използвани в QA процесите, се различават значително в зависимост от размера и естеството на продукта.

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

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

Методологии

Пъргав

При подвижен подход към разработването целта е всеки цикъл на работа („спринт“) да създаде работещ софтуер, който може да бъде добавен и подобрен итеративно. Това прави QA процесите неразделна част от цикъла на развитие.

Чрез тестване на софтуерни компоненти на всеки етап от тяхното производство, вие намалявате риска от наличие на грешки при пускането.

Терминология

Тестване за автоматизация

Тестване, извършено с предварително написани скриптове, предназначени да контролират изпълнението на тестове.

Черна кутия

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

Дефект

Всяко отклонение от спецификациите на приложението; често наричан „бъг“.

Изследователско тестване

Нескриптен подход към тестването, който разчита на уникалната креативност на тестера в опит да намери неизвестни грешки и да идентифицира регресиите.

Тестване на интеграцията

Тестване на отделни компоненти / модули заедно, за да се гарантира, че те се свързват и взаимодействат добре един с друг.

Тестване на отрицателен път

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

Тестване на регресия

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

Тестове за дим

Минималистичен подход към тестването, предназначен да гарантира, че основната функционалност работи, преди да се извърши по-задълбочено тестване. Обикновено се случва в началото на процеса на тестване.

Тестов случай

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

Бяла кутия

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

Известен също като „Стъклена кутия“, „Ясна кутия“, „Прозрачна кутия“, тъй като тестерът може да „види вътре“ системата, която се тества.

Основните категории са

  • Единични тестове (отделни единици код правят това, което трябва)
  • Тестове за интеграция (единици / компоненти си взаимодействат правилно)
  • Регресионни тестове (повторно прилагане на тестове на по-късни етапи от разработването, за да се гарантира, че те все още работят)

Има три основни техники:

  • Разделяне на еквивалентност (тестваните входни стойности са представителни за по-големи набори от входни данни)
  • Анализ на граничната стойност (системата се тества с избрани входове, където поведението и следователно изходът трябва да се промени)
  • Графика на причинно-следствените ефекти (тестовете са проектирани от визуализация на връзките вход-изход)

Други ресурси

  • Как да напиша QA документация, която всъщност работи
  • Разработване с тест
  • Единични тестове