Путь тестировщика

Я программист, а хочу стать тестировщиком. Меня предупредили, что во-первых поначалу будет сильно колбасить, потому что программист - созидатель, а тестер - разрушитель. И значит надо менять психологию. Во-вторых в программирование будет вернуться трудно (почти невозможно), потому что будешь видеть все свои дыры. Тогда меня заинтересовал вопрос:
откуда берутся и куда деваются тестеры? То есть какова траектория (карьера) тестировщика. Тестирует ли он до самой смерти или как футболист в 35 лет сходит с дистанции?
Сем Канер пишет, что люди приходят в тестирование из разных мест, потом некоторые уходят, но многие возвращаются.
Может быть тестирование - это ловушка? (наркотик?)

Игорь Перец

Тестер -- не разрушитель, это Вас дезинформировали :)

Чтобы не колбасило, делайте тесты так, как будто это Ваша очередная разрабатываемая система. Знаете, бывают такие инструменты -- "заменители секретарши", которые автоматизируют выполнение рутинных действий. Вот создание автоматизированных тестов (заметьте -- создание!) сродни такой работе. Ну а exproratory testing -- всё равно все программисты это делают, особенно когда отлаживаются, только делают непрофессионально :)

В программирование вернуться нетрудно, и с видением дыр проблем не будет -- просто меньше станете делать ошибок, это даже к лучшему. Но очень может быть, что возвращаться просто не захочется. Дело не в наркотичности, а в том, что у тестировщиков обычно работа более разнообразная и круг интересов шире, чем у программистов.

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

Ну, управление мне не грозит, я этого не люблю (не получаю удовольствия), а вот консалтинг с обучением - сгодится. Но сначала надо в тестировании собаку съесть. Мне видимо попался специфический тестировщик, который считает, что главное - устойчивость программы, поэтому первым делом пытается ее завалить. Отсюда и идея разрушителя.
А вот еще вопрос: читают ли программисты литературу по тестированию?
Ведь они могут приспособиться и писать программы, которые хорошо проходят тесты, а не те, которые нужны заказчику. Может быть программерам запретить читать такую литературу? :angry:

Игорь

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

Видимо специфический :)

Я вчера засабмитил статью, посвящённую анализу различных моделей качества ПО и месту тестирования в этих моделях, думаю, что скоро она будет опубликована в библиотеке -- почитайте, посмотрите, как много ещё кроме устойчивости аспектов, которые необходимо учитывать для достижения высокого качества.

А вот еще вопрос: читают ли программисты литературу по тестированию?
Ведь они могут приспособиться и писать программы, которые хорошо проходят тесты, а не те, которые нужны заказчику. Может быть программерам запретить читать такую литературу?  :angry:

Так ведь тестировщики тоже не лыком шиты, сделают тесты "не по книжке" :)

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

А разработчики пусть читают такие книжки, они от этого лучше начинают понимать цели и задачи тестирования, улучшается взаимодейстие в команде. Кроме того, от этого у них повышается профессионализм как программистов, потому что чтение такой литературы помогает избавиться от типовых ошибок.

читают ли программисты литературу по тестированию?

Конечно, не все, но есть такие, кто читает. Знакомая читала, говорит, что оказалось очень и очень полезным.

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

Перец

Так! B)

И не бойтесь, что растеряете навыки разработчика, напротив, только углубите их, а также приобретёте новые.

Спасибо за пожелания. А вот еще вопрос:
какие слабости есть у тестировщиков?
Я пока вижу две:
1. в случае застоев (кризисов) тестировщиков увольняют первыми
2. тестировщик не может исправить найденную ошибку, он только на нее указывает, а программист (или начальник) решает, стоит она исправления или нет. Это бессилие угнетает. Действовать можно только методом убеждения...

Игорь

Спасибо за пожелания. А вот еще вопрос:
какие слабости есть у тестировщиков?
2. тестировщик не может исправить найденную ошибку, он только на нее указывает, а программист (или начальник) решает, стоит она исправления или нет. Это бессилие угнетает. Действовать можно только методом убеждения...

В следствии этого могу порекомендовать один фундаментальный труд:
http://www.livejourn...eau/234778.html

Прошу не воспринимать всерьез.... :rolleyes:

