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

Увод

Случвало ли ви се е да участвате в проект за разработване на софтуер, в който липсват жизненоважните мерки за контрол и осигуряване на качеството? Не сте сами в това отношение. Това се случва в зашеметяващо голям процент от компаниите и проектите. Дори и компаниите да знаят, че има такова нещо като QA (quality assurance – осигуряване на качеството) и че то трябва да се прави, всички усилия обикновено водят само до един голям QA спринт точно преди пускането на проекта. Това е стресиращ период, в който се опитваме да накараме софтуера поне малко да работи. Разбира се, целият този хаос се повтаря при следващия цикъл на излизане без ни най-малко подобрение.

На какво ни учат в институтите

Проблемът е, че при изучаването на информатиката не се преподава как да се гарантират стандартите за качество на софтуера. По-голямата част от времето се отделя за изучаване на алгоритмите, компютърните принципи, историята на някои езици и концепции и т.н. Освен това, поне в моето следване, имаше един семестър, посветен на техниките за управление на проекти и Scrum (рамката за управление на проекти чрез тяхното разделяне на части). Всичко това е чудесно, но тук напълно липсва осигуряването на качеството. Пренебрегването на QA е огромна загуба, защото над 90% от всички студенти работят в условията на различните компании след завършване на обучението. Те ще трябва да създават необходимия софтуер навреме и без грешки.

Защо компаниите едва едва успяват да предоставят софтуера си навреме

Сблъсквал съм се с това безброй пъти. Стандартите за осигуряване на качеството и мерките за осигуряване на качеството са сред първите, които минават под ножа, защото за проектите най-важен е бюджетът. Често те се залагат за в края на проекта, но ако разработката се проточи (което често се случва) или има разрастване на функциите (което винаги се случва), вече няма време за QA. В крайна сметка получаваме абсолютния минимум неструктурирани тестове и произвеждаме цифрова къщичка от карти с клатещи се стени.

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

Как да слезем от тази въртележка

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

Само ако намерим сили да изразим мнението си и да го поставяме на обсъждане отново и отново, можем да направим първите стъпки, за да излезем от този порочен кръг.

Да поговорим за парите

В един момент осъзнах, че използвам неподходящи аргументи. Ако кажете, че софтуерът ще бъде „по-стабилен“ или че ще „опрости значително поддръжката“, тези аргументи няма да имат особен смисъл за тези, които не работят по самата кодова база. Трябва да поговорим за парите. Ние, разработчиците, трябва да говорим за това колко струва липсата на QA. Това е езикът на бизнеса и на мениджмънта като цяло. Винаги се опитвам да обясня мерките за осигуряване на качеството с примери като този: „Ако не го направим сега, усилията за разработка (и следователно разходите) само след четири месеца те ще се увеличат с 15%“ или „Трябва да въведем unit тестове за всички функции, иначе фазите на стабилизиране на версиите ни всеки път ще се удължават. Това директно се отнася за всички функции, които създаваме, защото всеки път трябва ръчно да тестваме всички странични ефекти. В резултат на това напредъкът ни ще бъде все по-малък с всяка следваща версия“.

Според моя опит преходът към подобни решения и примери помага да се разбере смисълът на темата. В крайна сметка вашите усилия ще подобрят живота на всички, просто те все още не го осъзнават.

Минималната ефективна доза

За да бъдем реалисти е важно да не преекспонираме мерките за осигуряване на качеството, като изразходваме предварително големи суми за тях. Не бива да възпрепятстваме развитието на проекта като цяло; освен това не всички заинтересовани страни ще харесат този подход. Винаги съветвам да се наблегне на най-важните части на приложението. Обикновено има определен сценарий на използване, характерна особеност или нещо друго, върху което е изградено цялото приложение. Това може да е някаква основна функционалност, която трябва да работи правилно и стабилно, за да може софтуерът да бъде полезен за клиента или потребителя. Именно това трябва да се тества. Измислете мерки и начини да гарантирате, че тя работи по предназначение.

Харесва ми терминът „минимална ефективна доза“ (MED – minimum effective dose). Това е минималната мярка, която води до желания резултат. В областта на QA това може да бъде план за ръчно тестване, автоматизирани тестове в конвейер или нещо друго. Това е отправната точка. Ако функционалността на основните функции е подсигурена, можете постепенно да разширите стабилността, например да добавите unit тестове за всички нови функции. Също така помислете за източниците на информация, които не можете да контролирате, като например външните API или въвежданите от потребителя данни. Намерете начини да валидирате и тях, защото това са очевидни места, в които софтуерът ви може да се провали поради неправилна употреба. Итегрирайте и работете поетапно. Това се отнася и за осигуряването на качеството.

Какво всъщност търся аз

Във всеки нов проект, който започвам или продължавам, търся концепцията за осигуряване на качеството. Колкото и малка да е тя, екипът трябва да помисли за нея.

• Какво ще пускаме?
• От какво се нуждаем, за да работи?
• Как да го направим работещо?
• Кои от мерките преднамерено ще изключим и защо?

Наличието на писмена документация плюс може би и план за тестване са чудесни основи, върху които софтуерът може да се развива. Те показват, че ние, екипът, сме обмислили как да продължим напред. Мисъл от гледна точка на EDR. Освен това препоръчвам редовно да преглеждате избраните методологии, да речем веднъж на тримесечие.

Не използвам TDD (Test-Driven Development – разработване, управлявано от тестове, бел. прев.), когато пиша сорс код, но силно препоръчвам да се пишат тестове паралелно с писането на софтуера. Това е най-подходящото време за писане на тест. Ако пишете тестове, докато реализирате дадена функция, ще получите допълнително предимство: кодът ще бъде структуриран така, че действително да може да бъде тестван. Когато пишете тестове за вече готов софтуер, често откривате, че в кода има твърде много взаимни зависимости или че са нарушени принципите на едноличната отговорност. С помощта на тестовете показвате, че сте разбрали желаното поведение и гарантирате, че всичко работи според очакванията. Можете дори да го наречете документация на кода.

Преимуществата за проекта

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

Само при наличието на мерки за осигуряване на качеството един проект може да се развива със здравословни темпове.

Промяна на проектите към по-добро

Използвате ли вече собствени мерки за осигуряване на качеството във вашите проекти или нещата са много нестабилни? Искате да разширите уменията си като разработчик и да станете известен като човек, който пише качествен софтуер?

Започнете с малко. Помислете за MED (Minimum Edit Distance – минимално редакционно разстояние) на вашия проект. Поемете отговорност и се превърнете в човека от екипа си, който прави тази разлика. Не всеки трябва да бъде проповедник на QA, но можете да научите хората на тези техники, от които наистина се нуждаят, като давате пример. Бъдете този, който ще започне тази дискусия.