Как истинските тестери се различават от фалшивите лаборатория за качество
Днес не можах да заспя. Тежките мисли затъмниха смъртното ми съществуване от няколко дни.
Основният им източник (или по-скоро катализаторът) е описанието на тестовата зона на уебсайта на SQA Testing School, намиращо се в Силициевата долина. В това описание тестването е представено като елементарна област, която можете да научите много бързо, имате нужда от минимум знания за това и можете да спечелите много добри пари от това.
Първата праведна мисъл беше: тестване обиден!
Първият беше заменен от втория, по-балансиран: описаното е съвсем вярно. Намирането на работа като тестер е лесно. Лесно е да си лош тестер и да не те уволнят. Да не донесете и най-малка полза от проекта и в същото време да печелите прилични пари е лесно.
Но има, има истински гении в техния занаят, които са полезни и въпреки "блатистия" пазар на труда в областта на тестването, те са висококвалифицирани специалисти!
Кои са те?
Как да разберете истински джедаи от фалшиви тестери?
Резултатът от мисълта беше СПИСЪК НА ДЕСЕТ РАЗЛИЧИЯ НА ИСТИНСКИ ТЕСТЕР ОТ ФАЛШИФ.
1. Реални тестери с проекта едновременно.
Истинските тестери не са врагове на програмистите. Истинските тестери нямат за цел да „разбият продукта“ и след това саркастично да потрият ръцете си. Истинските тестери обикновено не са доволни от наличието на проблеми, грешки, дефекти и грешки!
За да бъде полезно за проекта, тестването трябва да действа като услуга. Грешките не са продукт, който трябва да бъде пуснат. Грешките не са полезни. Само дейности, насочени към постигане на общи цели, носят полза.
И за това ви трябва:
- вземат предвид целите на проекта
- адаптиране към външни условия (приоритети, срокове, цели, задачи на високо ниво)
- да може да разбере КАКВО трябва да се направи СЕГА, за да помогне на проекта да постигне целта си?
Ако тестването е неефективно, грешките се намират със закъснение и некачественото стартиране, тогава ще има все повече и повече: лошата локализация на дефекти отнема време от разработчиците и тяхното установяване в неприоритетен ред води до затруднения в Поправяне.
Ето защо, вместо задачата „как мога да намеря куп грешки и да попитам разработчици на DDOS“, истински тестери си мислят: „От какво се нуждае проектът сега, в какъв формат и с какви приоритети?“.
2. Истинските тестери знаят как да проектират тестове.
Без монклик и тестване на Redlot!
Истинските тестери знаят как да проектират тестове. За да направят това, те поне научиха библията на тестовия дизайн на Лий Коупленд и най-много усвоиха контрола на риска за качеството.
В зависимост от условията тестването може да се извърши изследователски или според тестови случаи, но тестовете не се правят от булдозера „Натискам бутоните“, а само според резултатите от анализа: какво трябва да се тества, в какво приоритет и как може да се направи най-ефективно?
За целта всяко изпитване започва с изследване на продукта, фактори, влияещи върху неговата работа и последващото им разделяне на класове на еквивалентност.
Помислете първо, а след това тествайте!
3. Истинските тестери разбират архитектурата на тествания софтуер.
Не е нужно да сте напреднал разработчик, за да бъдете истински тестер. Но за да разберете как ефективно да тествате приложението си, просто трябва да знаете неговата архитектура.!
Тестването на черна кутия не позволява да се тества продукта в детайли, а тестването само „от потребителя“ води до факта, че много фактори, влияещи върху работата на софтуера, не се отчитат.