Спасибо за пожелания. А вот еще вопрос:
какие слабости есть у тестировщиков?
Я пока вижу две:
1. в случае застоев (кризисов) тестировщиков увольняют первыми
2. тестировщик не может исправить найденную ошибку, он только на нее указывает, а программист (или начальник) решает, стоит она исправления или нет. Это бессилие угнетает. Действовать можно только методом убеждения...

Это не слабости :)

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

1. в случае застоев (кризисов) тестировщиков увольняют первыми

Мне как-то это спорным кажется. Вот, к примеру, в отделе 5 разработчиков и один тестировщик - кого первым уволят в случае сокращения штата?

2. Тестировщик может исправить баг, если хочет. А может не исправлять, если ему в лом. А разработчик -- обязан :)

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

Игорь

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

Тут все зависит от того, какое приложение тестировать. Если например клиент-сервер с БД, то ошибки типа "неправильное формирование запросов в приложении" и т.п. вполне можно исправить. Ну и если тестировщик знает язык, на котором написано приложение, то он вполне способен оценить природу ошибки и исправить ее, хотя это уже не его работа.

насчет пяти программистов и одного тестировщика, это отдельный
вопрос, который я никак не могу разрешить. Теория моя такова (я высосал ее из пальца):
чем больше проект, тем больше доля тестировщиков. В маленьком проекте тестировщики не нужны. В среднем проекте нужны 1-2 тестировщика. В большом проекте тестеров почти столько же, сколько и программистов. И наконец в очень большом пректе тестеров больше всех.
Канер приводит такие цифры: Windows NT (v4) содержит 6 млн. строк кода, а тестировщики написали 12 млн. строк. Значит тестировщиков было больше, чем программистов! Потому эта версия такая надежная.
Вообще Windows глючит не потому, что в Майкрософт плохие программисты, а потому что там плохие тестировщики.
Вопрос в том, много ли в мире больших проектов и растет ли их число, или наоборот, проекты мельчают (если исключить самых крутых игроков вроде Майкрософт). То есть растет ли спрос на тестеров?

Мне как-то это спорным кажется. Вот, к примеру, в отделе 5 разработчиков и один тестировщик - кого первым уволят в случае сокращения штата?

тестировщика.
девелоперы начнут судорожно делать вид что что-то тестируют.
после пары плохого качества релизов проект закроют, или компанию кто-то купит и разгонит всех нафиг. или компания обанкротится.
или одумается :)

В России возиожна своя специфика - например, шеф сбегает с деньгами на Кипр, разработчиков сажают за неуплату налогов, тестер счастливо работает в другой компании :rolleyes:

Вообще Windows глючит не потому, что в Майкрософт плохие программисты, а потому что там плохие тестировщики.

Сразу видна точка зрения программиста :D

На форуме, насколько мне известно, нет тестировщиков из Microsoft, но полагаю, что они с вами не согласятся.

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

А что Вы называете средним или большим проектом? Можно узнать количественные оценки?

То есть растет ли спрос на тестеров?

Имхо, да растет.

Канер приводит такие цифры: Windows NT (v4) содержит 6 млн. строк кода, а тестировщики написали 12 млн. строк. Значит тестировщиков было больше, чем программистов!

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

Вообще Windows глючит не потому, что в Майкрософт плохие программисты, а потому что там плохие тестировщики.

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

А что Вы называете средним или большим проектом? Можно узнать количественные оценки?

Мои оценки следующие:
Если в проекте осталось 50 нераскрытых ошибок, то он может работать, и тестеры не нужны.
При стандарте 10 ошибок на 1000 строк кода, это проект в 5 тыс. строк.
Если в проекте 500 ошибок, то его уже надо тестить профессионально, то есть проект в 50тыс. строк
назовем средним.
Дальше не знаю, я с большими и очень большими проектами не работал и не представляю, сколько например строк кода в Visual Studio.
Но видимо от 100тыс. строк это уже большие проекты. Все, конечно, и от языка зависит :)

Если в проекте осталось 50 нераскрытых ошибок, то он может работать, и тестеры не нужны.

Прошу прощения, а как вы узнаёте сколько ошибок осталось в проекте?

Ну и ещё немного мне непонятно, если в проекте 1,000 строк кода, найдено 500 ошибок (цифры потолочные), но при этом не работает 2 из 25 заявленных в требованиях функций? Тогда как? Не нужны тестировщики?