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

----------------------------------------
Здрав дух, в здрава бутилка!

И последно кое е по-упорито - петното или кашлицата

Съдържаниет е скрито
Влезте за да го видите

Бира, кола, кафета, пици, дългокраки секретарки и прочее ... но това не са от важните фактори

Съдържаниет е скрито
Влезте за да го видите

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

Правиш една фукнционалност, след това и правиш тест, после започваш следващата ... това за мен е правилния подход, но това не е ТДД.

----------------------------------------
Здрав дух, в здрава бутилка!

Чакай сега, ами какво правят модерните напоследък на само в квартал Кастро в Сан Франциско така наречени юзър експириънс пичове? Те не следят ли от страната на клиента какво ще стане?

Девелопера автоматизира това е ясно и пише юнит тестове, добре, аз не мога да разбера QA-те дето не могат да програмират и автоматизират какво правят точно?

Все пак не забравяй - заплата на едно QA - вноска за Кайен. Примерно ако сложиш на един кантар, от тия с везните дето Темида ги носи - един Кайен на едната везна и едно QA на другата, кое ще е натежи повече? Според мене Кайено тежи доста повече от едно QA.

Редактирано от Mr T на 12.11.08 16:25.

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

Но юнит тестовете са много добри при регрешън. Примерно идва ти бъг от QA-a (тука си представи, че ако го нямаше този QA нямаше да го има този бъг но можеше да има Кайен) и преди да го фикснеш пишеш тест който да фейлва, след фикса теста трябва да мине и така остава регрешън тест.

Ако се прави постоянно (да кажем тийм от 4-5 девс фиксват 2-3 бъга на ден всеки), може само за 3-4 месеца да имаш страхотен пакет (не това което си мислиш, друго) от 2000 регрешън теста и да махнеш 1-2 QA-та и с парите да си купиш... сещаш се.

<quote>
:) тестването на SP става чрез известното от време оно полуавтоматично средство - QA .
</quote>

И как работи това? "Пешооо, смениш сторната процедура дето вади броя на бикините по доставчик, виж там дали не се е насрало нещо като се върнеш от обяд"

<quote>
В сорс контрол се пази script-a на цялото DB.
</quote>

И как работи това? При всяка една промяна на нещо в ДБ, експортваш скрипта, слагаш го във файл и той стои в соурс контрола? Всеки от тийма прави това? Или как? Нещо слуша за промени и автоматично при промяна експортва скрипта? Всичкия код на всичките процедури в един файл ли е? Ами ако са 1000? Ами ако трябва да провиш порт от MSSQL към Оракъл какво правиш? Целия T-SQL го преписваш на PL/SQL? На ръка?

пич
:) ако базата се променя толкова често, че едва ли не излиза извън контрол, то проблема със сигурност не е в базата. Смени си шефовете, ПМ, ТЛ или там който е безотговорния фактор!

Edit: Пак да кажа! Липсата на идея кво праиш, никога не прощава в дългосрочен план. Ако аз требе а си сменям структурата на базата едва ли не всеки ден, ще се самоубия ритуално! Какво по дяволите правиш, ако поне една шибана ДБ не си дефинирал така, че да не оцелее повече от ден като структура !

Редактирано от mlee на 12.11.08 22:45.

Ей тук има обстоен флейм за и против сп-тата, струва си да се прочете. Обосновани мнения.

Съдържаниет е скрито
Влезте за да го видите

В отговор на:

---

можеше да стане въпрос за BDD, и дали някой реално го е пробвал

---

Съдържаниет е скрито
Влезте за да го видите