С нарастващата сложност на ИТ технологиите, поради броя на интегрираните ИТ системи, има естествен ръст в необходимостта от тестване на софтуера.
Броят и сложността на тестовете се увеличават, което от своя страна значително забавя пускането на продуктите в експлоатация. От друга страна, почти всички организации се стремят да съкратят времето за пускане на софтуерни продукти, поради което удължаването на жизнения цикъл на софтуера поради увеличаване на обема на тестване се възприема негативно. Понякога се превръща в частично или дори до пълно отхвърляне на тестването и води до забележимо намаляване на качеството на ИТ услугите.
Пренебрегването на тестването води до следните последствия:
- Намаляване на качеството на продукта, който се разработва (основната причина за всички други последствия);
- Постоянен ръст на непреките разходи за осигуряване на качеството поради възникване на софтуерни дефекти в промишлената експлоатация;
- Загуба на клиенти, които не искат да използват продукт с лошо качество.
Препоръчително е да влезете в теста възможно най-рано, на етапа на анализ на изискванията, но нека да определим оптималния момент, когато можете да започнете тестване.
Според изследването на IBM цената на дефекта се увеличава с времето (подробен доклад тук).
Времевата линия съдържа няколко точки:
А: В системата се появи дефект заедно с кодов фиксатор.
Б: По-малко от един ден мина, дефектът не се проявява по-рано, но се възпроизвежда, когато се изпълнява определена последователност от стъпки. Такъв дефект е много лесно да се определи.
C: След няколко дни си спомняме какви промени са направени в системата, които могат да причинят дефект, което може да доведе до необходимостта от двойна проверка на направените в системата промени след тези, които са причинили дефекта. Но въпреки това той все още може да бъде фиксиран без значителни разходи.
D: Освобождаване: Дефектът започва да засяга потребителя, както и целостта на вашата система. Поправете дефекта ще стане по-трудно, ще изисква допълнителни усилия.
E: Дефектът е бил в продукта за известно време след освобождаването и вече е засегнал онези части от кода, които не са били променени. Потребителите са наясно какво е то и са принудени да приемат съществуването му. Въпреки това става все по-трудно да се поправи, тъй като вече е дълбоко в системата и разработчикът почти е забравил какви промени са го причинили.
F: Дефектът съществува в системата дълго време и лицето, което е въвело промените, които са причинили този дефект, вече не работи в компанията. За да се определи такъв дефект е изключително трудно.
Зелената линия показва сумата от всички разходи за фиксиране на дефект във времето и включва:
Коригиране на открития дефект в етапа на разработване. Тук цената на дефекта е нула, защото по време на програмирането разработчикът забелязва дефекта и веднага го фиксира.
Процеси на превключване – изключване на други задачи и фокусиране върху разбирането на функционалната и техническата страна на дефекта. Ако дефектът се открие от разработчика веднага след разработването, преди фазата на тестване, в този случай, цената на корекцията също е близо до нула, тъй като разработчикът лесно се връща към него и я фиксира. Ако корекцията се изпълнява от друг служител или, когато няма информация за причината за дефекта (както в точка Е), цената на фиксирането се увеличава многократно.
Определяне на причината за дефекта. В този случай, цената нараства постепенно с нарастващата сложност на разработеното приложение и като се има предвид, че с течение на времето хората, които са имали представа за причините за неговото възникване, забравят промените, които са я предизвикали.
Корекция на дефекти след освобождаване. Колкото по-голяма функционалност е добавена към некоригирания дефект, толкова по-трудно и скъпо е да го поправите. Също така значително увеличава риска от въвеждане на допълнителни дефекти.
Въздействие върху потребителя, репутацията на вашата компания. Тук допълнителната загуба на средства се дължи на подкрепата на потребителите и загубата на имидж на продукта. Колкото по-дълго дефектът е в продукта, толкова повече щети го причинява.
Загубите от дефекта
Най-известната загуба на Toyota, намерена в продукта след освобождаването.
През 2009 г. Toyota припомни продадените автомобили във връзка със заглушаването на педала на газта. Един от пътниците на Lexus ES350 се обади на компанията: Колата започна да се ускорява неконтролируемо със скорост от 100 км / ч и спря да реагира на педала на спирачката. Загинаха се четирима пътници. През ноември 2009 г. дилърите бяха инструктирани да съкратят педала на газта, да актуализират софтуера на автомобила и да тестват приложението, съдържащо грешка, която е причинила забавяне на спирачната система. Така до 2010 г. са изтеглени около 8,2 милиона коли. Не е трудно да си представим мащаба на разходите за коригиране на тази грешка.
Заслужава да се отбележи, че съществуват 2 вида разходи: Непреки и преки.
Преките разходи са средства, които дадена компания изразходва за поддържане на продукт в добро състояние, т.е. всъщност върху възнаграждението на труда за всички, които участват в работата по проекта.
Косвени – това са разходите, свързани с качеството на продукта, пристрастяването на потребителите към новия продукт. Ако продуктът е бил тестван от началото на разработването на проекта, преките разходи за поддържане на качеството на продукта винаги остават на същото ниво и растат само с растежа на проекта, а непреките разходи са сведени до минимум.
В случая, когато изпитанията изобщо не се извършват, разходите за директни разходи за тестване липсват, а непреките разходи на нискокачествения софтуер растат безкрайно. За да се намали нарастването на непреките разходи, е необходимо да се въведат тестове възможно най-рано, поне преди пускането, най-добре в началото на анализа на продуктовите изисквания и подготовката на проектната документация.
Заключение
Въз основа на гореизложеното може да се направи заключението, че най-безболезненото и най-малко скъпо освобождаване на продукт в пускането може да бъде, ако тестването за наличие на дефекти бъде въведено възможно най-скоро, а именно на етапа на изискванията или по време на разработването на проекта.
Не трябва да спестявате при тестване, отсъствието на което води до неудовлетвореност на потребителя от продукта, неконтролирани разходи и може да доведе до загуба на значителни средства.
