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

[Tester]

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

[barancev]

Мощно задвинул! Уважаю.

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

[Case]

(imho) Не должны.

Дэбаг дело девелоперов. У них и инструменты для этого есть (таже среда разработки).

[Case]

Но я бы на этом не останавливался.

У нас сие называется "пройти чуть-чуть дальше после определения что это ошибка и ..." Дальше полёт фантазии не останавливается ничем. А так как наши системы тесно друг с другом интегрированы, то иногда поиск причины сбоя уходит не то что за рамки тестируемого приложения, а за рамки платформы на которой оно крутится :)

Неправильно это.

[Doveangel]

А у нас на предприятии так и работают))
Кроме меня - я рьяно сопротивляюсь - говорю что это не моя обязанность. Я так уверенно это говорю - что никто не спорит.

1. Принцип у меня такой - я нашла, а ты исправь - у каждого своя работа
2. Нигде не читала что тестировщик причины ошибок искать должен
3. Так и запутать разработчика мона - будет мысленно возвращаться именно к мнению тестировщика
4. Программа - дите разработчика - и разработчик знает свое дите лучше чем кто ни было

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

[PavelB]

Если ошибка локализована и известно, как её исправить -- зачем привлекать программистов, пусть тестировщики сами и исправляют, это уже несложно после всего сделанного.

А затем можно спокойно переименовать тестировщиков в программистов и набирать новых тестировщиков.

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

[Vasiliy]

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

[Tester]

Спасибо всем за ответы :rolleyes:
Мой топ-менеджер своего мнения не изменил и сказал, что хочет найти такого умного тестера. Ну хотеть - оно никогда не вредно. Я ему пожелала успехов :D

[Dmitry_NJ]

Мой топ-менеджер своего мнения не изменил и сказал, что хочет найти такого умного тестера.

Я бы вам пожелал найти более умного топ-менеджера :) Но, видимо, уже в другой компании...

[dlg99]

налицо "serious attitude problems". :angry:

А менеджер молодец. Усли ему удастся создать команду способную на "white-box testing", code review and internal software architechture review, то это должно сильно улучшить качество продукта. Если, конечно, продукт достаточно сложный.
Для простых расходы слишком велики, пожалуй.

Это примерно то, чем SDET (software design engineer in test / software developer engineer in test) в microsoft занимаются.

Вот только предлагать подобные вещи человеку, который: junior engineer (not by official title, but by mindset), most likely technically incapable, and seems to be having attitude problems я бы не стал. Да и он, наверно, просто мечтал вслух.

Понимаете, если QA (SDET) в состоянии локализовать проблему до уровня "дизайн компонента .... плох" и т.п. это не значит, что он(а) же это будет исправлять.
Если баг-фикс это серьезные изменения одной компоненты и рефакторинг еще пяти, то этим займутся девелоперы.

[Dmitry_NJ]

Это не у Tester'a проблемы с attitude. Это у менеджера проблемы. Причем серьезные, если он/она не понимают разницы между black-box и white-box testing. И не понимает, что для white-box testing требуется совершенно иной набор skills, который, кстати, говоря, стоит совсем других денег (с этим у менеджеров самые серьезные проблемы). Вместо того, чтобы навешивать на человека дополнительные обязанности и пытаться за те же деньги заставить его заниматься еще и white-box testing, лучше бы занялся поиском спеца, если он действительно так нужен. Ну или хотя бы как-то материально заинтересовал уже работающего сотрудника на овладение white-box testing.

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

Для того, чтобы копаться в чужом коде, надо во-первых, обладать знаниями сравнимыми со знаниями самих разработчиков, а во-вторых, иметь очень сильное желание этим заниматься. Большинству почему-то нравится писать свой собственный код и называться программистом, а не ковыряться в чужом и называться тестировщиком. Microsoft может позволить себе держать классных спецов SDET. Думаю, что разница в зарплате между тестировщиками и разработчиками в Microsoft не такая значительная, как между тестировщиками и разработчиками в России. Ну и потом работать SDET в Microsoft это одно, а работать тестировщиком, имея квалификацию, сходную с квалификацией программиста, в ООО "Рога и Копыта" это совсем другое.

[Victorea]

Я так думаю, что этот менеджер набрался новой методологии и теперь хочет, чтобы в его комманде работали только самые "продвинутые" тестеровщики. В чем-то он прав. С одной стороны, тестировщик действительно может (и часто должен) находить причину и место ошибки в коде. Некоторые компании действительно требуют изначального владения такими навыками. С другой стороны, где такие тестировщики? Их еще не воспитали ;)

[Tester]

Еще раз спасибо за ответы. :)
Моя специализация действительно никогда не включала white testing и все, что к этому может относится. Поэтому для себя я вижу такие варианты:
1) расширить свои профессиональные возможности
2) если начальство найдет специалистов по white box testing - взаимодействовать с ними
3) в крайнем случае вегда можно сменить работу

[Dmitry_NJ]

С одной стороны, тестировщик действительно может (и часто должен) находить причину и место ошибки в коде.

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

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

[dlg99]

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

root cause analysis - нормалное явление.
Везде, где я работал.

Вполне достаточно понимать, из каких "кирпичиков" построена система, как они взаимодействуют.
Все, что нужно - анализировать логи (иногда) и думать, что ты делаешь.
Все просто, код не нужен. ;)
логи нужны ;)

это к "находить причину".

да, junior qa этим не должен заниматься. если, конечно, он не мечтаeт стать 'senior' someday :rolleyes:
ну и test automation coder, который просто пишет тесты по заказу остальной команды - тоже.

[barancev]

Честно говоря, я ожидал, что народ возмутится, я даже намеренно волну чуть повыше приподнял :)
Но народ почему-то смиренно воспринял свою нелёгкую участь.

Попробую немного возразить себе и защитить тестировщиков с другой стороны.

Мнение разработчика.

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

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

2. Разработчик, поняв причину ошибки, найдёт более качественное решение проблемы, потому что знает, как систему предполагалось реализовать. Тестировщик, исправив ошибку, может ненамеренно разрушить что-то другое просто по незнанию.

3. Разработчик, исправив ошибку, внесёт также исправления в другие похожие места, где может возникнуть аналогичная проблема. Тестировщик про другие места ничего не знает.

4. Разработчик, однажды исправив, впредь не будет делать такую ошибку. А если тестировщик за него подчистит, разработчик повторит свою ошибку ещё и ещё.

5. Кто будет отвественен за правильность исправления? Кто будет контролировать тестировщика, исправившего ошибку? Он сам? Разработчик умывает руки.

Короче, от имени разработчиков -- дорогие тестировщики, вам что, своей работы мало? делайте то, что хорошо умеете, и будет вам за это великая слава!