Сообщений в теме: 28

[Vestalka]

Хороший тестировщик - это такой, которого программисты хотят убить ))))

[Куатор]

Хороший тестировщик - это такой, которого программисты хотят убить ))))

QA : - АААА у меня тут ничего не работает!!
RnD : - В какой области?
QA : - Сюда жму, и пишет что не может!
RnD : - Вообще не запускается?
QA : - Я только установил
RnD : - Посмотри в системных переменных путь к папке продукта зарегистрирован?
QA : - Где посмотреть?!
Есть подозрение, что вот тут RnD будет готов убить куа.. я не уверен, что прям здесь , но через пару дней точно )

[ch_ip]

Хороший тестировщик - это такой, которого программисты хотят убить ))))

А по мне так хороший - это такой, к которому программисты приходят и просят: "Я тут новый билд выпустил, посмтри его, пожалуйста"

[Артем Б.]

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

[LeshaL]

Товарищ LeshaL когда-то задвинул такую мысль: плохой тестировщик - это тот, работе которого нельзя доверять.

Да чего-то такое говорил, подтверждаю :) Только вот обратного из этого не следует.

И да, мысль я ВЫдвинул, а не ЗАдвинул.

[Артем Б.]

Да чего-то такое говорил, подтверждаю :) Только вот обратного из этого не следует.

Я об обратном и не говорил :)

И да, мысль я ВЫдвинул, а не ЗАдвинул.

fxd

[Vestalka]

Хороший тестировщик - это такой, которого программисты хотят убить ))))

А по мне так хороший - это такой, к которому программисты приходят и просят: "Я тут новый билд выпустил, посмтри его, пожалуйста"

Жаль, у меня нет таблички "Сарказм" )))) Зато в конце куча смайлов )))
Конечно, хороший тестировщик - это к которому приходят и мнению которого доверяют, к которому прислушиваются.
Т.е. если тестировщик вносит предложение, то от него не отмахиваются, а обсуждают и принимают решение (ну, тут еще, конечно, все зависит от адекватности предложенного). Если он говорит: "Этот функционал проверен!", то все верят и не лезут проверять повторно, потому что там действительно все нормально (плохой пример: находишь после чьего-то тестирования достаточно серьезную багу, а тебе говорят: "Я про нее знаю!". Хотя она незадокументирована и никем не фиксится).
Как-то так )))

[LeshaL]

Да чего-то такое говорил, подтверждаю :) Только вот обратного из этого не следует.

Я об обратном и не говорил :)

Да я понимаю, это я к теме всего топика высказался. По идее, кто-нибудь может подумать, что верно "хороший = not(плохой)" - как true = not(false).

ОФФТОП: Подобную тему поднимал на тренинге Майкл Болтон. Дословно не помню, сейчас нет под рукой материалов, но суть такая - есть утверждение: "на карточке, если с одной стороны написана гласная буква, то с другой обязана быть нечетная цифра". Из этого делают неправильные выводы, что "если с одной стороны написана нечетная цифра, то с другой должна быть гласная буква" или "если с одной стороны согласная буква, то с другой должна быть четная цифра".

[owasp]

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

Вот пока, всё просто. В дальнейшем какие-то требования добавят, надеюсь, хорошие требования. Вот требование - находить не менее 5-ти дефектов в день - пример плохого требования. При таком подходе сотрудник становится машиной для производства дефектов. Можно даже "саботировать" этот процесс, оформляя например не дефект, а развернутую статью, в которая тянет на 5 очень важных дефектов.

Если на предприятии фиксированная ставка у тестировщиков или фиксированный оклад, то надо будет придумать критерии хороший/плохой. Если же ставка индивидуальная, то нужен индивидуальный подход - все асы, и поэтому хорошие.