Как совет могу сказать, что ваши кейсы должны быть в таком виде, чтоб любой человек смог разобраться,в вашем же случае я что-то совсем мало что понял.

Плохой совет. Любой человек не придет и не начнет тестировать, а времени на написание такого рода тестовых описаний уйдет много и будут они еще скорее всего трудно-пререписываемы и быстро-устареваемы.
Писать тестовые описания, на мой взгляд, надо так, чтобы они были максимально понятны участникам процесса. При этом желательно, чтобы это не отнимало много времени (ведь тестировать важнее, чем писать описания) и чтобы были устойчивы к незначительным изменениям.

А какие конкретно у вас затруднения с баг-трекером?
На последней конференции я кое-что рассказывал по этой теме.
http://www.slideshar...haL/ss-10392275

Посмотрите, может найдете там ответы. Если нет - пишите сюда, или в отдельную ветку, постараюсь ответить. Или вообще лучше в личку пишите, т.к. я на форум последнее время захожу раз в неделю где-то.

Добрый день!
Во-первых, хочу поддержать ребят, которые говорят о том, что тестовое задание надо давать хотя бы после интервью, а не до него. Причин несколько, думаю они будут понятны из написанного ниже. Я бы предложил такую схему:
Изучение резюме и телефонный скрининг (для определения того, что человек хочет выполнять предлагаемую работу в принципе) -> техническое собеседование (лучше когда несколько человек, всей командой не обязательно, не все любят) -> тестовое задание (опционально, в них есть несомненные плюсы) -> второе интервью для определения условий итд (желательно с руководством) -> офер (для победителя).

Во-вторых, можете посмотреть видео моего недавнего выступления о том как я работу менял. Взгляд соискателя:

В-третьих. 2-3 дня на такое тестовое задание абсолютно нормальный срок (это для тех, кто что-то подозрительное тут увидел). Не забывайте, что кандидат может иметь работу, на которой у него есть задачи, другие интервью и тестовые задания, семью итд. А лучше всего спросить самого кандидата за сколько он сможет сделать задание. Это тоже показатель.

Тоже хочу кружку! так и запишите +1

И еще покажите мне, плиз, кнопочку "Напечатать программу конференции", чтобы она так красиво сразу и на принтер ушла.

Программу в данный момент печатать еще рано. Для печати будет сделана специальная версия, скорее всего в PDF формате. По крайней мере сейчас планируется сделать именно так.

Еще хотел спросить, входит ли в обязанности тестировщика исправление ошибки, на уровне исходников программы, в моем случае или это зависит от организации и предъявляемым требованиям?

з.ы. вроде осознал, Тестировщик должен найти проблему и передать в вышестоящие инстанции(н-р прогерам), а они уже будут решать проблему...

На мой взгляд, за исключением редких случаев - не должен. Вы правильно осознали. Если тестировщики начнут править код, а программисты исправлять тесткейсы - то что это за балаган получится?
Но если вы нашли ошибку или даже только подразумеваете где она есть в коде - вы можете добавить такую информацию в описание дефекта. И чем больше вы уверены в этом - тем больше должны. Сохраните кому-то время. Можете даже приложить исправленый вариант, если исправление маленькое. Не факт, что программист именно так исправит баг, но рабочий вариант его может навести на определенные мысли.

И ошибки обычно складывают в специальное место, которое называется дефект-трекером - там их все видят и когда они там - о них все знают.

Да и кроме главного направления тестирования в каких еще направлениях смотреть - HTML, sql, Java? Я просматривал чужие резюме и заметил, что много чего мелькает, но что подучить, не сильно отвлекаясь от основной темы ТЕСТИРОВАНИЕ?

Одним из возможных преимуществ для работодателя может быть знание предметной области.