Category: Bugs

Покрай силната неопределеност и неструктурираност на част от методиките в Quality Assurance витаят едни общи разбирания, че Quality Assurance engineer-а осигурява качество. Това НЕ е така. Ние можем да:

• Анализираме изискванията на клиента и на тази база (и немалко предишен опит) можем да предвидим още преди да е започнала активната разработка да открием несъответствия (логически, технически или концептуални);
• На база клиентски изисквания да напишем десетки или дори стотици тестове (test cases) на всеки отделен компонент, които след като част от нужната функционалност е готова да изпълним за да се уверим, че това, което е направено съвпада с вижданията на клиента за добре работещо приложение;
• Да използваме множество методики, тест техники, черна магия и каквото друго е нужно по време на разработката на проекта. Всичко, което намерим го логваме в някой bug tracking system (дали ще е TFS, BugZilla, JIRA, дори и Google Docs, etc няма значение). Знаете правилото – ако няма логнат бъг значи няма бъг. А повярвайте ми – в този ежедневен поток от информация много лесно можете да забравите нещо ако не го логнете;
• Да проверим след като програмисти/дизайнери/други са фикснали проблема дали е направен по начин, който може да удовлетвори клиента (и в идеалния случай и нашите лични вижданя за това кое е правилно);
• Да направим финални тестове, които да ни дадат солидни доказателства, че можем да кажем на клиента актуалния статус на проекта. Има вариант в който да репортнем, че нещото не работи според очакванията и изискванията, но да бъде предприет риск (risk management) и въпросната функционалност да бъде пусната в production. Това зависи от клиента, не от нас.

И още едно, много важно нещо – мога да ви гарантирам, че НЯМА софтуер без бъгове. Има такъв с неоткрити такива. Някой преди време беше казал, че: “QA can miss a bug, but the crowd will not”.