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

[Strategimws]

Здравствуйте, помогите пожалуйста новичку. На собеседованиях очень часто задают подобный вопрос. Подскажите пожалуйста, как все же дать правильный ответ? И что вы делаете когда у вас возникает подобная ситуация? Заранее спасибо)

[Freiman]

Правильного ответа нет. Рассуждайте, задавайте вопросы.

[Vasiliy]

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

Прикрепленные файлы

•  Screenshot_20200308-141106_Samsung Internet.jpg   127,53К   4 Количество загрузок:

[kuzyara]

Что делать тестировщику если программист считает что это не баг а фича

Чем баг отличается от
фичи: фича есть баг,
одетый во фрак!

[marko_sorokopud]

это вопрос не о правильном ответе, а о том, как вы мыслете

во-первых, если возникает спорный вопрос, это означает, что что-то не было проговорено до начала имлементации.

во-вторых - несколько вариантов, чтобы натолкнуть на мысли, но не более

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

2 если работаете с документацией, а в документации не описано, что так система должна вести себя, то программист прав - это фича, хотя...

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

 

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

[kuzyara]

во-первых, если возникает спорный вопрос, это означает, что что-то не было проговорено до начала имлементации.

В вашей фирме тестировщик участвует в бизнес-анализе и постановке ТЗ? Каким образом тестировщик попадёт в этап до начала разработки? Работает по совместительству аналитиком? Вы ему за это платите?

можно положить этот вопрос на заказчика, проджект менеджера, бизнес аналитика или продакт овнера

Какая у вас цепочка статусов задачи? ...=>«В разработке»=>«В тестировании»=>...? Рабочий процесс (jira) линеен? Каким образом тестировщик может кому-то поставить вопрос(задачу)? тем более заказчику? Максимум что он может - это вернуть в разработку, или у вас не так?

ваше дело задокументировать инцидент

Тестировщик участвует в составлении документации? Каким образом происходит "документация" "инцидента"? Кто у вас занимается решением "инцидентов" тестировщика?

найдите подход как объяснить программисту, что он не прав

А оно ему надо? Подходы искать, убеждать, что-то кому-то доказывать?

[kuzyara]

Что делать тестировщику если программист считает что это не баг а фича

 

Если на собеседованиях задают подобный вопрос, значит в конторе нет ни нормального аналитика, ни менеджера, ни программиста.

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

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

 

В современных же конторах пишут автотесты: сценарные тесты, функциональные, интеграционные. Процесс разработки _основан_ на tdd, ci/cd полностью автоматизирован, ведётся codereview и testreview тимлидами. Для TestMonkey здесь вообще нет места.

[kuzyara]

Как программист скажу вот что.

Если мне приходится отвечать что это не баг а фича - значит я не вижу решения на своём уровне, могу только подсказать вероятные пути. Поднимай вопрос и решай проблему сам. Что я могу сделать, если, как в том анекдоте, дом пи%$сы строили...

 

 

- Кто тебе дом строил? Здорово получилось...

- Да пидорасы!

- ??

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

[marko_sorokopud]

я не на "своей фирме", я сам тестирую программное обеспечение. 

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

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

3. что касается статусов - есть статус qa failed или qa query. когда мне не понятночто, то что я вижу именно то, чего ожидает заказчик или конечный пользователь значит надо уточнить иначе есть риск что то где то пошло не так

4. "документация" "инцидента" - это баг репортинг, просто то, что все называют багом в ISO стандартах называется инцидентом, баг используется как синоним, но это не совсем корректное понятие. тестер определяет severity а представитель от бизнеса должен определить приоритет

5. я написал несколько раз, что все зависит. если это хороший девелопер, который просто не правильно понял суть поставленной задачи (все мы люди), тогда я ему объясню на нескольких примерах, почему он ошибается. Если это девелопер, без которого станет лучше жить, то я просто буду писать баг репорты и отправлять на приоритезацию бизнеса

 

вы написали об одном из типов проектов, которые существуют у нас на рынке. но таких не большой процент, и manual trainee там не нужен. поэтому сомневаюсь если человеку зададут этот вопрос а он ответит - если у вас нет tdd, atdd, bdd, unit testing, integration testing и бизнес аналитика - это фигня, я не хочу сдесь работать. вопрос "Что делать тестировщику если программист считает что это не баг а фича" - не зададут на собеседовние та такой проект о котором вы пишете

[Vasiliy]

 

во-первых, если возникает спорный вопрос, это означает, что что-то не было проговорено до начала имлементации.

В вашей фирме тестировщик участвует в бизнес-анализе и постановке ТЗ? Каким образом тестировщик попадёт в этап до начала разработки? Работает по совместительству аналитиком? Вы ему за это платите?

 

А сложно выдать тестировщику ТЗ на этапе "до разработки"? И попросить ознакомиться?

 

 

можно положить этот вопрос на заказчика, проджект менеджера, бизнес аналитика или продакт овнера

Какая у вас цепочка статусов задачи? ...=>«В разработке»=>«В тестировании»=>...? Рабочий процесс (jira) линеен? Каким образом тестировщик может кому-то поставить вопрос(задачу)? тем более заказчику? Максимум что он может - это вернуть в разработку, или у вас не так?

 

По-хорошему, тестировщик должен задать вопрос аналитику или владельцу продукта. Там до заказчика уже один шаг.

 

 

ваше дело задокументировать инцидент

Тестировщик участвует в составлении документации? Каким образом происходит "документация" "инцидента"? Кто у вас занимается решением "инцидентов" тестировщика?

 

Баг на документацию вполне обычная вещь. Вешается на аналитика.