Как да започнете тестване на софтуер

Какво пишат в блоговете

Буболечки и дупки

• Визуални илюстрации на възможни сценарии с програмен код.

Прост масив

Онлайн обучения

Присъствени обучения

Конференции

Какво пишат в блоговете (EN)

Раздели на портала

Относно инструментите

Най-добри работни места

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

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

Желанието да напиша тази статия възникна доста отдавна в резултат на четене от ръководителя на новосъздадения отдел по качество на маса литература за тестване на софтуерни продукти и комуникация в интернет форуми на инженери по качеството. Основният проблем на всички тези източници на информация е много силният сциентизъм в представянето на елементарни неща като цяло и пълното нежелание да се премине от общи разсъждения към конкретни примери, от които начинаещият може да разбере нещо. Що се отнася до платеното обучение, програмите на повечето курсове (поненай-малко у нас) предполагат студентът да работи във вече подготвена организация с изграден процес на развитие, като трябва само да му се дадат необходимите знания и умения, за да може да се включи възможно най-безболезнено в този процес.

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

Мотиви за появата на тестера

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

Ако проектът е повече или по-малко дълъг, тогава с течение на времето проблемите с коригирането на грешки, като се вземат предвид коментарите на потребителите и инженерите по техническа поддръжка, стават толкова широко разпространени, че програмистите най-често сами, „отдолу“, инициират увеличаване на персонала от „момиче, което ще мушка бутони“. Така че в организацията има тестер, който може да върви по два начина.

Първият е наистина да „натискате бутоните“. Естествено, когатоработейки по този начин, грешките на тестера бързо свършват, но потребителите остават, което кара всички да го обвиняват в непрофесионализъм (и какво искахте от „момиче, което натиска бутон“).

Лошото е също, че на този етап, за съжаление, не може да се очаква специална помощ и съдействие от никого. Обикновено общуването с другите изглежда така: „На тест“ или „Какви са грешките? Всичко работи". Следователно вторият начин е да организираме работата по-ефективно.

В литературата има много определения, но любимото ми е следното: „главната цел на тестването е да се увери, че системата прави това, което трябва, и не прави това, което не прави“. И отново, с прости думи, основната цел на тестера е да разработи възможно най-пълната система от тестове и в същото време да направи всичко, така че следващия път да не забравите какво е направил, какво е намерил и как да поправите тази открита проверка.

Когато няма нищо друго.

Важно е да започнете да разбирате и формализирате процеса на разработка, който вече имате. Може да си мислите, че не съществува, но обективно го има, просто не е достатъчно добър. Съберете и проучете всички длъжностни характеристики, корпоративни стандарти и друга необходима документация. Много е възможно всичко това да го няма - често в малките организации целият процес протича на ниво устна комуникация. Най-вредната последица от това е липсата на ясно дефинирани служебни задължения. Наличието на длъжностни характеристики е гаранция не само за това, че винаги можете да намерите отговорен човек. При разработването им учудващо добре се откриват пропуски и логически пропуски в съществуващата организация на труда. Следователно написването на позиция в отдела за тестване и длъжностни характеристики (дори за позиции, които все още не съществуват) е първата необходима стъпка. INосвен това, в идеалния случай нашата цел е да накараме нашия отдел да комуникира с останалия свят само чрез документи.

Оттук и първите изводи:

обхватът на техните отговорности в организацията трябва да бъде конкретизиран (най-често, между другото, това означава „стесняване“) и фиксиран;
за тестване, в допълнение към устните истории на разработчиците, е необходимо да има документирани изисквания към системата (просто казано, изискванията са списък на това, което системата трябва да прави и на какви условия трябва да отговаря). Колкото по-подробен е списъкът с изисквания, толкова по-лесно е да се тества системата;
откритите дефекти трябва да бъдат регистрирани по някакъв начин и по такъв начин, че по-късно да може да се проследи техният жизнен цикъл;
резултатите от теста трябва да се съхраняват някъде в удобна за търсене и анализ форма;
в никакъв случай не започвайте веднага с тест автоматизация. За това е "автоматизацията", за да се автоматизира вече съществуващ и установен процес и ако започнете веднага с него, тогава нищо друго освен огромни материални и времеви загуби няма да работят.

Как са и какво да правим.

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

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

