от Курс за ССОК
Във всеки софтуер (хардуер и процес) има грешки. Това е неизбежно, т.к. те се създават от хора, а хората допускат грешки. За разлика от затворения модел на работа, при СОК грешките се откриват сравнително бързо и е възможно всеки да подаде рапорт за грешка. Обществото на тестерите е също толкова важно, колкото и това на разработчиците.
Роли в процеса на тестване
Думата тестване е доста обширна, но в действителност съществуват много различни роли в процеса на подобряване на даден софтуер. Те могат да бъдат изпълнявани от един или няколко човека в зависимост от проекта.
- Ловец на грешки (bug hunter) - човек, който използва софтуера по определен начин, следвайки или не определена методология. Целта на тази роля е откриването на ситуации, при които софтуера не изпълнява функциите си или се държи странно. Крайният резултат е рапорт за грешка, съдържащ достатъчно начална информация за проблема. Тук правим разлика между тази роля и ролята на попълващия рапорта (reporter) в следния смисъл: Обикновен потребител подаващ сигнал за грешка (reporter) не е ловец на грешки. Много често този потребител се натъква на грешката случайно и не се интересува от последващото развитие на рапорта. От такива потребители идват голяма част от рапортите в повечето проекти. Ловецът на грешки е човек, който целенасочено се опитва да накара софтуера да сгреши като използва дадена методология или променя нормалната среда за работа на софтуера.
- Анализатор - анализира (triage) множество рапорти за грешки като ги съпоставя един с друг. Често маркира рапортите като дубликат на вече съществуващ рапорт или ги маркира като затворени/невалидни, ако са много стари. Целта е да се намали обема на активните рапорти (house keeping), както и да се насочат различните потребители забелязали даден проблем към един и същ рапорт за грешка. Потребителите използват основния рапорт за следене на коментарите по проблема, докато програмистите имат възможност да изискват информация от повече хора и да прочетат свързаните (дублирани) рапорти.
- Тестер - целта му е да определи дали даден проблем е оправен или не. Дали при условията отразени в рапорта, софтуера се държи както се очаква или не. След направените тестове, рапортите преминават в потвърдено състояние (VERIFIED) или обратно към програмиста (FAILS_QA/ASSIGNED).
- Управление на плана за тестване - роля при която се създава, коригира и адаптира плана за тестване според конкретните нужди. Рядко е силно изразена в дадена личност. Обикновено се осъществява от група опитни тестери. При създаването на плана (test plan - какво да се тества) и самите тестове (test case - как да се тества) обикновено се следва определена методология.
- Програмист на тестове - програмист който създава автоматизирани тестове. Обикновено тестерите сами са автори на тестовете си. Може да се използва и комбинация от автоматизирани и ръчни тестове.
- Администратор - обикновено при наличието на автоматизирана среда за тестове или друга необходима инфраструктура (пр. файлов сървър). Грижи се всичко да функционира добре, за да може да бъде извършено самото тестване.
- Програмист на софтуерната платформа (framework) позволяваща изпълнението на автоматизирани тестове - добре се съвместява с горните две роли.
Системи за рапорт и следене на грешки
Това е най-важната инфраструктурна част при тестването. Без такава система би настъпил истински хаос. Тя помага за организиране на работата и информацията, и ефективно използване на доброволния труд зад проекта.
Независимо от конкретната платформа (Bugzilla, Trac, Mantis, др.), системата предоставя възможност за следене на състоянието на даден проблем във времето. За да използвате ефективно тази система е необходимо да бъдете добре запознати с правилата за нейното ползване, необходимата информация която трябва да предоставите и различните състояния, през които преминава даден рапорт за грешка.
Как да попълним добър рапорт за грешка ?
В основата на добрия рапорт за грешка е информацията. Информация която ще помогне на програмиста да разбере как, защо и къде се случва проблема. Правило номер едно е, че доброто заглавие е най-важно. Докато информация може да бъде добавяна чрез коментари, заглавието е това, което би накрало (или не) програмиста да прочете повече за проблема.
Писането и управлението на рапорти за грешки е цяла отделна наука, но добра практика е да се запознаете със софтуера, който тествате и с изискванията на програмистите относно рапортите за грешки. Начална страница по темата във Федора е налична на http://fedoraproject.org/wiki/BugsAndFeatureRequests. Полезни са също и следните страници:
Участие в процеса на тестване
Ако сте новак най-лесно е да започнете със самото тестване. Много проекти имат т.нар. дни за тестване, в които много хора се събират в Интернет и изпълняват тестове върху една и съща версия на софтуера. Това се прави по време на цикъла на разработка, когато продукта е сравнително стабилен, пр. алфа версия. Пример за такива тестови дни можете да намерите на: https://fedoraproject.org/wiki/QA/Test_Days
Ако вече имате опит в тестването може би бихте предпочели по-отговорна роля. Дефинирането на тестове е много подходящо за издигане в обществото на тестерите. Въпреки, че в много проекти всеки би могъл свободно да създава нови тестове би следвало да го правите, само ако имате опит. Целта е да се дефинират нови тестове, който покриват части от софтуера, които не са тествани до сега, пр. нова файлова система, нов начин на работа с програмата, т.н. Добре дефинирани тестове са тези които описват обекта на тестване, необходимите стъпки за изпълнение, очакваните резултати при положителен (и/или отрицателен) резултат.
Пример - Стартиране на инсталацията от DVD
Описание:
Инсталация (на ОС), стартирана от DVD диск.
Стъпки за изпълнение:
1. Подготвяне на инсталационен диск (запис на диска)
2. Включване на компютъра
3. Избор на DVD диска като стартиращо у-во (пр. промяна на настройката в BIOS)
Очаквани резултати:
1. Инсталатора (на ОС) стартира успешно от DVD диска
2. Инсталатора преминава към графичен режим (готов за инсталиране на ОС) без грешки.
Горният тест е извадка от списъка с тестове на http://fedoraproject.org/wiki/QA/TestCases
Друга възможност е да сте човека, който отговаря за дефинирането на план за тестване. Това е плана, според който се установява дали дадена бъдеща версия на софтуера е достатъчно стабилна, за да бъде разпространена публично. Тестовия план е съвкупност от тестове, условия за тестване (ръчно, автоматизирано), график на тестовете (пр. всяка събота) и резултати от изпълнените тестове. Целта на този план (още нар. тестов документ понякога) е да предостави достатъчно информация, на тези които са оторизирани да вземат решение за разпространението на бъдещата версия. Това обикновено са лидерите на проекта, докато тестовите планове са грижа на лидера на тестовия екип.
Пример за различните планове за тестване на Федора (9, 10) можете да намерите на http://fedoraproject.org/wiki/QA/TestPlans
Връзки
