А можно ли ответить на вопрос "Хороший ли я тестировщик"?

Собственно, сабж. Мысль возникла не потому, что я чем-то не доволен, что у меня какие-то проблемы. Совсем наоборот: я хочу работать над собой, становится лучше. Но для этого надо ответить на несколько простых вопросов:
-Что я умею делать?
-Как хорошо я это делаю?

В QA совсем недолго, потому могу только предполагать, что есть какой-то аналог brain-bench, который может быстро указать на сильные и слабые стороны специалиста. Собственно, нужна подсказка: куда копать

P.S. за спиной 6 лет работы с 1С, разработка на С++. Но тема не об этом...

Сообщение отредактировал EugeneL: 17 марта 2012 - 14:10

Но для этого надо ответить на несколько простых вопросов:
-Что я умею делать?
-Как хорошо я это делаю?

Мы за вас на эти вопросы не ответим.
Так какие у вас варианты?

Что вы умеете делать?
Тестирование методом черного ящика? Белого ящика? Исследовательское? Нагрузочное? Автоматизация? Тест-дизайн?

Интересно, а можно ли считать одним из качеств хорошего тестировщика - большое количество купленных багов (серьёзность багов major) на fixber.com?
Или победа в конкуpсах на utest.com?

Что вы умеете делать?
Тестирование методом черного ящика? Белого ящика? Исследовательское? Нагрузочное? Автоматизация? Тест-дизайн?

1. Тестирование методом черного ящика -- ежедневно.
2. Тестирование методом белого ящика -- 1с-конфигурации - запросто :) Все остальное -- скорее нет, чем да. Иначе я бы позиционировал себя, как разработчик...
3. Исследовательскте тестирование -- всегда интересно, а что же будет, если я сейчас ткну не туда, куда написано в инструкции... Oops :)
4. Нагрузочное. Гм. Я отрастил себе еще 500 пар рук и могу свободно подменить работу 1000 пользователей с БД или сайтом. Я серьезно )
5. Автоматизированное. White + NUnit, Selenium + JUnit, немного поковырял QTP, сейчас Flex Monkey + Flex Builder*. Частый гость на rsdn.ru, sql.ru... ник не этот
6. Тест-дизайн.... я джуниор, а кто это доверит джуниору? Но думаю, я бы смог. Отталкивался бы от заказанного функционала. В прицнипе, обновляю тест-кейсы на проекте (пишу, какая именно ошибка и по какой причине ожидается -- может, кто-то сделает кейс быстрее, если у него будет такая информация, которой не было у меня)

Вот, я ответил. Кажется, я the Man who Cans Make Everything, но это далеко не так, скорее всего.

Думаю, что если исходный вопрос переместить в область HR, то на него станет проще ответить:
"Что должен уметь QA-специалист, которого Вы возьмете на работу? Как Вы это проверите при ограниченном времени собеседования?"**

* - изюминк в том, что все вызовы асинхронны и невозможно посмотреть состояние системы во время исполнения....
** - вопрос, естественно, не буквальный. Я никуда не собираюсь уходить, но ведь прием на работу и, что намного важнее, ПОСЛЕДУЮЩЕЕ ПРОДВИЖЕНИЕ как раз основываются на том, что кандилат умеет делать и как. И что за это хочет (но это -- не тема этого топика)

Может это будет интересно.

С этой программы:

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

Интересно, а можно ли считать одним из качеств хорошего тестировщика - большое количество купленных багов (серьёзность багов major) на fixber.com?
Или победа в конкуpсах на utest.com?

Я думаю что НЕТ.

Потому что количество багов не показатель. Я знаю ребят, которые находят кучу багов, всегда больше всех, всегда в лидерах на проекте. Но пропускают самые серьёзные для пользователя недочёты.

При этом любой РМ и ТМ скажут, что лучше найти 10 багов, критичных для пользователя, чем 20 средней критичности. Так что увы и ах, количество не показатель!


Автору: расскажите, что вы умеете, как вы это делаете, чему и как учитесь. Тогда станет понятнее, что вам ответить. Я давно составляю матрицу навыков тестировщика с тестом, и так же давно откладываю эту задачу :) Когда-нибудь исправлюсь ;)

При этом любой РМ и ТМ скажут, что лучше найти 10 багов, критичных для пользователя, чем 20 средней критичности. Так что увы и ах, количество не показатель!

То есть, если тестировщик нашел 10 критичных багов, но пропустил 20 менее критичных, то он все равно хорошо сделал свою работу?

Автору: расскажите, что вы умеете, как вы это делаете, чему и как учитесь. Тогда станет понятнее, что вам ответить. Я давно составляю матрицу навыков тестировщика с тестом, и так же давно откладываю эту задачу :) Когда-нибудь исправлюсь ;)

1. Тестирование методом черного ящика. Smoke, critical path, regresion. Если выявлен недостаток, смотрю воспроизводимость, пытаюсь свести к минимальной длине последовательность действий для воспроизведения его.
2. Тестирование методом белого ящика. Знаний у меня маловато, чтобы тестировать исходный ход лучше IDE разработчика.
3. Исследовательскте тестирование. Если есть время -- всегда стараюсь проверить моменты, которые могут (по моему мнению) привести компоненты системы в нестабильное состояние. Стараюсь "выйти из пределов классов уже определенных ошибок", т.к. в рамках одного класса поведение, скорее всего, будет одинаковым. Надо очень хорошо знать продукт, который тестируешь, чтобы лучше представлять его внутреннюю структуру.
4. Нагрузочное. Пока не приходилось, но думаю смогу: могу подключиться к БД из ЯВУ, знаю SQL.
5. Автоматизированное. White + NUnit, Selenium + JUnit, немного поковырял QTP, сейчас Flex Monkey + Flex Builder. Частый гость на rsdn.ru, sql.ru... ник не этот
6. Тест-дизайн.... при разработке новых тестов я буду отталкиваться от функциональных возможностей ПО, т.е. кейсы будут в первую очередь на то, ради чего система и создается. На момем проекте меняется UI, планирую заменить кейсы на обновленные и уточнить некоторые моменты (не нравится, что есть кейсы из 40 шагов)

Про обучение: мне немного непонятно, где я нахожусь сейчас. А это очень надо для того, чтобы определять, в каком направлении двигаться

Как вариант, можно ответить на вопрос - "какие проблемы с тестированием есть на моем проекте, и что мне мешает решить их?". Почему-то кажется, что ответить на этот вопрос проще, нежели копаться в себе. Да и обучаться, решая конкретную проблему проще, чем учится "на будущее".

EugeneL, возможно, окажется полезным Компетенции тестировщика - я на этот текст ориентируюсь, если без конкретики "уметь работать там-то и в том-то".

хм. Чисто из своего опыта.
Знание цикла разработки ПО и место QA в этом цикле.

Судя по умениям - у Вас очень достойный набор знаний!