Анализ на тестове и дизайн на тестове

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

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

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

Конференции

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

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

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

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

Доклад на Максим Богуславски, ръководител на отдела за осигуряване на качеството, banki.ru на конференцията CodeFest 2015.

В моя доклад искам да говоря за:

Защо традиционните методи за проектиране на тестове от Karner и Miles не работят в конкурентна среда?
Как да тествам огромен портал за 1 час?
Как да вземем решение за допустимост на внедряване в условията на кратки срокове, несигурност и известни дефекти?
Как да определите, че всичко върви по начина, по който се изисква, и да продължите да работите без извънреден труд?

Елате на разговора ми и ще ви кажа какво може да се направи за три години с екип от страхотни инженери и как да дадете възможност на един бизнес да завладее пазара и да спечели пари.

Тестовият анализ е основен компонент на тестването. В Amazon има много книги на тази тема, но нито една от тях досега не е преведена на български.

Какво представлява тестовият анализ? Какви задачи решава тестовият анализатор? Какви видове анализи и изследвания на тествания софтуер съществуват?

За да отговорим на тези въпроси, публикуваме първия уебинар на Наталия Рукол за курса „Училище за анализ на тестове“. От него ще научите за ролята на тестовия анализатор, задачите на тестовия анализ и форматите за изследване на софтуерни продукти.

Доклад на Алексей Лупан на онлайн конференцията за тестери Fun ConfeT&QA, пролет 2012 г.

Един обикновен тестер започва кариерата си с тестови случаи и завършва чудесния си жизнен цикъл с тях.

Вик от тълпата: „Камон! Долу тестовия случай!“

от площадабръмчи: "Дааааааайош старите поръчки обратно!"

Мурка в кожено яке ни докладва от трибуната: „Другари! Докога ще търпим господството на тестовите случаи?! Имаме нужда от забавление! Весело, другари! Забавно!"

Нека започнем веднага, нека "Отречем се от старото меееееее"...

Речта на Алексей Баранцев на онлайн конференцията Fun ConfeT&QA за тестери.

Техниката за покриване на комбинации по двойки (тестване по двойки) е може би една от най-„магическите“ техники. Стотици опции? Милиони милиарди трилиони децилиони комбинации? Няма проблем! Вземаме Magic Tool, поставяме в него данните за тези параметри, натискаме Magic Button. Бъркотия от числа - и изходът е само дузина комбинации, които трябва да бъдат проверени.

Виждал съм две крайности в прилагането на тази техника.

Една крайност - ползвайте навсякъде, със зашеметяващо елементарна обосновка за приложимост - "е, малко са тестовете, готино е!" Другата крайност е пълно отхвърляне на използването на тази техника, със също толкова прекрасно обяснение - "не е ясно как работи и има подозрително малко тестове, не вярвам!"

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

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

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

О, да, разбира се, определено ще покажа Magical Tools, как без него :)

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

Какво е SharePoint?

Преди да преминете директно към спецификата на тестването, си струва да кажете няколко думи за самата платформа SharePoint. Всъщност това е CMS (Content Management System), която съдържа разработена система за управление на документи – DMS (Document Management System). За да бъдем абсолютно точни, възможностите на SharePoint, подобно на CMS, са в "елементарно" състояние, но със задачите за организиране на сътрудничество, създаване на файлов архив и управление на документи, той се справя на "най-високо ниво"! SharePoint най-често се използва за създаване на корпоративни интранет портали, предназначени да улеснят взаимодействието на служителите в една и съща компания или организация.

И така, SharePoint е уеб базирана платформа за сътрудничество и система за управление на документи, разработена и внедрена от Microsoft. Така тази платформа се превръща в единен комуникационен център и едновременно с това електронно хранилище на информация. Това решение може да се използва за създаване на корпоративен уеб портал, който хоства споделени документи или специализирани публични приложения. Данните в SharePoint са организирани под формата на списъци (например задачи,дискусии, календари) и библиотеки с документи. Функционалността на SharePoint се представя на потребителя чрез уеб части, контроли, които показват списъци и им позволяват да бъдат редактирани. Тези уеб части се хостват на страници, които на свой ред се публикуват в портала и са достъпни за потребителя чрез браузър. SharePoint е по същество приложение ASP.NET 2.0, което използва IIS за показване на уеб страници и SQL Server за съхраняване на данни.

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

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

Какво се случва, ако потребителят, случайно или умишлено, премине такава технологична граница - въведе твърде голямо число или твърде дълъг низ? Трябва ли тестерът да се опита да разбере? Или може би е достатъчно да предупредим потребителите, за да не въвеждат "лоши" данни и кой е въвел - ние не носим отговорност? И ако все пак решихме, че тестерът трябва да се опита да провери всичко това, как да търсим тези граници, ако никъде не са описани?

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

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

Искате ли да научите повече за различните техники за проектиране на тестове? Елате на онлайн обучениетоTest Design Workshop или обучение лице в лице в Москва Test Design from A to Z

Запис на доклада на Алексей Лупан от онлайн конференцията Fun ConfeT&QA.

Обичаме да пишем тестови случаи толкова много, че научаваме този бизнес буквално от началото на първия ден на тестване до края на втория ден. След това завършваме цялата си кариера. Понякога пишем малки тестове, понякога извайваме картини на Ботичели. Предложете алгоритъм за „златната среда“ за писане на компетентни тестови случаи?

Продължаваме да публикуваме най-добрите доклади от SQA Days 13. Днес представяме доклад на Никита Налютин „Математика за тестери“.

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

Резултатите от следващата онлайн конференция за специалисти по ръчно тестване Fun ConfeT&QA бяха обобщени. Както обикновено, ние публикуваме най-добрия доклад въз основа на резултатите от гласуването. Това е докладът на Наталия Рукол „Анализ на тестове въз основа на състоянияи преходи.

Много тестове, които извършваме, са интуитивни за нас: опитайте се да въведете стандартни и не много стойности, извикайте една и съща функция от различни менюта, проверете комбинации от параметри и техните стойности. Но освен тях има и много по-малко очевидни тестове, които могат да открият сериозни грешки: тестове за определени последователности от действия.

Как са проектирани тези тестове?
Как да осигурим високо покритие без прекомерен брой тестове?
Какви инструменти има за тестване на състояния и преходи и как да ги използвате?

Докладът ще бъде полезен за тестери и дизайнери на тестове, а след него (надявам се) ще можете да прескочите значително по-малко критични дефекти.

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

Речник

В рамките на тази статия ще нарекаскриптово тестване, преди началото на което се създават тестове и вече се извършват проверки срещу тях. Като алтернатива на скриптовия подход могат да се разглеждат ad hoc, хаотично и проучвателно тестване, но за тях в отделна статия - ода за проучвателното тестване. Засега просто ще разделим тестването на скриптово (на базата на предварително написани тестове) и без скрипт, след коетоима ли друга