Лишние знания мешают?
понедельник, сентября 14, 2009
В своем посте "What Makes A Good Software Tester?" Dr. James McCaffrey описывает восемь характеристик настоящего тестировщика. Одной из таких характеристик является: существенные технические данные. Причем, здесь он имеет ввиду, кроме всего прочего, умения/знания программирования:
A great software tester must have significant coding skills in order to understand the system under test, communicate with developers, and write test automation. ... I believe that a great tester must have at least 7.5-on-a-scale-of-1–10 (applications) development skills.
То, что автоматизатору было бы не плохо быть раньше программистом или иметь хоть какой—то опыт написания программ — это точно.
А вот, что касается, всего остального — то тут я не соглашусь с знаменитым доктором...Не раз и не два видел, когда именно апеляция к технической реализации той или иной функциональности системы приводила к выпуску софта с ошибками. В случае же, когда тестировщик не знает/не углубляется(если знает) в технический аспект решения проблемы, тогда аргументы программиста о нюансах реализации не принимаются во внимание — начинает работать логика, понимание use cases, usability — программистам становится интересно реализовать функциональность правильно. И все в шоколаде.... по крайней мере, так хотелось бы.Что я хотел сказать: далеко не всегда глубокие знания программирования будут помогать тестировщику. Но знать основы ООП или в каком случае равенство имеет смысл а = а + 1 — надо обязательно.
Из-под пера Maksim Grinevich
Тэги:
автоматизация,
мысли,
неоднозначное,
опыт,
тестирование,
Dr. James McCaffrey
Тэги:
автоматизация,
мысли,
неоднозначное,
опыт,
тестирование,
Dr. James McCaffrey
МакКэфри по средствам цифр говорит о том, что он верит в то, что тестировщик должен знать сильно больше среднего разработчика и хотя бы понимать то, что говорят самые опытные.
Случаи о которых вы говорите, больше показывают оплошность (лень) тестировщика - решение о качестве, только по технической реализации. Больше особо ничего и не сказать, потому что не понятен характер багов найденых после - то ли ошибка в "решении", то ли реализация повлекла ошибки вокруг.
Alex, зачастую это выглядит след. образом:
Девелопер: Мы тут реализовали вот так и все раюотает.
Тестер: тут вот такая-вот траббла..
Д: Ну ты же пойми, использую вот такую технологию у нас тут все получается, вот только вот эту закорючку в требованиях мы с этой технологией реализовать не можем - ну ты же знаешь эту СУПЕР_ПУПЕР_НОВУЮ_КРУТУЮ технилогию
Т: да знаю.. мне она тоже нравится. Да.. она не сможет это закорючку реализовать - ну её..
Второй вариант:
Девелопер: Мы тут реализовали вот так и все раюотает.
Тестер: тут вот такая-вот траббла..
Д: Ну ты же пойми, использую вот такую технологию у нас тут все получается, вот только вот эту закорючку в требованиях мы с этой технологией реализовать не можем - ну ты же знаешь эту СУПЕР_ПУПЕР_НОВУЮ_КРУТУЮ технилогию
Т: не не знаю... я знаю, что это важно и должно быть пофикшено.. может техническую сторону стоит поменять?
....
Когда новую функцию нельзя реализовать или исправить баг из-за используемой технологии, по словам разработчика, тогда появляются другие факторы, которые влияют на то махнуть на это рукой или нет (что нужно заказчику, как воздействует отсутствие исправления на проект) и при возникновении разногласий решаются, чаще всего, на уровне менеджмента.
Примеры, которые вы привели вполне понятны и я тоже с таким сталкивался. Но вредность знаний они всё-равно не показывают (возможно только мне). Тут я вижу хорошую иллюстрацию умения донести до разработчика ошибку. В первом случае, неумение заинтересовать разработчика, например - «Нельзя исправить эту ошибку? Но ведь тогда всё, что ты сделал не будет работать.» - и тогда, возможности технологии уже не будут играть такую большую роль. Во втором случае, указание на то, что сделано изначально неправильно («сменить технологию»), но без предложения лучшего пути, плюс возвышение над разработчиком («спрашивается зачем пошел в тестирование, если так хорошо знаешь, как нужно тут всё сделать»).
Конечно, Кесарю — кесарево: разработчикам придумывать реализации, а тестировщикам искать ошибки, неточности и противоречия, но тестировщику хорошо понимать разработку, а программисту тестирование, никогда не повредит.
"...тестировщику хорошо понимать разработку, а программисту тестирование, никогда не повредит."
Вот это точно! У меня в загашнике есть даже лекция "Тестирование для программистов"...
Но весь вопрос о глубине этих знаний. Собственно мы с вами об одном и том же говорим, только немного разными словами...
to Maksim Grinevich
Пример показательный конечно, но не всегда.
Рассмотрим продолжение второго варианта, программисты говорят, хорошо... и печально костылят новую технологию, и через месяц работы программы оказываеться, что костыль может сильно убивать производительность, он костылиться ещё одним костылём и так далее, пока в конце концов таких костылей не окажется столько, что придёться либо отказаться от проекта, либо заново его переписывать, но в первом случае, возможен вариатн:
Тестер: о да ребята, я вас понимаю, давайте обсудим с заказчиком. И потом принимаеться один из двух вариантов, отказаться от новой супер технологии, либо немного изменить требования к функции, может на самом деле не такие уж они критичные :)
Нам например приходиться сталкиваться с тестерами из "страны восходящего солнца", вот у них да, есть противная особенность в описании бага, давать свои мего ценные замечания по поводу того почему он возник (имеется ввиду не просто шаги воспроизведения, но чуть ли не конкретные функции), и как его пофиксать, и ассайнить не на менеджера, а сразу на девелопера, который по их мнению может это пофиксать. И это напрягает, потому что слишком уж часто они ошибаются :)
to Pavel Drobushevich:
Развитий событий может быть несколько - это безусловно. Даже бывают (я точно знаю есть) тестировщики, которые занимаются ревью кода - они -то глубоко знают техническую сторону процесса.
Но, чтобы быть толковым тестировщиком умение "кодить" - необязательно...
В нашей жизни много разных "сценариев", одни удачны, друшие нет - но в большинстве (в общем случае) пусть тестировщик лучше знает своё, чем чужое более глубоко...
При тестировании приходилось сталкиваться с ошибками, которые без знания языка реализации и его особенностей не возможно обнаружить.
"Но, чтобы быть толковым тестировщиком умение "кодить" - необязательно..."
Но желательно.
Тут, Сергей, я с вами полностью согласен...
Ведь как хорошо, когда каждый тестер умеет программировать, владеет глубокими аналитическими умениями/знаниями, способен взять управление проектом на себя, может свободно из простых пожеланий заказчика сгенерировать формализованные требования и т.д.
Но всё это - лишь nice to have - а мы ведь живем в реальной жизни..;)