Comments 15
Не дочитал статью, отвечаю на вопрос в заголовке - если разработчик не согласен, что это баг, то только обращение к заказчику или начальнику. Других вариантов нет.
Спасибо за комментарий, в статье я поставил акцент на факт того, что разработчик делает функционал по задаче и может повлиять на аналитику функционала, если есть для него явные технические расхождения. Тестировщик тестирует, но также он выполняет тестирование удобства использования. Тут уже вопрос к аналитике, а не к разработчику. И связываться с заказчиком минуя аналитика бессмысленно. Я частично согласен с вами, но если у вас есть опыт и вы как QA можете влиять на продукт путем обеспечения качества, то можно провести аналитику самому путем тестирования и просто согласовать это. Далее идем к разработчику и демонстрируем факт изменения требований. Но если нет требований, то и нет аналитики. Тема моего поста как тестировать без требований, а вы судя по всему говорите о наболевшем.
Вообще говоря, если нет требований, то нет и бага. Есть, может быть, некое серое место в системе (UI или функционал), которое каждый интерпретирует в меру своего опыта/видения.
И кстати, аналитика не было вообще в 95% проектов, где я работал. А так-то да.
Один из вопросов на собеседования тестировщика «Что такое баг?»
Хорошим ответом считается «Несоответсвие ожидаемого и фактического результата»
И тут я полностью согласен с вами. Опять же тестирование без требований нельзя назвать тестированием) Но реальность останется реальностью.
То есть, есть специальный аналитик на зарплате, но нет требований даже в виде имейла? Неплохо)
Легко. В задаче-тикете в общих чертах, грубыми мазками написано, что надо делать. У нас ведь эджайл, мы же не можем позволить себе тратить время на тз? Вот. А потом - голосом, голосом, или даже личным присутствием, такой "чайка-аналитик", ЕВПОЧЯ. Что-то разработчик написал в тикете, что-то не написал, о чём-то уже вообще все забыли ...
Ну вот кто тикет создал, тот и источник истины, к нему все вопросы. Если есть сомнения, то к челу повыше.
а чел повыше отправляет к челу пониже, и так зацикливаемся
А тогда ты плюешь на всех и делаешь, как считаешь правильным. Или уходишь, что ещё правильней.
Ну это как-то несерьезно... слишком просто взять и все бросить, заявление любой написать может, а вот взять штурвал корабля только герои
Что-то мне подсказывает, что несоответствие ожидаемого и фактического результата - это неправильная реализация. А баг - это незапланированное или неконтролируемое поведение программы. Например, ожидали оранжевую кнопку, а она - зелëная. Это не выполненное задание, а не баг. Баг - это когда ожидаешь, что при нажатии на кнопку у тебя скачается файл, а происходит отправка email. И это больше соответствует незапланированному поведению, в отличие от цвета кнопки.
На проекте есть аналитик, но нет требований? А чем, простите, аналитик занимается тогда?
Как тестировать без требований? Или как убедить разраба и себя, что это баг