Преди софтуерът да бъде изпратен за публична или търговска употреба, програмистите прекарват часове в изглаждане на всяка грешка, като продуктът остава в неопределеност, докато всички заинтересовани страни не бъдат удовлетворени.
Софтуерните гиганти от Силициевата долина като Google и Facebook често ще доставят популярни продукти на пазара въпреки грешките с нисък приоритет в техния софтуер. Инвеститорите и милионите лоялни потребители ще толерират софтуерни актуализации и временни пречупвания в продуктите, предлагани от тези компании.
Повечето софтуерни компании нямат този лукс. Клиентите искат продуктите да се представят според рекламите и с право са разтревожени, ако има нерешени уязвимости.
Защо са необходими тестови умения?
С толкова много налични опции за разработка на софтуер, клиентите не се замислят дали да се откажат от кораба, ако продуктът мирише на загубено време и пари. Софтуерните фирми трябва да извършват стриктно тестване на своите продукти, преди да ги пуснат на клиенти. Тези тестове предлагат следната информация:
- Те подчертават разликите между оригиналната концепция и крайния резултат.
- Те проверяват дали софтуерът работи, както са планирали дизайнерите.
- Те оценяват характеристиките и качеството.
- Те потвърждават, че крайният продукт отговаря на изискванията на клиента.
Тестването следва строг план за оптимизиране на натоварването, времето и парите, като същевременно предоставя на заинтересованите страни съществена информация за придвижване на продукта напред. Целта е да се улесни положителното изживяване на крайния потребител, като се поддържа задълбочен осигуряване на качеството (QA) програма. Предвид високите залози за разработчиците, QA мениджърите са едни от тях най-добре печелещите в технологичната индустрия. Тестването обикновено следва следните стъпки:
- Извършете анализ на изискванията, където мениджърите очертават план за въвеждане на подходяща тестова стратегия.
- Започнете тестове и анализирайте резултатите.
- Коригирайте всички дефекти и подложете софтуера на регресионно тестване (система за проверка дали програмата все още работи след модификации).
- Създайте доклад за приключване на теста, описващ подробно процеса и резултатите.
Физическите лица могат да станат сертифицирани софтуерни тестери чрез BCS, The Chartered Institute for IT, ISTQB (Международен съвет за квалификации за тестване на софтуер) и ASQ (Американско общество за качество).
Методи за тестване на софтуер
Тестването в черна и бяла кутия са два основни метода за преценка на поведението и производителността на продукта. Тестването на черна кутия, наричано също функционално или базирано на спецификация тестване, се фокусира върху изхода. Тестерите не се интересуват от вътрешните механизми. Те само проверяват дали софтуерът прави това, което трябва да прави. Познаването на кодирането не е необходимо и тестерите работят на ниво потребителски интерфейс.
Тестването с бяла кутия използва опит в кодирането като част от тестовата процедура. Когато даден продукт се провали, тестерите навлизат дълбоко в кода, за да намерят причината. Разработчиците на софтуер ще направят това сами, защото клиентите очакват от тях да накарат продукта да работи. Тестването на бяла кутия се нарича още "базирано на структура" или "стъклено" тестване.
Статичното тестване проверява изходния код и всяка придружаваща документация, но не изпълнява програмата. Статичните тестове започват в началото на разработката на продукта по време на процеса на проверка.
Динамичното тестване използва различни входове, когато софтуерът работи, а тестерите сравняват резултатите с очакваното поведение. Тестването на графичния потребителски интерфейс оценява форматирането на текст, текстови полета, бутони, списъци, оформление, цветове и други елементи на интерфейса. Тестването на графичния интерфейс отнема много време и компаниите на трети страни често поемат задачата вместо разработчиците.
Тестови нива
Използват се различни нива на тестване за идентифициране на области на слабост и припокриване във всяка фаза на жизнен цикъл на разработка на софтуер. Нивата на теста са:
- Единичен тест
- Интеграционно тестване
- Тестване на системата
- Тестване за приемане
При модулно тестване разработчиците тестват най-основните части на кода, като класове, интерфейси и функции/процедури. Те знаят как трябва да реагира кодът им и могат да правят корекции в зависимост от изхода.
Интегрираното тестване е известно още като "модулно" или "програмно" тестване. Подобно е на модулното тестване, но съдържа по-високо ниво на интеграция. Модулите на софтуера се тестват за дефекти, за да се провери тяхната функция. Интеграционното тестване идентифицира грешки, когато модулите се интегрират. Различните методи за интеграционни тестове включват "отдолу нагоре", "отгоре надолу" и "функционално инкрементално".
Системното тестване тества компонентите на проекта като цяло в различни среди. Тестването на системата попада в метода на черната кутия и е един от последните тестове в процеса. Той ще определи дали системата е готова да посрещне нуждите на бизнеса и потребителите.
Обикновено има два вида тестове за приемане. При алфа тестване софтуерът се изпълнява вътрешно на сайта на разработчика в симулирана или реална среда. Софтуерът работи така, сякаш го използват живи крайни потребители. Разработчиците отбелязват всички проблеми и започват да коригират грешки и други проблеми.
Също така в обхвата на тестването на черна кутия, при тестването за приемане, клиентите тестват софтуера, за да разберат дали разработчикът е разработил напълно програмата, за да отговаря на желаните от тях спецификации.
Бета тестването или тестването на място позволява на клиентите да тестват продукта на своите сайтове в реални условия. Клиентите могат да предложат на група крайни потребители възможността да тестват софтуера чрез предварителни или бета версии. Бета тестването има за цел да получи действителна обратна връзка от потребителите, която се изпраща на разработчика.
Типове тестове
Различните видове софтуерни тестове са предназначени да се фокусират върху конкретни цели. Тестовият инженер и мениджърът на конфигурацията използват инсталационно тестване, за да гарантират, че крайният потребител може да инсталира и стартира програмата. Той обхваща области като инсталационни файлове, инсталационни местоположения и административни привилегии.
Тестването за развитие прилага набор от синхронизирани стратегии за откриване и предотвратяване на дефекти. Той включва статичен анализ на код, рецензии на партньорски кодове, проследимост и анализ на показатели. Целта е да се намалят рисковете и да се спестят разходи.
Потребителското изживяване попада в светлината на прожекторите с тестване за използваемост. Той измерва колко лесен е GUI за използване. Той проверява точността и ефективността на функциите и емоционалните реакции на тестовите субекти.
Тестът за разумност показва дали софтуерът си заслужава времето и разходите за продължаване на по-нататъшни тестове. Ако има твърде много недостатъци, по-агресивни тестове няма да последват.
Тестването за надеждност се извършва по време на фазата на пускане на софтуера, където се извършва тестване на дим, за да се види дали софтуерът ще работи достатъчно, за да може да се тества.
Тестовете за дим разкриват фундаментални повреди, които са достатъчно сериозни, за да предотвратят изпускане. Когато разработчиците тестват нова компилация, това се нарича тест за „проверка на компилация“. Когато системата претърпи модификация, регресионното тестване следи неочаквано поведение. Той посочва неблагоприятни ефекти върху модули или компоненти.
Тестерите въвеждат необичайни записи и разпознават способността на софтуера да управлява неочаквано въвеждане при разрушителни тестове. Това показва на разработчиците колко стабилна е програмата при управление на грешки.
Когато хардуерът или други функции се повредят, тестовете за възстановяване показват колко добре софтуерът може да се възстанови и да продължи да работи.
Автоматизацията изпълнява функции, които са трудни за изпълнение ръчно. Тестването включва използване на специфичен софтуер за провеждане на тестове и предоставяне на данни за действителните спрямо очаквани резултати.
Софтуерът трябва да работи в различни компютърни среди, така че тестът за съвместимост проверява как софтуерът реагира на различни системи. Например програмистите тестват софтуера с различни операционни системи и уеб браузъри.
Тестовете трябва да бъдат обширни и да отговарят на всички притеснения на клиента, или проектът бързо се превръща в загуба на ресурси.
Тестването на производителността изследва производителността на софтуера в различни сценарии. Събира се информация за отзивчивостта, стабилността, разпределението на ресурсите и скоростта. Под-тестове като обем, капацитет и пикови тестове играят роля в този процес.
Тестването за сигурност измерва способността на софтуера да защитава сигурността на потребителите. Функции за оторизация, удостоверяване, поверителност, интегритет, наличност и неотказ са примери за функции, които трябва да бъдат тествани.
Тестването за достъпност е различно от тестването за използваемост. Това определя степента, до която потребителите с различни способности могат да използват софтуера.
Резултатите от тестовете за интернализация и локализация показват как софтуерът може да се адаптира към различни езици и регионални изисквания. Това включва добавяне на компоненти за конкретни местоположения и превод на текст.
