5 мита за QA в софтуерната разработка
За всички е ясно, че качеството е важна част от процеса на разработка на софтуер. За съжаление обаче често се бъркат понятията “quality assurance” (QA - осигуряване на качеството на софтуера) и “тестване”, като границите им са размити и неясни. Ние сме събрали 5-те най-често срещани мита що се отнася до QA в софтуерната разработка. Запознайте се с тях, за да не допускате грешки.
1. Quality assurance е тестване
Често пъти термините „quality assurance“ и „тестване“ се използват като взаимнозаменяеми. Истината е, че тестването всъщност e част от quality assurance процеса.
Доброто осигуряване на качеството на софтуера трябва да обхваща целия процес още от самото начало – от описването на изисквания за проекта чак до поддръжката на софтуера. Това обхваща набор от различни тестови техники, но трябва да бъде съобразено и със стандартите, процесите, документацията, изобщо целия цикъл на разработка.
2. Всички бъгове могат да се премахнат
Очакванията на клиентите, мениджърите, програмистите трябва да бъдат в границите на разумното. Един от най-големите недоказуеми закони на софтуера и компютрите като цяло е, че всички системи имат бъгове. Никога не могат да бъдат елиминирани всички бъгове в една система, всичко се довежда до намаляването им до приемливо ниво.
Тест експерта Борис Бейзър е изчислил, че неговата лична норма на бъгове е 1,5 бъга на ред изпълним код, като това включва и правописните грешки. Повечето бъгове се намират и коригират от програмиста още докато пише кода, но голяма част от тестването е всъщност изкореняването на възможно най-много бъгове.
За по-големите системи, фазата на поддръжка е основно съсредоточена върху справянето с постоянно допълван списък с бъгове. Има и списък с „известни проблеми“, които се толерират, защото цялостното качество на системата е прието като достатъчно добро. Ето защо е важно да се определи между членовете на екипа какво точно се разбира под „достатъчно добро“ и да се цели достигането на това ниво.
3. Тестването трябва да бъде напълно автоматизирано
Автоматизираното тестване може да улесни усилията на екипа, но това не изключва ръчното тестване от картинката. Ефективното тестване се постига най-лесно чрез комбинация от автоматизирано и ръчно.
Автоматизираните тестове могат да намалят нуждата от повтаряемо ръчно тестване, но те имат тенденцията да използват едни и същи входни данни всеки път. Софтуер, който последователно преминава определен набор от автоматизирани тестове, може да не се „справи“ толкова добре, когато е подложен на по-произволни и непредсказуеми входни данни от тестъри от кръв и плът. Професионалният опит на обучен QA експерт може да предложи по-взискателен тест от автоматизиран скрипт.
Също така може да бъде много трудно да се създаде някаква форма на надеждно автоматизирано тестване в ранните етапи на даден проект или пък за нова функционалност. На преден план е разработката на софтуер и често е трудно да се вземе решение кога най-добре да започне писането на автоматизирани тестове. Някои софтуерни платформи страдат и от недостиг на технологични рамки за тестинг, като това допълнително подкопава обхвата на автоматизация.
4. Лесно е да тестваш
QA инженерите често са подценявани и то главно от хора, които не разбират напълно каква стойност добавят те в един проект.
Наистина добрите QA експерти се намират рядко. Те комбинират дълбоко познание за тест техники с истински ентусиазъм за качество. Те намират грешки в проекта, които всички други биха пренебрегнали. Те предоставят и по-широка перспектива върху проекта, базирайки се на дълбоко разбиране едновременно на бизнес изискванията и на процеса по разработка на софтуера.
5. QA се прави накрая
Много проекти се планират като се предвижда част от тестването да се направи щом разработката на софтуера приключи. Това звучи разумно, но уловката е, че времето, което е оставено за QA, често се свива значително в процеса на разработка. Неизбежните забавяния в разработването на софтуера се отразяват на времевите прозорци, оставени за тестване. И в случай, че се стигне до избор между няколко цикъла на тестване или добавянето на нова функционалност, истината е, че тестването често губи тази битка.
Този подход е неефикасен и защото големите бъгове се оставят да се натрупват в системата до по-късни етапи на проекта, а е всеизвестен факт, че колкото по-късно се отстраняват те, толкова повече се оскъпява проекта.
Тестването за сигурност също се пренебрегва често. Обикновено то се свежда до единичен одит на системата точно преди да бъде пусната. В един идеален свят трябва да се използва подход базиран на риска , който да идентифицира и поправи уязвимости по време на целия процес на разработка. Тестването на сигурността трябва да бъде включено в архитектурата на дизайна и в процеса на code review.
Без митове
А как се тестват системи и ръчно, и автоматизирано? Как се пишат и разчитат спецификации на софтуерните изисквания? Какви техники за софтуерно тестване се използват? Отговорите на тези и други въпроси, ще получат студентите на СофтУни в безплатния ни курс QA Fundamentals. Те ще научат основните концепции на осигуряването на качеството на софтуера, как да търсят дефекти чрез въвеждане на подходящи входни данни и как да тестват потребителското изживяване, как да работят със спецификации на софтуерните изисквания (SRS). За най-добре представилите се студенти, след изпита ще има възможност за старт на кариерата им в ИТ индустрията при официалните партньори на курса по QA Fundamentals – Proxiad Bulgaria! Курсът започна на 13 юли и завършва на 29 август с практически изпит. Всички, които успешно вземат изпита си с оценка над 5.00, ще получат и официален сертификат от Софтуерния университет.
