DK
а нужное поле в документации описано?
Size: a a a
2019 September 11
R
DK
косяк же. Все что в документации, должно быть в плане тестирования
R
ну, если так подходить, то косяк программиста, он же не сделал то, что в документации
R
и QA не нужна
R
как бы понятно, что косяк
DK
QA не заметили. и пропустили
R
не понятно это косяк, за который надо карать или это норм погрешность
DK
я бы карал
DK
программист не может не ошибиться, но когда две службы пропускают баги задокументированных моментах - это неочень
R
ощущения такие же, но с другой стороны QA не саперы же, тоже могут ошибаться
OE
Тут зависит от того, как у вас устроен процесс и насколько регулярно программист пропускает часть задачи, насколько он нагружен, как выспался перед работой, не голодный ли. А тестировщики видимо вообще документацию не читают, надеются, что программист-то уж точно читал, но так низя. Но вообще я б тоже карала тестировщиков.
SS
Если в документации есть - косяк QA - при условии что было выделено время
SS
по логике есть функционал который сделан по спеке
по реализации функционала в процессе есть проверка QA этого функционала по этой спеке и лично ответственный за эту проверку - его и карать
по реализации функционала в процессе есть проверка QA этого функционала по этой спеке и лично ответственный за эту проверку - его и карать
SS
если пропало после - есть регрессионное тестирование, но это уже вероятностный процесс - qa карать надо, но еще карать надо и программиста
SS
только что это вопросы для начинающих? пора валить в другой чат,да?)
Т
А может никого карать не надо?
Человеческий фактор часто есть, надо его пытаться исключать другими путями
Человеческий фактор часто есть, надо его пытаться исключать другими путями
SS
надо. представьте себя на месте хорошего QA. Он тщательно проверяет, а его коллега спустя рукава. И коллеге это всегда сходит с рук. Какой вывод? Не напрягаться
ec
Только массовые расстрелы спасут Родину?
SS
не, точечные публичные порицания