Тестване? И как става?

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

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

- Програмисти отказват да пишат тестове (имало си тест-инженери за тая работа);
зависи,може да трябва да пишат може и друг да им ги пише,според случая, но тоя вилм отказват не го рабирам...ако няма кой да ги пише,какво значи отказват ......отказват да работят?

- Понякога тестването е от типа: "Юруш! Ръгай скриптове, код, щракай с мишката, дай резултат";
глупости отново :) има си добре изпипана методология за тестване, май в ISTQB най-чисто е описана

- Аз лично имам чувството, че понякога на тестерите им се плаща на брой отрапортувани бъгове, като гледам какви чудеса правят;
пак глупости, щом се правят бъгове редно е да се репортват, ако не са реалистични просто се затварят или се обяснява на тестера да не прави глупости

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

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

При вас по-различно ли е?
да много (явно)

От моя гледна точка на кратко
В сегашната ми фирма пишем юнит тестове, но не за всичко само за някои неща. Разбира се си тествам нещата преди да кажа че са готови и после те се тестват от екип тестери, които не съм и виждал. И не събмитват много бъгове, принципно гледам да си пиша нещата без много бъгове и това ми отнема повече време от бързото изкодване. А така правят някои, кодят кодят и го изкодват бързо и след това 100-200 бъга. А неоткритите един бог знае.

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

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

Е така се тества :) [линк]

Малко допълнение от мен

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

- Понякога тестването е от типа: "Юруш! Ръгай скриптове, код, щракай с мишката, дай резултат";
глупости отново :) има си добре изпипана методология за тестване, май в ISTQB най-чисто е описана
ISTQB(International Software Testing Qualifications Board) не е методология за тестване, а организация, която прави стандарти в областта на софтуерното тестване. Методологията на тестване зависи от методологията на правене на софтуер (waterfall, agile, prototyping, etc., whatever) T.е. ако пишеш код без конкретен план и задача, можеш да очакваш същото и при тестването :)

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

Фирмата тества фалит

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

О, не са така само някои проекти, а повечето За това и не очаквам особено развитие.

Това си е живо ебане:)

когато няма дори 1 кадърен QM в цялата фирма.

Аз не мисля, че проблема е само в липсата на някакъв тип работници с титли. Не трябва да се прехвърля топката. Аз смятам (така е поне в embedded програмирането, не знам за другите области), че програмистите носят отговорност най-малкото за тестовете на ниско ниво. За мен дизайна, кодирането и component тестването никога не са били разделени дейности.

Говорейки за типове длъжности, какво стана с валидаторите от жонсан контролс

Пичове, няма никакъв смисъл от хора дето тестват по начина, който описвате. Като се пише код, се пише така, че да се самотества. Автоматизации, юнит тестове, или просто "the belief" както казва Ицо Стоичков, но ако се надяваш на тестери да ти проверят нещата, нещо е генерално не наред.

--
One day it will make sense.

Където се налага, практиките се развиват. Щото се налага. Щом тези практики ги няма, значи не се налага.

Или иначе казано, очевидно не е качеството фактора, който има значение за софтуера ви. Иначе досега да сте взели да го правите "както трябва" (не, че някой знае как трябва. Та тъй.

Ти базикаш ли се, програмист да откаже да си напише юнит тестове на собствения код. Уволняваш един или двама и да видиш другите как ще почнат да си вършат работата. Всъщност, проблемите ти не са в програмистите, а в калпави мениджъри, които не могат да наложат подходящ работен процес. С две думи, дори не можеш да уволняваш, защото мениджмънтът е бил толкова хитър, че е наел абсолютно минималната бройка хора, която вършат работата. Един да уволниш и ще се чудиш как да попълваш липсата му.

Хората не без причина са измислили екстремното програмиране.

Ефективното тестване много зависи от добре направения дизайн. Преди години, когато обикалях тръстиковите плантации в БГ съм виждал код, който просто не можеш да тестваш с юнит тестове, защото е написан безобразно.

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

:)За какво образование в университетите ни говориш? Погледни кодът, който се публикува в конкурса на Мусала. Половината са студенти и в кода им се вижда, че елементарно не могат да си подредят кода, пък не дай боже да трябва да търсят и отстраняват дефект в така писан код, но не 200 реда, а 200 000. Те до толкова са извън матрицата на нашия бранш, че не умеят един заглавен коментар да сложат в работните файлове и да си напишат имената, а какво да говорим за параграф уточняващ авторските им права. Кадрите излизащи от повечето български университети са пълна трагедия, а ти ни говориш за качество.

Замисли се как се финансират БГ софтуерните фирми и ще си обясниш много неща.

Ако 98% от БГ софтуерните фирми се финансираха със законни пари и само от продажбата на продукти или услуги, то нещата щяха да са много по-различни.

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