В теме 19 ответов, и 9 участников, последнее обновление сделано пользователем 
Надежда Тарасюк 12 г, 9 мес. назад.
-
Сообщения
-
Всем привет!
У нас в компании довольно часто тестировщики выполняют роль аналитика на проекте. Вот я недавно задумалась, плохо это или хорошо
Было бы здорово услышать мнение участников сообщества по этому поводу. Ответьте, пожалуйста, на вопросы:1) Вы когда-нибудь занимались тестированием ПО (вопрос к аналитикам)?
Если да, то как вам? Понравилось , не понравилось? Чем именно?
Если да, то желательно уточнить уровень вовлечённости в тестирование:
а) минимальные проверки софта перед демонстрацией заказчику;
б) учавствовали в тестировании ПО на проекте (был выделенный участок работы или полностью отвечали за тестирование продукта) и одновременно выполняли задачи BA;
в) тестировщик в прошлом.
г) свой вариант2) Как вы думаете, роли «тестировщик» и «бизнес-аналитик» совместимы?
а) Если да, то что в этом сочетании хорошего?
б) Если нет, то что в этом сочетании плохого?Всем привет!
У нас в компании довольно часто тестировщики выполняют роль аналитика на проекте. Вот я недавно задумалась, плохо это или хорошо
Было бы здорово услышать мнение участников сообщества по этому поводу. Ответьте, пожалуйста, на вопросы:[b]1) Вы когда-нибудь занимались тестированием ПО (вопрос к аналитикам)? [/b]
Если да, то как вам? Понравилось , не понравилось? Чем именно?
Если да, то желательно уточнить уровень вовлечённости в тестирование:
а) минимальные проверки софта перед демонстрацией заказчику;
б) учавствовали в тестировании ПО на проекте (был выделенный участок работы или полностью отвечали за тестирование продукта) и одновременно выполняли задачи BA;
в) тестировщик в прошлом.
г) свой вариант[b]2) Как вы думаете, роли «тестировщик» и «бизнес-аналитик» совместимы?[/b]
а) Если да, то что в этом сочетании хорошего?
б) Если нет, то что в этом сочетании плохого?1а+г(был БА/ПМ на проекте, где вначале не было QA, а потом стало 4 или 5.. и, соответственно, вначале носил несколько шляп)
2а хорошо, когда реализацию проверит тот же человек, который разрабатывал требования.. да и проверять проще, не надо у БА спрашивать "глупые" вопросы по спеке.. плюс QA (НЕ тестер) приступает к проекту почти так же рано, как и BA
2б у этих двух ролей всё-таки немного разные цели и способы их достиженияТо, что QA может частично (или полностью) выполять функции аналитика на проекте, по-моему, не хорошо, и не плохо. Это нормально. Это данность и явление, с которым встречаются многие компании. Более того, существует отдельное направление в QA — QA аналитик. Это просто подобласть области анализа. Часто весьма удобно иметь узких специалистов, но профессиональных.
Может быть, это вас удивит, но отличие QA от тестировщика в том числе и заключается в его способности делать анализ. И не только в способности, конечно. Просто QA на проекте, в отличае от тестировщика, работает от стадии создания документации по проекту и до стадии приемки проекта заказчиком. И именно задачей QA является определить критерии качества конечного продукта, что и является, собственно, ТРЕБОВАНИЯМИ. Я предполагаю, что с работой QA мало кто сталкивался по-настоящему, поскольку в нашей стране считанные единицы компаний используют таких специалистов. Все остальные, в том числе и самые крупные, предпочитают покупать "дешевых" тестеров, задачей которых является проверка соответствия конечного продукта заданным требованиям и не более.Vika, спасибо за ответ.Все остальные, в том числе и самые крупные, предпочитают покупать "дешевых" тестеров, задачей которых является проверка соответствия конечного продукта заданным требованиям и не более.
Прямо крик души
Думаю, не всё у нас так печально, как ты пишешь. И, кстати, из поста следует, что тестировщик на проекте с плохой спецификацией (или вообще без неё) — уже QA, т.к. проверять сответствие не с чем Но да это совсем другая история. Не хочется здесь начинать вечную дискуссию о различиях QC и QA. В своём вопросе под QA я подращумевала все активности, которые относятся к тестированию ПО. Сорри за подмену понятий 
То, что QA может частично (или полностью) выполять функции аналитика на проекте, по-моему, не хорошо, и не плохо. Это нормально.
Многие так отвечают, но мне как раз интересно, что заставляет людей совмещать роли, которые не так давно стали независимыми
И какие от этого есть преимущества и недостатки.
Думаю, самая распространённая причина — нехватка людей (аналитиков) в компании.
Ещё часто тестировщикам дают "попробовать" себя в бизнес-анализе, чтобы в будущем переманить в отдел аналитиковИ, кстати, из поста следует, что тестировщик на проекте с плохой спецификацией (или вообще без неё) — уже QA, т.к. проверять сответствие не с чем
Не факт (:. Ведь эту работу может продолжать делать кто-то другой (ПМ, лид, разработчик, да и сам БА).
Многие так отвечают, но мне как раз интересно, что заставляет людей совмещать роли, которые не так давно стали независимыми
хочется закончить словами "..от роли разработчика" (:
Думаю, самая распространённая причина — нехватка людей (аналитиков) в компании.
Ещё часто тестировщикам дают "попробовать" себя в бизнес-анализе, чтобы в будущем переманить в отдел аналитиковМмм.. я вот как бывший менеджер могу сказать, что самая распространенная причина, по мне, — это желание на 100% нагрузить имеющихся людей. По водопадной модели бОльшая часть аналитических активностей находится вначале проекта и уменьшается по мере продвижения к концу. У тех, кто занимается тестированием, бОльшая часть активностей приходится на конец проекта. Значит, если на все эти активности назначить одного и того же человека, то… ну сами понимаете (: Если говорить про, например, скрам, то там вообще ситуация, когда каждому члену команды неплохо бы вообще быть швейцарским ножом.
Ммм.. я вот как бывший менеджер могу сказать, что самая распространенная причина, по мне, — это [b]желание на 100% нагрузить имеющихся людей[/b]. Если говорить про, например, скрам, то там вообще ситуация, когда каждому члену команды неплохо бы вообще быть швейцарским ножом.
Вот сравнение, которое я точно возьму на вооружение! Блестяще сказано!
И, кстати, из поста следует, что тестировщик на проекте с плохой спецификацией (или вообще без неё) — уже QA, т.к. проверять сответствие не с чем
Не правда, вы подменяете понятия. Отсутствие на проекте документации, как правило, как раз-таки, подразумевает наличие на нем тестера, а не QA. Был бы QA — была бы документация. Хотя бы в виде тест дизайнов или User stories. Отсутствие документации обычно чревато плохим конечным качеством (если, конечно, на пректе не работает гений, что вряд ли). И поверьте мне, мой опыт менеджмента однозначно подтвердает истинность данной теории.
Кстати, крика души в моем посте не было, поскольку мне, собственно, совершенно не важно, сколько компаний предпочитает тестеров полноценным QA… Я констатировала факт, могу привести примеры. Но это будет как раз тот спор, которого вы хотели избежать: об отличиях.Многие так отвечают, но мне как раз интересно, что заставляет людей совмещать роли, которые не так давно стали независимыми
И какие от этого есть преимущества и недостатки.
Думаю, самая распространённая причина — нехватка людей (аналитиков) в компании.
Ещё часто тестировщикам дают "попробовать" себя в бизнес-анализе, чтобы в будущем переманить в отдел аналитиковЧто значит "заставляют людей совмещать роли"? Сама суть работы QA подразумевает некоторые аналитические активности. Я ведь написала, какие именно:
определить критерии качества конечного продукта, что и является, собственно, ТРЕБОВАНИЯМИ.
Вы вот говорите, что вы QA. Давайте представим себе работу этого самого QA так, как она, собственно, выглядеть должна.
Возмем "идеальный" проект, на котором все роли распределены. Аналитик соберет требования к продукту, он напишет документ и передаст его в RND отдел. Что будет происходить дальше с этим документом/ами? Со стороны QA? Как только готовы требования и даны первоначальные оценки со стороны девелопмента и QA, оба эти отдела начинают работу над проектом. С чего начнется ваша работа как QA? с написания тестовой документации. Вы возьмете требования, задокументированные аналитиком, переработаете их и составите user cases и test cases на их основе. Но, вы же понимаете, что даже в идеальной модели вам придется поработать "аналитиком", уточняя требования у аналитика, составившего документ. Вот вам прямое пересечение. После написания test cases вам надо будет их приоритезировать, составить список acceptance тестов, которые и будут являться КРИТЕРИЯМИ для оценки качества. А значит, у вас будут ТРЕБОВАНИЯ, ваши требования к работе конечного продукта на основе требований к нему заказчика… Это все можно продоложать и дополнять… Вы, как QA, должны будете продумать различные варианты использования продукта, продумать negative tests, продумать performance tests… И для всего для этого вам нужно будет снова и снова выяснять требования…
Хотите другой пример? А общение с заказчиком? Очень часто заказчик желает получать информацию из первых рук, очень часто QA приходится напрямую с ним говорить и уметь согласовать результаты… А вы, как QA, отвечаете еще и за то, чтобы качество конечного продукта, его вид и варианты использования заказчика устроили… А что, если вам кажется, что та или иная кнопка расположена не вполне удачно? Тестеру до этого дела нет, ему сказали — он сделал.. А QA до всего есть дело, поскольку у него есть свои требования.Работа QA и работа аналитика пересекаются намного больше, чем работа аналитика и работа программиста. QA — представитель пользователя (заказчика) внутри фирмы разработчика, гарант качества продукта и его соответвтия поставленным целям. Видите связь с аналитиком? Тестер — контролер программиста внутри фирмы разработчика. Он с аналитиком общего ничего не имеет .
QA — представитель пользователя (заказчика) внутри фирмы разработчика, гарант качества продукта и его соответвтия поставленным целям.
Отлично сказано. Абсолютно согласна с тем, что тестировщику приходится довольно часто применять аналитические способности, но я всё-таки спрашивала о варианте , когда тестировщик полностью замещает аналитика на проекте (анализ требований от заказчика, подготовка спецификации, выполнение роли главного источника информации в области требований на проекте). Т.е. бизнес-анализом никто не занимается, кроме человека, официальная должность которого "тестировщик ПО":)
Кстати, по поводу роли QA недавно прочитала интересную мысль (http://software-testing.ru/library/test … 145-bolton). Статья бунтарская, в стиле Майкла Болтона Но я считаю, что фраза "Наличие отдела обеспечения качества – признак некомпетентности в отделе разработки" имеет право на жизнь. Я видела спецификации, после прочтения которых возникают не вопросы, а мысль "какой же аналитик молодец, как можно было предусмотреть всё?" я вот как бывший менеджер могу сказать, что самая распространенная причина, по мне, — это желание на 100% нагрузить имеющихся людей. По водопадной модели бОльшая часть аналитических активностей находится вначале проекта и уменьшается по мере продвижения к концу. У тех, кто занимается тестированием, бОльшая часть активностей приходится на конец проекта.
Да, это схема, в которой я учавствовала неоднократно. Работает
Если говорить про, например, скрам, то там вообще ситуация, когда каждому члену команды неплохо бы вообще быть швейцарским ножом.
Моя подруга, которая сейчас работает тестировщиком в Швеции, как раз и выполняет роль швейцарского ножа: тестировщик + скрам-мастер + support issues менеджер. Правда, здесь уже возникает вопрос перегрузки людей…
стати, по поводу роли QA недавно прочитала интересную мысль (http://software-testing.ru/library/test … 145-bolton). Статья бунтарская, в стиле Майкла Болтона
Но я считаю, что фраза "Наличие отдела обеспечения качества – признак некомпетентности в отделе разработки" имеет право на жизнь. Я видела спецификации, после прочтения которых возникают не вопросы, а мысль "какой же аналитик молодец, как можно было предусмотреть всё?" С удовольствием прочитала статью, хотя нового для себя в ней почти ничего не нашла. Именно этому меня и моих коллег учили и продолжают учить в компании, в которой я работаю. Именно так мыслить учат ведущие тренеры на различнх конференциях и тренингах, и на американских "Старах", конечно. Так что я не совсем понимаю, что бунтарсокого вы в ней нашли. Автор, безусловно, грамотный, но он рассказывает прописные истины, которые просто не все знают или не все хотят знать по разным причинам.
Дело в том, что автор выступает против неверного толкования профессии, а не против наличия в фирмах отделов тестирования и утверждает, что каждый должен заниматься своим делом, а не контролировать чужую работу.Ответьте, пожалуйста, на вопросы:
[b]1) Вы когда-нибудь занимались тестированием ПО (вопрос к аналитикам)? [/b]
Если да, то как вам? Понравилось , не понравилось? Чем именно?
Если да, то желательно уточнить уровень вовлечённости в тестирование:
а) минимальные проверки софта перед демонстрацией заказчику;
б) учавствовали в тестировании ПО на проекте (был выделенный участок работы или полностью отвечали за тестирование продукта) и одновременно выполняли задачи BA;
в) тестировщик в прошлом.
г) свой вариант
Всем привет. Хочу просто поддержать опрос, так как в развернувшемся обсуждении не могу участвовать по причине некомпетентности. Зато с удовольствием отвечу от своего лица на первый вопрос.
В малых проектах я частенько выполняю роль тестировщика, потому что там каждый человек на счету. Так как кодить не дают, то я обычно плюс к разработке проектной документации тестирую приложение. Не скажу, что мне это нравится… Тестировщик в нашей местной ментальности (возможно, и не заслуженно) относится к младшему персоналу на проекте. И никакой контроль качества он не осуществляет. Просто заполняет специальный протокол тестирования и сообщает о найденных багах разработчикам или проектному менеджеру. Контроль качества, действительно, осуществляют ведущие специалисты. И действительно это мне кажется справедливым, потому что именно они планируют и распределяют ресурсы и чутко регулируют соотношения "стоимость/качество", "время/качество", "количество/качество".
2) Как вы думаете, роли «тестировщик» и «бизнес-аналитик» совместимы?
а) Если да, то что в этом сочетании хорошего?
б) Если нет, то что в этом сочетании плохого?Ответ на этот вопрос я не знаю. Наверное, совместимы, и наверное, крутые команды имеют в своем стаффе таких спецов.
Пожалуй, пока сворачивать обсуждение тестирования на форуме аналитиков
А то не миновать нам жёлтой карточки:
)
Всем спасибо за участие в опросе и интересные мысли.
Жёлтой карточки не будет. По крайней мере, пока (:
Я бы оставил тему открытой, раз она вызывает желание пообщаться/выяснить истину, т.е. интересна участникам.Привет,1 — занимался.
Варианты а) и в).
а) — неотъемлемая часть нашего процесса, так как никто лучше аналитиков не знает как домен, так и само приложение. Думается мне, что QA (в правильном смысле этого слова) нам бы в конторе и на проекте не помешал… Хотя, как правильно сказала Вика, я принадлежу к тому большинству, которые в жизни не сталкивались с настоящим QA, поэтому мне сложно судить об их сфере деятельности и квалификации.. Но по описанию круто
в) — на проектах без QA (в основном это небольшие проекты — от пары дней до пары недель).
Мне это периодически как нравится, так и не нравится. Нравится с точки зрения кратковременной смены деятельности + получаю удовольствие от ведения проекта, по сути, от начала и до конца (иногда приятно осознавать, что большая часть активностей в твоих руках и не приходится возлагать большую ответственность на тех, на кого не всегда можешь с уверенностью положиться). Не нравится с точки зрения именно вида деятельности — тестирование.. ну не мое это.2 — я, честно говоря, думаю, что это совместимо больше в плане "аналитик, занимающийся тестированием", чем "тестировщик, занимающийся анализом". Люди, конечно бывают разные, но большинство из тех тестировщиков, с кем мне приходилось иметь дело, крайне далеки от того, чтобы потянуть работу аналитика. И это, во-первых, опять же связано с тем, что настоящих квалифицированных QA я не видел… а во-вторых, как сказала Алиша (и это очень часто оказывается правдой), тестировщики — это в основно, младший персонал на проекте. Последней фразой я никого не хочу обидеть и сам лично не считаю, что тестировщики — это младший неквалифицированный персонал (по крайней мере очень хотелось бы, чтобы на моих проектах это было не так).. но, к сожалению, во многих компаниях реалии именно таковы — берем в тестеры дешевых студентов либо тех, кто не смог показать себя в другой области.
По своему опыту могу сказать, что это и не нехорошо, и неплохо — это нормально, и прежде всего определяется зрелостью компании. Понятно что в маленьких коллективах с небольшими проектами многие позиции взаимозаменяемы, тогда как в больших корпорациях уже имеется формальное разделение по областям и по зонам ответственности.
Ещё надо разделять такие вещи как QA и QC специалисты, если первые отвечают за качество отношений с заказчиком/партнером, то вторые отвечают за качество поставляемого решения. В данном случае, как я понимаю, имелись ввиду вторые.Ещё надо разделять такие вещи как QA и QC специалисты, если первые отвечают за качество отношений с заказчиком/партнером, то вторые отвечают за качество поставляемого решения. В данном случае, как я понимаю, имелись ввиду вторые.
Хотелось бы уточнить по поводу ответственности QA: вы не ошиблись? Вы действительно считаете, что QA отвечают за качество отношений с заказчиком/партнером? Нет, я не исключаю такой возможности.. особенно, если речь о том, что QA — это роль, которую могут играть руководитель компании, руководитель отдела производства, качества, маркетинга и т.д.
Вы должны авторизироваться для ответа в этой теме.
