floyder

А дефекты всё равно найти надо

В чем цель тестирования? Кто ваш заказчик? Кто конечный потребитель?

Люди могут быть отличные, процессы - не очень. И наоборот. Вас хотят мотивировать и тотально контролировать. Так не бывает. Программист > Тестировщик - извините, это вообще бомба.
Много копей было сломано в обсуждениях KPI тестировщиков. Однозначный вывод на сегодня - исчисляемых сбалансированных KPI для тестировщиков не существует. Можно считать метрики, опираться на них при принятии решений, но завязывать на них финансы - самоубийство.
Косвенным образом можно посчитать сроки-качество (сроки: отклонение от baseline, качество: число критичных/блокер багов после релиза).

Даже если стоит "опыт от года", работодатель в большинстве случаев готов будет взять начинающего тестировщика. При условии, что зарплата будет соответствовать вашему уровню.
Пройдите хотя юы одно собеседование. Оно вам поведует больше, чем все наши советы на форуме.
Вот еще неплохая заметка про собеседование со стороны работодателя:
http://rinauzhevko.b.../2012/09/3.html

Если у вас отсутствует документация на проект, добро пожаловать в scrum. Для начала советую определиться с целью тестирования. Если цель - сделать заказчика счаствливым, тогда читаем дальше.
1. Ежедневные митинги с обсуждением тасков - позволят структурировать информацию и выбрать приоритеты (кто-то должен писать или озвучивать юзер кейсы)
2. Планнинг покер и другие игрушки - позволяют обмениваться участникам горизонтальной информацией

Есть желание командой вести что-то типа скрам-стендапа, только письменного, где будут записываться некие мини-репорты о том, чего сегодня делал. Очевидное решение - гугльдоки, но хочется послушать опытных коллег, может быть, посоветуете что-нибудь более удобное. Для сервиса ограничение - простой, бесплатный, и очень желательно интегрированный с basecamp'ом - есть ли что-то такое?

Какую роль в процессе занимаете вы? Чего вы хотите от отчетов?

kitsune
Статистику поднять можно. Но к ней нужны конкретные пути решений. Допустим, мы узнали, что defect leakage слишком большой. Что с этим делать?

Мне помогает переключение на другое приложение, а потом снова возврат к нужному.

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

Багхантинг не лучшая практика и приводит к

И получите вы набор багов типа "Здесь не хватает запятой, тут шрифт не тот и еще картинки некрасивые". А за серьезными вещами никто не будет следить, так как времени на это уходит на порядок больше.

а применение

А как насчет ввести "Весовой коэффициент" бага?

приводит к конфликтам, тк "Весовой коэффициент" - экспертная оценка и зависит от мнения конкретной личности.

Скажите, эти критичные баги на поверхности того функционала, который был протестирован тестером?
Или по каким-то причинам нет?
То есть, личный прокол некоего тестера или скорее недочет тестовой стратегии/манагера или кадровой политики в общем.

Случаются и те, и те случаи. Эффект замыливания довольно высок при такой частоте регрессионных тестов. И стоит смириться с тем, что человек не робот, и на 100% полноту прохождения сценариев гарантировать нельзя. Опять же эффект пестицида.

Можно ли как-то роботизировать данный процесс?