Здравствуйте, McSeem2, Вы писали:

ГВ>>Начальство хочет быть уверенным, что кто-то помимо тебя сможет проверить работоспособность этой фичи. И что если кто-то, кроме тебя доработает эту фичу, то он сможет удостовериться, что всё работает как надо. В принципе, желания вполне разумные.

MS>>>А я-то откуда знаю, как?!
ГВ>>Макс, ты не знаешь о своей фиче ничего.

MS>Если бы я был в чем-то не уверен, я бы с радостью написал этот план, типа обратите пристальное внимание вот на такие-то условия. А то, что от меня требуют мне напоминает коментарии в коде, типа ~ClassName() // Destructor

Э... Знаешь, есть такой закон Мерфи: "Настоящие программисты не тестируют"? Ловятся если не все, то почти все, и что характерно, все уверены в том, что вот у них-то всё совершенно нормально. В смысле, я не думаю, что ты непременно поймаешься, но уверенность слегка настораживает.

MS>Я однажды добавил к такому коменту в реальном коде "yes, Captain Obvious guaranteed!!!". Задача тестера — найти такие условия, при которых фича глючит — и такое случалось, при чем безо всяких тест-планов. Молодцы студенты-тестеры, они мне очень помогли. А если бы был формальный тест-план, ни фига бы не нашлось. Потому что я сам уже это все проделал и проверил.

Кажется, начинаю понимать... Попробуй сыграть по всем правилам: перечисли в том тест-плане полный список параметров, граничнные значения, ожидающиеся характеристики под нагрузкой (если применимо). Это немного out of scope для тест-плана, но всё-таки. Приведи несколько характерных тест-кейзов для примера и ещё — негативные кейзы, то есть такие, где должны вылететь ошибки. Играть, так играть, чего уж там!

Рыбу тест-плана можешь погуглить, но по сути в нём всё просто: зачем, как, в каких условиях, какие кейзы, что должно быть на выходе, что считается приемлемым результатом тестирования (ну там, краш не чаще, чем раз в 5 минут ).

MS>Еще прикольная история. [...]

Клёвый у тебя директор, Be fair to yourself — ценное качество. За это и натриеэбонатизм с сараем простить можно.