PM Stories » тестване

100 въпроса при интервюиране на софтуерни разработчици. Част 2 – кодиране и тестване

Майк Рам — Sun, 15 Mar 2009 18:31:46 +0000

В тази серия от постове ви предлагам въпроси към кандидатите за работа на позиция “Софтуерен разработчик”. Въпросите ги заимствах от Jurgen Appelo от блога NOOP.nl, който е изготвил един голям списък от 100 въпроса, разделен в 10 категории, според областите на знание, дефинирани от Software Engineering Body of Knowledge (SWEBOK). Препоръчвам ви да си свалите и самия The Guide to SWEBOK от там – една важна и полезна книга за софтуерни разработчици.

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

Кодиране

Кое ви интересува най-много, когато правите ревю на чужд код?
Кога използвате абстрактен клас и кога – интерфейс?
Освен IDE-то, кои други помощни средства използвате и считате за особено полезни?
Как осигурявате вашия код да бъде едновременно бърз и сигурен?

Алгоритми

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

Структури от данни

Как бихте записали стойността на един цвят в база данни по най-ефективния начин?
Как бихте записали N-мерен вектор в база данни?
Как бихте записали резултатите от футболно първенство (отбори и резултати) в XML документ?

Тестване

Знаете ли какво е тестване за регресии (regression test)? Как бихте подсигурили, че новите промени няма да “счупят” работещата функционалност?
Знаете ли какво е покритие на кода (code coverage)? Какви видове покритие на кода съществуват?
Какво бихте направили, за да намалите възможността потребителя да открие бъгове по време на приемните тестове?

Следва продължение.

Гласувайте за тази статия в Svejo.net:

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

Вижте и тези публикации:

Кой тества вашия продукт? Резултати от анкетата

Майк Рам — Wed, 02 Apr 2008 13:32:37 +0000

Оказа се, че тази анкета нещо съм я забравил и стои от много време на сайта, а няма особена активност по нея. Дали въпросът не е интересен или просто който е имал мнение вече го е дал – не знам. Но времето на тази анкета изтече, а имам и други въпроси, които искам да ви задам, затова я затварям и обявявам резултатите.

Въпросът беше: Кой тества вашия продукт? Общо гласувалите в анкетата са 66 човека, като разпределението на отговорите е следното:

Тестери – членове на проектния екип (36%, 24 гласа)
Отдел по качеството във фирмата (23%, 15 гласа)
Програмистите (23%, 15 гласа)
Клиентът (18%, 12 гласа)

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

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

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

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

Гласувайте за тази статия в Svejo.net:

Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл.

Вижте и тези публикации:

Кой тества вашия продукт?

Майк Рам — Sun, 20 Jan 2008 16:14:45 +0000

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

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

По-интересен е случаят, в който тестването е неотменна част от жизнения цикъл на продукта и с това се занимават нарочно определени хора. Тук отново съществува едно принципно разделение: в някои фирми тестерите са част от проектния екип – те участват в тестването на всички документи – още в най-ранната фаза на проекта – и остават в екипа до окончателното предаване на продукта на клиента, че даже и малко след това – по време на процеса на поддръжка.

В други фирми пък за тестването отговаря специален отдел по качеството, който не се числи към нито един проект, а извършва оценка на качеството на всички продукти, които се разработват в компанията. Обикновено този отдел се ръководи от Quality Manager – човек, който има последната дума по отношение на това дали продуктът покрива критериите за качество, зададени при самото стартиране на проекта. На този тип организация му казват Testing as service или тестването като услуга.

Въпросът е: кой е по-ефективният метод и кой е по-подходящ за нашия проект?

Напоследък се налага организация от типа “тестване като услуга”, може би поради това, че тестерите от отдела по качеството могат да бъдат по-ефективно натоварени. От друга страна, тестването като услуга има и своите недостатъци, един от които е изискването за предварително подготвена детайлна документация, което на практика е рядко срещано явление – най-вече поради постоянно променящите се изисквания от страна на възложителя.

В подкрепа на организацията, при която тестерите са равноправни членове на проектния екип, Johanna Rothman е публикувала един пост в блога PM Hut, озаглавен Тестването не е услуга. В него тя аргументира своята позиция със следното:

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

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

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

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

Гласувайте за тази статия в Svejo.net: