Pavel Eideland Глобалната цел е да се гарантира качеството на крайния продукт
„Банкови технологии“: И така, какво е тестване на софтуер?
Павел Айделанд: Има много отговори на този въпрос. Например, Wikipedia заявява, че тестването на софтуера е процесът на изследване на софтуера, за да се получи информация за качеството на продукта. Може също така да се каже, че тестването е неразделна част от процеса на осигуряване на качеството на софтуера. Тестването не цели откриване на дефекти или писане на тестови скриптове, внедряване на система за регистриране и обработка на грешки (bug tracking system). Всичко изброено по-горе са само средства за постигане на глобалната цел - да се гарантира качеството на крайния продукт за потребителя. И непосредствената задача на тестването е контролът на качеството.
„Б. Т.: Какво се разбира под думата качество? Възможно ли е да се определят официални критерии за качество?
Стр. Е.: Един от методолозите на RUP (Rational Unified Process, една от най-разпространените методологии за разработка на софтуер), Филип Крухтен, дефинира качеството по следния начин: „Качеството отговаря на очакванията на потребителите“. Процесът на тестване просто се опитва да формализира понятието "качество", да определи методите, чрез които то ще бъде контролирано и измервано, и числено да изрази колко доволен ще бъде крайният потребител в крайна сметка.
Що се отнася до софтуера, ако трябва да се постигне предварително определено ниво на качество, тогава в компанията трябва да има определено ниво на процес на тестване. Когато клиент на нашите услуги за тестване зададе въпроса: „Какво може да предложи Аплана в областта на тестването?“, тогаваВинаги му отговарям: „Гарантирано високо ниво на внедрени процеси, което ни позволява да гарантираме високо ниво на качество“.
„Б. T.”:Какви видове тестове съществуват? Какво може да очаква крайният потребител от тестването?
Стр. Е.: По отношение на софтуера има няколко основни типа тестване.
1. Ръчно функционално тестване. Тестване на ниво краен потребител на част или продукт като цяло, както и тестване на взаимодействие с други продукти. Най-търсената услуга в момента, която се поръчва от нас.
2. Автоматизирано функционално тестване. Аналог на ръчно функционално тестване, с единствената разлика, че тестването се извършва от програма-робот, а не от човек. Тестването е много по-бързо, но по-малко гъвкаво. Също така, за да използвате автоматизирано тестване, може да са необходими доста високи умения за програмиране.
3. Тестване на натоварване. Определяне или събиране на индикатори за производителността на софтуерната и хардуерната система. Извършва се чрез прилагане на определено натоварване към системата, като емулира работата на много реални потребители едновременно. Също така с помощта на този вид тестване се определя степента на съответствие на събраните показатели с посочените изисквания към системата. При този вид тестване работим много тясно с ИТ специалистите на клиента.
4. Единично тестване. Част от фаза на програмиране, която ви позволява да тествате очакваната производителност на части от програмния код. При използването на този вид тестване се проверява логиката на работа на отделните функции и процедури в кода, включително дали добавянето на нова функционалност не е довело до грешки в съществуващия софтуер.
5. Тестване на сигурността на приложението. Оценка на уязвимостта на софтуера към различни видове атаки отвън и отвътре: кракване на пароли, DDoS атаки, червеи и др.
1. Тестване на продуктовите изисквания за коректност, осигуряване на класическо трио за изисквания: пълнота, недвусмисленост и последователност.
2. Тестване на продукта за съответствие с посочените изисквания. Например, за всяко изискване от техническото задание, тестовите анализатори на Аплана разработват няколко варианта за проверка, за да бъдат максимално сигурни, че и най-малките детайли на изискването са изпълнени правилно.
3. Тестване на продукта за съответствие с неофициалните изисквания на крайния потребител. Често желанията на крайния потребител не са отразени във формалните изисквания, остават неизразени на хартия. За да разрешим подобни несъответствия навреме, ние провеждаме предварителни интервюта с потребителите и сравняваме техните изисквания с изпълнението.
4. Тестване на придружаващата документация -- ръководства за потребителя, ръководства на администратора, друга документация, предоставена с продукта.
5. Тестване на различни платформи или браузъри. Важно е дали продуктът ще се използва в различни операционни системи или трябва да се показва правилно в различни браузъри.
6. Интеграционно тестване - тестване на взаимодействията на продукта с други продукти в единна софтуерна и хардуерна среда.
7. Тестване на използваемостта на продукта (Usability). Винаги можете да подобрите оформлението на контролите, удобството на отчетите и други малки неща, които създават крайното впечатление за продукта за потребителя.
Други видове тестове могат да бъдат класифицирани по подобен начин.
тестване --това е утвърден клон на ИТ пазара, който вече има собствена структура и свои специалисти, а нашата компания заема една от водещите позиции тук.
„Б. Т.: Какъв вид тестване препоръчвате да се извърши, ако е необходимо да се въведе нов продукт или да се пусне нова версия на вече използван продукт?
Стр. E.: Всеки от видовете тестове може да се използва самостоятелно или в комбинация помежду си, в зависимост от нуждите. Например, можете да тествате продукт за съответствие с посочените изисквания, но не и да извършвате тестове за натоварване, ако можете да направите само един тип тестове или ако сте уверени в маржа на производителността. Но, както показва опитът от нашите проекти, решението какъв вид тестване наистина е необходимо трябва да се вземе само след задълбочено изследване на системата.
„Б. T.»:И все пак, защо е необходимо да организирате тестване нарочно, ако крайните потребители винаги могат сами да проверят качеството на продукта?
Стр. E.: Тестването служи като вид бариера, разделяща потребителите на даден продукт от неговите разработчици. Нека ви дам пример: докато работих по един от нашите проекти, по време на който тествахме интернет банка, забелязах, че потребителите и разработчиците имат напълно различни задачи във връзка с внедрявания продукт. Разработчиците трябваше да пуснат продукта в действие на всяка цена, а потребителите бяха готови да закупят продукта, но само с добро качество и в необходимото време. Тъй като този подход беше продиктуван от нуждите на участниците (разработчици и потребители), с цел предотвратяване на конфликт на интереси, бяхме поканени на сцената – екипът за тестване. От една страна, ние действахме в интерес на крайните потребители,защита на качеството на продукта и съответствието му с посочените изисквания. От друга страна, помогнахме и на разработчиците, тъй като повечето от нашите служители имат техническо мислене. По този начин комуникацията между екипа за разработка и екипа за тестване беше много по-лесна.
„Б. T.”:И ако няма проблеми в комуникацията между потребители и разработчици, тогава трета страна не може да бъде включена?
Стр. E.: Ако няма тестване и продуктът се предоставя незабавно на крайните потребители, тогава качеството на работата на разработчиците пряко засяга работата на крайните потребители в началния период от време след внедряването. Ако има грешки, се натрупват отрицателни точки, създава се негативен имидж на доставчика на продукта, който е много труден за коригиране. Недостатъчното качество на продукта, доставен от производителя (от което никой не е застрахован), веднага води до големи загуби за потребителите в случай на критични за бизнеса грешки. Ако крайните потребители не са клиенти на продукта, а само неговите потребители (например потребители на интернет банка или онлайн магазин), тогава компанията, внедрила продукта, също ще претърпи репутационни загуби. С привличането на Аплана фирмата внедрител получава увереност, че няма да има негативна реакция от страна на потребителите.
Освен това, ако няма тестване, тогава как знаете преди внедряването дали продуктът отговаря на изискванията, които са му били поставени при поставянето на задачата? Има само два начина: да се доверите на разработчика или да проверите. Дори отличната репутация на доставчика не дава 100% гаранция за липсата на грешки и точното разбиране на изискванията. Освен това доставчиците почти никога не посочват изрично кои проверки на продукта са извършени преди пускането му на потребителя.И когато тестваме софтуер, нашият клиент винаги знае какво и как тестваме и какви последствия могат да имат определени системни недостатъци.
„Б. T.”:Какво е добре оформен процес на тестване?
Стр. Е.: Можете да говорите за тестването по същия начин, както за всеки друг процес в организацията. Както при другите процеси, има няколко нива на тестова зрялост. Съгласно TMMI (Test Maturity Model Integration, аналог на популярната оценка на зрелостта на ИТ процесите CMMI), тестването може да бъде разделено на пет нива на зрялост със съответните етапи: I - начален (приемане на продукта директно от крайните потребители), II - управляван (тестова среда, планиране на теста, дизайн и изпълнение на теста, автоматизация на теста), III - дефиниран (отдел за тестване, жизнен цикъл на теста, нефункционално тестване), IV - измерим (измерване на теста, оценка на качеството на продукта). ), V - възможност за непрекъсната оптимизация (предотвратяване на дефекти, оптимизиране на процеса на тестване, контрол на качеството).
Разбира се, само процесът на петото ниво на зрялост може да се нарече идеален, но може да се говори за добро ниво на тестване в организацията, започвайки от четвъртото ниво. В нашия проект Testing Factory в Сбербанк България успяхме да видим всички предимства от преместването на процесите на тестване на по-високи нива. Например, не беше достатъчно да има отдел за тестване (второ ниво), както и да се коригира и формализира жизнения цикъл на тестването (зададени срокове, отговорни за тестовите среди, отделен бюджет, тестов план - трето ниво). Едва на четвъртото ниво на зрялост на процесите на тестване се появи измерването на всички процеси и количествените оценкикачеството на доставения продукт. След това ползите от тези преходи станаха очевидни и подкрепени с числа. Дейността на отдела за изпитване стана по-прозрачна и очевидна за ръководството.
Освен това, с нарастването на нивото на зрялост се увеличават и целите на самото тестване. Ако на първоначално ниво целта на тестването е само да покаже дали нов продукт може да работи изобщо след внедряване (и е възможно тестването да е вече в ход по време на пробната експлоатация на продукта в индустриална система), то на петото ниво на зрялост процесът на тестване дори е насочен към предотвратяване на грешки при внедряването на продукта. Това е много важен момент, например за тези наши клиенти, за които системните грешки в търговската експлоатация водят до огромни финансови загуби.
„Б. Т.: Как да оценим ефективността на процеса на тестване?
Стр. E.: Наличието на правилно организиран процес на тестване, който винаги се опитваме да установим с нашия клиент, увеличава наличността на продуктите и съответно намалява времето за прекъсване на работата. Наличността се отнася до процента от очакваното време, през което продуктът работи, без да бъде принуден да спре достъпа от крайни потребители. Например, ако системата трябва да работи 24 часа в денонощието, 7 дни в седмицата, но в действителност не е достъпна средно по два часа на месец, то нейната наличност е 99,96%. Според пазарни анализатори на ИТ (Alinean, Gartner) преките загуби на центрове за данни, когато капацитетът им е недостъпен, надхвърлят 1,5 милиона рубли. в един часа. Загубите на организациите, които са крайни потребители на техните услуги, могат да бъдат десетки и стотици пъти по-големи. Увеличаването на наличността на критична бизнес система от 99,5% на 99,9% намалява загубите на компанията от неналичност на системи, свързани със софтуерни повреди, с 5веднъж.
„Б. T.”:Разкажете ни малко за вашия опит в прилагането на процеси за тестване и най-често задаваните въпроси.
Стр. E.: Прилагането на подходящ процес на тестване намалява рисковете на крайните потребители на първо място и като допълнителна полза прави процеса на разработка по-прозрачен и лесен за тях. Потребителите виждат, че ИТ отделът на внедряващата компания следи качеството на продуктите, прехвърлени на крайните потребители, а не просто се стреми бързо да внедри това, което разработчикът е прехвърлил.
И още един пример от практиката: в един от нашите проекти задачата беше да изградим тестов процес при клиента. Когато започнахме да разработваме нормативни документи за тези процеси, отново се убедихме, че тезата „Тестването е част от жизнения цикъл на разработката на софтуер” е 100% правилна. Всички наши правила за тестване неизбежно се пресичат с документи за други дисциплини, от установяване на изисквания за разработка до правила за въвеждане на софтуер в търговска експлоатация и обработка на коментари, получени от потребители. По този начин, за да се изгради правилният процес на тестване, беше необходимо да се промени самият процес на разработка, в резултат на което всички участници бяха победители.
Списание "Банкови технологии", бр.8, 2012г