план за тестване - документ, съдържащ кратка информация за самата система, силите и средствата, с които се предполага, че ще бъде тествана, какво точно трябва да се тества (до списъци или дори описания на тестове), приблизителни планове за времето, критерии за завършване на тестването и признаване на освобождаването като успешно, рискове и друга информация, която може да повлияе на процеса на тестване. В литературата и в Интернет има много празни тестови планове, от които можете да създадете желания шаблон за себе си. Съществуват два подхода за написване на тест план - статичен и динамичен. Статичен - когато планът за тестване е написан веднъж при разработване на стратегия за тестване и съдържа само неизменна информация. И динамичен - когато тестовият план съдържа и описания на тестове, които се коригират и допълват в процеса на разработка на софтуера. Честно казано, не разбирам защо трябва да се прави това, ако всички промени могат да бъдат направени в документите, свързани с тестовия план, което позволява по-добро структуриране и проследяване на версиите, но това е въпрос на вкус. Аз използвам първия подход.
Тестът е документ, описващ определен тест. Неговата подробност не трябва да бъде прекомерна - в крайна сметка, в условията на работа, приети в статията, няма да имате сили или време за това. Основното изискване за тестов случай е описание на теста и очакваните резултати на добре дефинирана независима част от функционалност (или свойства) на софтуера, които трябва да бъдат недвусмислено ясни както на вас, така и на вашите подчинени, ако има такива. Красотата на такива тестови случаи е, че те могат да бъдатструктура, както желаете, превръщайки се в набори от контролни таблици (при автоматизиране на тестването това ще бъдат набори);
контролна маса (Check-list, aka Suite - set) - всъщност в предишния параграф писах за тях. Това е табличен документ, който комбинира (чрез хипервръзки) набор от тестови случаи с бележки за резултата от тяхното изпълнение и бележки.
доклад от теста - полученият документ, съдържащ връзки към контролни таблици и заключения относно изправността на изданието с подписите на тестера и ръководителя на проекта.

От цялото море от видове документи, които се предлагат например в РУП, можете да оставите само четири за начало

За всеки монтаж се създават всички посочени документи (с изключение, разбира се, тестовия план). В тази форма те вече са достатъчни, за да се знае в края на фазата на разработка, че цялата основна функционалност на системата е тествана и да се твърди, че този модул работи.

И тук преминаваме към съхранение на данни и версии. В интерес на истината, като начало, подходът е доста прост. Някъде във файловия сървър се формира споделен ресурс, в който се създават папки за всеки проект. Всяка такава папка съдържа следните елементи:

файл с тестов план
файл с образец на протокол от изпитване;
Каталог TestCase с набор от тестови случаи за този проект;
директорията Builds, в която в отделни папки се съхраняват тестваните тестови случаи за тази сборка (на практика копие на папката TestCase, документите от която се използват като шаблони) и тестов отчет.

За начало (и за по-късно) такава структура е напълно достатъчна, за да контролира процеса на тестване. Препоръчително е да поставите файл ссписък с изисквания за тази итерация.

Списъци с изисквания и регистриране на грешки

С изискванията, за съжаление, е най-трудно - програмистите не обичат да се занимават с рутина, особено в случаите, когато това изисква значителни интелектуални усилия. Необходими са обаче и изисквания, за да се знае какво да се тества. Следователно, ако няма такива, тогава тестерът трябва сам да направи списък с изисквания, поне под формата на таблица в Excel. За да направите това, трябва да общувате с ръководството, с програмистите, с клиента и със собствения си здрав разум (в същото време, отново, проверявайки с клиента), но това е много полезна работа в крайна сметка. Между другото, разработването на тестови случаи е много обвързано с изискванията, които се проверяват от описаните в тях тестове.

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

И на този етап е време да представим BTS.

За начало може дори да бъде Excel файл с персонализирани автофилтри, но в идеалния случай е препоръчително незабавно да вземете решение за софтуера, който ще се използва по-нататък за автоматизирано тестване, проследяване на грешки, управление на изискванията, документация и т.н. Има достатъчен брой производители, които правят цели специализирани комплекси. Знаейки в коя област на ИТ работи организацията, с кои СУБД и в кои среди за разработка, можете да изберете подходящия продукт. Например, ако възнамерявате да използвате Rational, тогава е по-добре да инсталирате Rational Clear Quest като система за регистриране и проследяване на грешки. Освен това в началния етап, като работеща база данни, е по-добреизберете Access поради лекотата на конвертиране на данни от него във всичко с последваща промяна в контролния софтуер.

Като всяка драсканица, BTS в началото среща отхвърляне от страна на програмистите, но след почти седмица те не могат да работят без нея. Друг допълнителен плюс на тези системи е формализирането на комуникацията между отделите и премахването на недоразуменията по въпросите на отговорността. Плюс за мениджърите - начин за обективна оценка на нивото на квалификация и принос към общата кауза на своите служители.

Три условия за успешен старт

По този начин, за първичната организация на тестването, е необходимо да се изпълнят, може да се каже, условията на трите "F":

формализиране на задълженията - писане на длъжностни характеристики и правилник за отдела;
формализиране на комуникацията с програмистите - въвеждането на BTS;
формализиране на работата на тестерите - създаване на тестови случаи, планиране и получаване на тестов доклад.

Всъщност това, което отличава добрия производствен процес от лошия е, че той не е оставен на произвола, а е подреден и контролиран.