VLana

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

Неправда.

Правда.

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

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

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

Немного сумбурно получилось...

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

У нас поступают следующим образом:
Разработчикам ставят сильные машины (ну еще бы, у них столько всего открыто одновременно).
Тестерам на класс пониже.
А уж что стоит у заказчика.. бывает и очень слабое железо.
У нас приложение клиент-сервер.
Со стороны клиента тестеры выявляют слабые места.
Со стороны БД- есть специальные программы, которые оценивают "тяжесть" запросов.
Эти запросы детектятся и передаются обратно в разработку на оптимизацию.
Оставшееся пишет заказчик.