Сам не пойму что со мной

← →
Плохиш © (2006-01-07 01:31) [40]

1. Хороший тестер должен уметь сломать любой софт.
2. Плохой тестер - это тестер, который знает, как программа должна работать.
3. Если тестер делает все действия с программой правильно по инструкции/техзаданию, то такого тестера надо срочно выгонять.
4. Если во время тестирования в фирме обвиняют тестера в действиях приводящих к неработе программы, то такая контора не может называться НОРМАЛЬНОЙ!
5. Пусть тестер найдёт ошибки, чем их найдут пользователи, ошибки от тестера гораздо легче исправить ;-)

← →
QwertyKz © (2006-01-07 02:05) [41]

> 4. Если во время тестирования в фирме обвиняют тестера в
> действиях приводящих к неработе программы, то такая контора
> не может называться НОРМАЛЬНОЙ!

lol это же его работа (тестера) приводить программу к неработе :)

← →
Плохиш © (2006-01-07 02:19) [42]

> Yerlan Dossanov © (06.01.06 23:30) [15]
> > Kerk © (06.01.06 23:21) [8]
> А как ты предлагаешь тестить, если в исходниках нужно задавать
> параметры.
> Т.е. по-любому придется туда лезть.
> Я же говорю, мне приходит не готовый софт, а скрипт, файл
> *.sql.

> Yerlan Dossanov © (06.01.06 23:35) [16]
> Многие параметры, которые в готовом софте юзер будет выбирать
> в менюшках и чекбоксах, на данном этапе ручками вписываются
> в процедуру.
> Когда скрипт не отрабатывает, я бегу со страшными глазами
> к разработчику, и выясняется, что нужно было учесть еще
> энное количество факторов, которые ясно указаны в исходнике.

Судя по этому ты работаешь не тестировщиком, а каким-то левым отладчиком, результат работы которого нужен для того, чтобы было кого потом объявить козлом-отпущения. Ты не можешь выдавать положительный результат о работе какого-то скрипта, потому что ты не можешь гарантировать, что в окончательном проекте все нужные параметры будут заданы в правильном виде с помощью "в менюшках и чекбоксах".

← →
Sergey Masloff (2006-01-07 10:55) [43]

Плохиш © (07.01.06 02:19) [42]
>потому что ты не можешь гарантировать, что в окончательном проекте
пАчИму такой злой, да? ;-)
Менюшки может еще через полгода будут. А скрипт уже сейчас есть. И вполне можно его тестировать. И, при определенных условиях, с высокой вероятностью гарантировать его безглючность.
А при выявлении глюков потом сразу искать глюки в задании параметров через менюшки а не или в менюшках или скриптах.

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

← →
Yerlan Dossanov © (2006-01-07 11:22) [44]

[40] Плохиш © (07.01.06 01:31)
1.Согласен.
2.Категорически нет.
3.В принципе да, но не всегда.
4.Согласен.
5.Согласен.

← →
Lamer@fools.ua © (2006-01-07 12:00) [45]

>>Плохиш © (07.01.06 01:31) [40]

IMHO, лучше вот так:
2. Плохой тестер - это тестер, который знает, только как программа должна работать.
3. Если тестер делает все действия с программой только правильно по инструкции/техзаданию, то такого тестера надо срочно выгонять.

IMHO, лучше вот так:
2. Плохой тестер - это тестер, который знает, только как программа должна работать.
По-моему, тестер должен лишь абсолютно точно знать, как программа должна работать, т.е. что от нее требуется.Тогда он сразу заметит любое отклонение(читай - ошибку).
А знать, как софт не должен работать, ИМХО, нереально - вариантов его некорректной работы масса.

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

[47] Desdechado © (08.01.06 17:50)

1. поставить себя на место рядового пользователя (т.е. прикинуться полным идиотом, не читавшим инструкции и не понимающим, что программа вообще делает) - это позволяет найти способы использования программы, которые разработчик (в силу узости его понимания) не мог предусмотреть, и баги, с этим связанные
С нашим софтом прикидываться полным идиотом не получится - он достаточно специализирован, и его пользователи - далеко не чайники.

2. поставить себя на место разработчика, чтобы выдать рекомендации, как лучше обойти или закрыть ситуации из п.1
А вот с этим как раз проблемы, в силу недостаточности знаний

Сам не пойму что со мной Найти похожие ветки