Прикольно на новой работе. Вот я добавил в софту новую мощную фичу, о которой все давно мечтали и оно наконец сбылось. Погоняли, нашли мелкие глюки, я поправил, в общем, нормальный рабочий процесс. А теперь, когда уже все работает, начальство требует составить план финального тестирования. Ну и че? — Ну я могу написать делайте то, нажмите сюда и т.д. Но какой в этом смысл?! Я объявляю новую фичу, подробно объясняю ее функциональность, а от меня еще требуют какой-то план, как ее тестировать! А я-то откуда знаю, как?! Я уже протестировал сам, прежде чем выдать и я гарантирую что этот план даст true. Я могу описать все шаги, но нафига это все, когда оно и так уже проверено? Задача тестера — поймать программиста. А если от программиста требуют описания того, как его поймать, то это вообще нонсенс. Нафига тогда тестеры нужны?
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Прикольно на новой работе. Вот я добавил в софту новую мощную фичу, о которой все давно мечтали и оно наконец сбылось. Погоняли, нашли мелкие глюки, я поправил, в общем, нормальный рабочий процесс. А теперь, когда уже все работает, начальство требует составить план финального тестирования. Ну и че? — Ну я могу написать делайте то, нажмите сюда и т.д. Но какой в этом смысл?! Я объявляю новую фичу, подробно объясняю ее функциональность, а от меня еще требуют какой-то план, как ее тестировать!
Начальство хочет быть уверенным, что кто-то помимо тебя сможет проверить работоспособность этой фичи. И что если кто-то, кроме тебя доработает эту фичу, то он сможет удостовериться, что всё работает как надо. В принципе, желания вполне разумные.
MS>А я-то откуда знаю, как?!
Макс, ты не знаешь о своей фиче ничего.
MS>Я уже протестировал сам, прежде чем выдать и я гарантирую что этот план даст true. Я могу описать все шаги, но нафига это все, когда оно и так уже проверено? Задача тестера — поймать программиста. А если от программиста требуют описания того, как его поймать, то это вообще нонсенс. Нафига тогда тестеры нужны?
А ты спрашивал, что в этом плане хочет видеть начальство? Общие подходы к таким документам есть, но они могут варьировать от организации к организации.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, McSeem2, Вы писали:
MS>Нафига тогда тестеры нужны?
В том числе чтобы тестпланы писать
Нормальное разделение труда.
Так что твое недоумение понятно.
Но тестерам нужно помочь. Дам им спецификации.
Без них они ничего толком не протестируют.
Без явных спецификаций еще можно что-то накодить,
а тестировать без них вообще толком невозможно.
Здравствуйте, McSeem2, Вы писали:
MS>Прикольно на новой работе. Вот я добавил в софту новую мощную фичу, о которой все давно мечтали и оно наконец сбылось. Погоняли, нашли мелкие глюки, я поправил, в общем, нормальный рабочий процесс. А теперь, когда уже все работает, начальство требует составить план финального тестирования. Ну и че? — Ну я могу написать делайте то, нажмите сюда и т.д. Но какой в этом смысл?! Я объявляю новую фичу, подробно объясняю ее функциональность, а от меня еще требуют какой-то план, как ее тестировать! А я-то откуда знаю, как?! Я уже протестировал сам, прежде чем выдать и я гарантирую что этот план даст true. Я могу описать все шаги, но нафига это все, когда оно и так уже проверено? Задача тестера — поймать программиста. А если от программиста требуют описания того, как его поймать, то это вообще нонсенс. Нафига тогда тестеры нужны?
Ну не знаю... вот бывают такие фичи которые крайне лениво программисту тестировать под всеми возможными нюансами. Время это занимает. Тестеру иногда кажется — а один фиг, все юзеры одинаковые, под любым протестирую. А на самом деле в бэкенде юзеры разные, и разные настройки могут непредсказуемым образом крашнуть систему. это только программист может сказать — что вот эту вещь желательно потестировать под юзерами с разным уровнем прав доступа и т.п.
я например ленюсь такое делать самой, я ж не тестер чтоб как обезьяна целыми днями кликать там. Я основное протестила, свои тесты написала, и дальше полагаюсь на тестировщиков и пишу им арии, которые надо проверить и которые знаю что могут повлиять на результат.
Здравствуйте, McSeem2, Вы писали:
MS>Прикольно на новой работе. Вот я добавил в софту новую мощную фичу, о которой все давно мечтали и оно наконец сбылось. Погоняли, нашли мелкие глюки, я поправил, в общем, нормальный рабочий процесс. А теперь, когда уже все работает, начальство требует составить план финального тестирования. Ну и че? — Ну я могу написать делайте то, нажмите сюда и т.д. Но какой в этом смысл?! Я объявляю новую фичу, подробно объясняю ее функциональность, а от меня еще требуют какой-то план, как ее тестировать! А я-то откуда знаю, как?! Я уже протестировал сам, прежде чем выдать и я гарантирую что этот план даст true. Я могу описать все шаги, но нафига это все, когда оно и так уже проверено? Задача тестера — поймать программиста. А если от программиста требуют описания того, как его поймать, то это вообще нонсенс. Нафига тогда тестеры нужны?
потом код поменяют и его надо будет тестировать опять.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, McSeem2, Вы писали:
MS>>Нафига тогда тестеры нужны?
B>В том числе чтобы тестпланы писать B>Нормальное разделение труда. B>Так что твое недоумение понятно. B>Но тестерам нужно помочь. Дам им спецификации. B>Без них они ничего толком не протестируют. B>Без явных спецификаций еще можно что-то накодить, B>а тестировать без них вообще толком невозможно.
Сначала подумал даже, что стихи...
80% людей оценивают свое мастерство выше среднего...
On 11.04.2013 14:17, bastrakov wrote:
> детектирую опыт в индустрии не больше пары лет, и возраст до 27.
Ну, вот только он в америках и зарплаты у вас сравнимы в циферках — у
него правда в баксах в год, у тебя в рублях в месяц.
Я так предполагаю, что у тебя около 100000.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Начальство хочет быть уверенным, что кто-то помимо тебя сможет проверить работоспособность этой фичи. И что если кто-то, кроме тебя доработает эту фичу, то он сможет удостовериться, что всё работает как надо. В принципе, желания вполне разумные.
MS>>А я-то откуда знаю, как?!
ГВ>Макс, ты не знаешь о своей фиче ничего.
Если бы я был в чем-то не уверен, я бы с радостью написал этот план, типа обратите пристальное внимание вот на такие-то условия. А то, что от меня требуют мне напоминает коментарии в коде, типа ~ClassName() // Destructor
Я однажды добавил к такому коменту в реальном коде "yes, Captain Obvious guaranteed!!!". Задача тестера — найти такие условия, при которых фича глючит — и такое случалось, при чем безо всяких тест-планов. Молодцы студенты-тестеры, они мне очень помогли. А если бы был формальный тест-план, ни фига бы не нашлось. Потому что я сам уже это все проделал и проверил.
Еще прикольная история. Приделал я тут CPU Meter. Ну софта реал-тайм, и если будет плохо, данные будут теряться. А этот митер показывает. А там может быть 128 оцифрованных аналоговых каналов в реал-тайме по USB. И нужен реал-тайм мониторинг всмякого-разного. И вот прежние двое прграммеров (да, царство им небесное, они оба погибли в бурных водах горной реки Западной Вижинии год назад. Я не был с ними знаком, но их код останется со мной навеки. Я уже начал различать, что писал один, а что — другой) просто делали то, что от них требуется. В результате получилась такая каша, что ее разгребать и разгребать. И вот я в такой ситуации и меня назначили типа главным. А конторка-то маленькая, вся продукция делается в гараже, где директор хранит свои мотоциклы. Если кому интереесно — marslabs.com
И вот по поводу этого митера разгорелся знатный срач. Ernie (директор) сказал, что это круто, внедряем. На что посыпалось очень много возражений со стороны маректинга, типа кому понравится, что наша софта не эффективна в определенных режимах. Но Ernie всех заткнул одной фразой — Be fair to yourself. И намекнул, что наши клиенты именно за это нас и любят, если допустил лажу — ну так и скажи, любой инженер поймет. Ну, и маркетинг заткнулся. К счастью, во всяких фордах и космических отраслях инженеры таки рулят. Я очень уважаю этого человека. Хотя и ненавижу. Потому что он, блинн, в точности такой же эбонат натрия как и я, только чуть старше.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
ГВ>>Начальство хочет быть уверенным, что кто-то помимо тебя сможет проверить работоспособность этой фичи. И что если кто-то, кроме тебя доработает эту фичу, то он сможет удостовериться, что всё работает как надо. В принципе, желания вполне разумные.
MS>>>А я-то откуда знаю, как?! ГВ>>Макс, ты не знаешь о своей фиче ничего.
MS>Если бы я был в чем-то не уверен, я бы с радостью написал этот план, типа обратите пристальное внимание вот на такие-то условия. А то, что от меня требуют мне напоминает коментарии в коде, типа ~ClassName() // Destructor
Э... Знаешь, есть такой закон Мерфи: "Настоящие программисты не тестируют"? Ловятся если не все, то почти все, и что характерно, все уверены в том, что вот у них-то всё совершенно нормально. В смысле, я не думаю, что ты непременно поймаешься, но уверенность слегка настораживает.
MS>Я однажды добавил к такому коменту в реальном коде "yes, Captain Obvious guaranteed!!!". Задача тестера — найти такие условия, при которых фича глючит — и такое случалось, при чем безо всяких тест-планов. Молодцы студенты-тестеры, они мне очень помогли. А если бы был формальный тест-план, ни фига бы не нашлось. Потому что я сам уже это все проделал и проверил.
Кажется, начинаю понимать... Попробуй сыграть по всем правилам: перечисли в том тест-плане полный список параметров, граничнные значения, ожидающиеся характеристики под нагрузкой (если применимо). Это немного out of scope для тест-плана, но всё-таки. Приведи несколько характерных тест-кейзов для примера и ещё — негативные кейзы, то есть такие, где должны вылететь ошибки. Играть, так играть, чего уж там!
Рыбу тест-плана можешь погуглить, но по сути в нём всё просто: зачем, как, в каких условиях, какие кейзы, что должно быть на выходе, что считается приемлемым результатом тестирования (ну там, краш не чаще, чем раз в 5 минут ).
MS>Еще прикольная история. [...]
Клёвый у тебя директор, Be fair to yourself — ценное качество. За это и натриеэбонатизм с сараем простить можно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, McSeem2, Вы писали:
MS>А если бы был формальный тест-план, ни фига бы не нашлось.
Формальный тест план всего лишь делает явным что и как тестировалось.
Формальность не убивает качество тестирование. Она просто делает его явным.
Альтернатива — народ потратил время, и не в состоянии сказать что они вообще протестировали...
MS>Потому что я сам уже это все проделал и проверил.
Ну тогда тебе надо дать персональный штамп ОТК, как раньше было заводах у некоторых гуру-слесарей
Типа тебе доверяют и дополнительный контроль не нужен
MS>Прикольно на новой работе. Вот я добавил в софту новую мощную фичу,
От фичи зависит. Если требует экспертных знаний, то имеет смысл привлекать разработчиков.
Здравствуйте, bastrakov, Вы писали:
B>Здравствуйте, McSeem2, Вы писали:
MS>>Прикольно на новой работе.
B>детектирую опыт в индустрии не больше пары лет, и возраст до 27. B>припоминаю что-то про музыку... может обратно к гитаре? во
Решил потроллить?
А вообще, забавная ситуация. Мне бы не хотелось, чтобы такие люди как бастраков нанимали меня на работу.
MS>Задача тестера — найти такие условия, при которых фича глючит — и такое случалось, при чем безо всяких тест-планов. Молодцы студенты-тестеры, они мне очень помогли. А если бы был формальный тест-план, ни фига бы не нашлось. Потому что я сам уже это все проделал и проверил.
Задачи тестеров бывают разные. Геннадий вам уже писал про то, что тест-план необходим для регрессионного тестирования, например. Для такого тестирования план очень полезен, так как позволяет не забыть никаких нужных шагов. При внесении изменения можно не протестировать все (не заметить зависимость в коде, забыть про какой-то сценарий работы). Т.е. польза от тест-плана наблюдается не "сейчас", а "потом". А вот свободный поиск — это задача на пользу "сейчас".
Кому писать план — вопрос сложный. Это могут быть аналитики или тестировщики (в этом случае по описанию фичи план составляется), это может быть программист (лучше знает реализацию или вообще не было формальных спецификаций).
Здравствуйте, minorlogic, Вы писали:
M>Нанять пару индусов для такого , а самому полезным заняться
лучше 1-2 выходца из СНГ, личный опыт
1 девушка из СНГ за два года только один дефект с моей точки зрения не был багом (остальные реальные баги)
последнии 3-4 месяца, группа индийских товарищей человек 10-15
я реально задобался закрывать не баги (уже есть заготовка куда только вставляю номер страницы документации где описанно как оно должно работать)
на каком то этапе пришлось закрывать все дефекты, результат
из 37 баг репортов 2 реальные ошибки (я даже не спорил стал фиксить) 35 было закрыто как ошибка тестирования
по факту приходиться перетестировать каждый баг репорт что они генерят, а генерят они просто много так как документацию не читают или у них план каждый дожен загенерить 10 репортов в сутки
Re: When the intern tells me that "the tests are for those who can not program"
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, McSeem2, Вы писали:
MS>>Нафига тогда тестеры нужны?
B>В том числе чтобы тестпланы писать
Вообще-то тестеры пишут тест кейсы ... а вот тест-план должен писать как раз разработчик
Так что я честно проблем тут не вижу, более того похоже что в конторе "правильный" процесс разработки.
).
