Дизайн на теста, нормално тестване
От най-лошия приятел на програмиста
Архив за категорията „тестови дизайн“.
...и всеки тестер може...
Триста пъти "ха-ха-ха"!
Сподели връзка:
хареса това:
Простота и яснота на дизайна на теста
Дефиниции на дизайна на теста
Ето най-простата дефиниция на понятието "дизайн на теста", една от най-често срещаните и най-логичните:
1) Дизайнът на теста е начин да измислите по-малко тестови случаи, но все пак да поддържате "максимално покритие"
... и в същото време е най-идиотското (защото е невъзможно да се поддържа това много ценно "максимално покритие" с насилствено намаляване на броя на проверките).
Сподели връзка:
хареса това:
Дизайнът на теста е бъркотия
Сподели връзка:
хареса това:
Стартиране на Allpairs
PairWise е един от най-готините аналитични подходи в софтуерното тестване. Като чук.
Ако ударите главата на врага с чук, печелите. Ако пропуснете - отидете да научите ...
Според pairwise.org има много софтуери за този бизнес, както от Microsoft (има няколко от тях, не само PICT), така и от NASA (вече не е наличен, летял в космоса), от Motorola, от IBM и т.н.
Сподели връзка:
хареса това:
Тестване на Redbrick
- ... Като цяло, тъй като нашата терминология е английска, англоговорящите англоговорящи я възприемат като цяло по различен начин от нас. Например „Регресионно тестване“ първоначално се възприема от нас като „тестване на Blablabla“ и те просто чакат дефиницията му (всякаква), защото звуците не подсказват нищо. И те разбират думите отделно и тези думи отделно подсказват много сами по себе си. Как лесно да дешифрираме термини като "Министерство на социалните и социалния труд". Бо контекстИма.
- Е, това е разбираемо.
— Разбирам, разбирам… Например, знаете ли за най-готината техника за проектиране на тестове — тестване с червена тухла?
- Ако бяхте англоговорящ човек, вече щяхте да попитате “What the hell, bro, what kind of red-brick testing?”. И така... можете да поставите всеки фуфломицин под това тестване с червени тухли и никой няма да се съмнява. По-късно ще има доклади за това на конференции.
- Да, но ние го наричаме "треньор". Продължаваме напред. Дизайнът на теста не е "най-добрият начин да се измислят тестови случаи". Това е аналитична работа с непредсказуеми резултати... А тестовите случаи се появяват просто като следствие от анализа. Без анализи - без тестови случаи. Има анализи, но лоши - ще има лоши тестови случаи ...
Сподели връзка:
хареса това:
Тест дизайн в човешките ръце на тестер
Миналата събота участвах в Лвов на QA Meetup от Binary Studio:
Като цяло възнамерявах да направя презентация на последователното прилагане на техники за проектиране на тестове, но след като публиката реагира на някои идеи, разбрах, че ако премина към демонстрацията, тогава всичко ще „трепти“, защото причините за действията и заключенията няма да бъдат очевидни за тази публика. Затова в движение превключих на различен формат на презентация, за щастие няма нужда от слайдове. В същото време говореше по-бавно.
Такъв тестов дизайн е дълбока тема, не можете да хвърляте хора, които не могат да плуват, и да се удавят в него, защото не се нуждаем от удавени хора.
Относно самата среща: мощно организирана, всичко е взето предвид, закуската като цяло е страхотна!
Какво забелязах в GENERAL: meetup означава среща на специалисти от дадена индустрия в неформална обстановка за обсъждане на тема или няколко теми. Като конфитюр за музиканти. Но докладът се обръщанеформалността на срещата в мини-конференция, в която има много формалности, които се спазват от всички, нищо не може да се направи по въпроса. Тази среща също прилича на миниконференция, само че действието се развива в офиса
Същата вечер погледнах в новия склад на Лвов със стари якета и немски каски - страхотно място, учтиви гости все още чакат там!
Лвов, "Зализна шапка"
PS Ако имате нужда от превод на заглавието, тогава: "Тест - дизайн в лудите ръце на тестера."
Сподели връзка:
хареса това:
Състояние – Действие – Състояние
Таки разбра защо тестването на State Transition не предизвиква незабавен ефект на ох-уей за повечето хора, които са затънали в тестването.
Това е най-„тестът за преход на състояние“
Неволята вече е описана от професор Преображенски в съответната литература като първопричина за опустошението.
Тук трябва да мислите "първоначално състояние на системата - действие - различно състояние на системата".
И ние се учим да мислим чрез тестови случаи като "Действие - Резултат от действие".
Тук "кръгове" също не се оказват.
И се оказва нещо като „Продуктът е наличен в количката – Продължете към плащане – Страницата за плащане е отворена“. Какви глупости, възхищавайте се на вашия полиграф ...
Е, тогава вечната шумерска тъжна песен започва да успокоява сърцето (просто изберете любимата си и добавете вода):
- Нямаме време за дизайн на тестове...
- Това не се използва в нашия проект...
- Никой в проекта не казва каква техника трябва да се използва ...
- Тествам само за еквивалентност и стойностни граници и това е достатъчно...
- Моля, помогнете помогнете...
- Всички тези техники са за маниаци, те наистина не носят нищо ...
- Ще го използвам, акотова наистина ще помогне за намаляване на броя на тестовете...
- Тестов случай е, когато трябва да проверите какво трябва да се направи стъпка по стъпка и софтуерът работи ...
- аз съм клоун...