anatashka

Моя хата с краю, ничего не знаю? Отчетик написали, а остальные пусть сами выкручиваются? - риторические вопросы.
Почему написание отчета не считается тратой драгоценного времени, которое можно использовать для тестирования?

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

Ув. LeshaL, вы меня абсолютно правильно поняли. И очень верно дополнили. :-)

Это просто описание того как с подобной ситуацией справлялась я.
Я не заявляю, что это абсолютно правильное решение, но это работало.

Моя хата с краю, ничего не знаю? Отчетик написали, а остальные пусть сами выкручиваются? - риторические вопросы.
Почему написание отчета не считается тратой драгоценного времени, которое можно использовать для тестирования?

Ну, так не моя же вина, что запустили до такой степени. Я считаю, что в таком случае я выполнила свою работу настолько насколько это возможно в сложившейся ситуации.

А написание отчетика - не занимает много времени (обычно есть документ, который заполняется перед тем как продукт отдается заказчику). Оно скорее несет информативный характер, чтобы потом было меньше негативных сюрпризов.

+ у нас, например, было много подобных случаев и описанное мною поведение скорее сложилось из опыта работы в конкретной команде. Пробовали мы поступать и так как вы предлагали, ув. Clauster.

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

2) требовать изменения срока поставки тоже пробовали. :)
Иногда это получалось, но иногда были случаи когда поставка версии итак до этого не однократно переносилась по разным причинам и больше оттягивать уже нельзя. И следовательно все равно результат был как в пункте 1.

К сожалению в реальной жизни такие случаи не редкость (лично у меня так часто случалось).

Т.е. с заказчиком оговариваются сроки, которые нарушать никак нельзя. Разработчики тянут до последнего, дорабатывают что-то, или срочно чинят то, что неожиданно сломалось в процессе добавления нового функционала. И даже если везде прописано, что у тестировщика должно быть минимум 3 дня для предварительного тестирования его все равно ставят перед фактом, что его надо сделать за 1 день (ведь нехорошо подводить заказчика.. он же нервничать будет..). Почему только это не так часто говорится разработчикам??? ;-)

В общем поскольку это все-таки наша работа, то ходить по всем менеджерам и жаловаться на жизнь, по моему мнению только трата драгоценного времени, которое можно использовать для тестирования. В общем я в таком случае делаю так:

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

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