Size: a a a

2019 February 01

AT

Alexander Tarankov in QA Сибирь
Тест е2е?
источник

VR

Vitaliy Roshchupkin in QA Сибирь
обычно да )
источник

AT

Alexander Tarankov in QA Сибирь
В долг живёте )
источник

AT

Alexander Tarankov in QA Сибирь
Потом придётся отдавать
источник

VR

Vitaliy Roshchupkin in QA Сибирь
потому и появляются мысли "а может не писать?" :))
источник

AT

Alexander Tarankov in QA Сибирь
Мы стараемся е2е не писать, чаще всего пишутся юниты. Их пишут программисты. Поэтому описанной проблемы у нас нет - мы пишем тесты вместе с задачей на разработку/фикс
источник

AT

Alexander Tarankov in QA Сибирь
То есть не когда баг найден, а когда решено его фиксить
источник

VR

Vitaliy Roshchupkin in QA Сибирь
Vitaliy Roshchupkin
Тут получается удобно программисту. Он исправляет баг и у него уже есть тест, который надо поднять.
Тут получается прикольная вещь. Ты нашел сегодня баг, e2e тест написать очень легко (ты еще в контексте).
А когда программист баг возьмет, он сразу и тест поднимет - тестеров не нужно будет отвлекать от задачек.
Переключений меньше :))
источник

AT

Alexander Tarankov in QA Сибирь
Vitaliy Roshchupkin
потому и появляются мысли "а может не писать?" :))
Думаю имеет смысл пересмотреть политику. Понятно, что сделано из лучших побуждений, но имеет свои минусы. Если есть желание и возможности делать по-другому, то надо делать по-другому, т.к. есть варианты лучше (хотя конечно надо смотреть на свою специфику, возможно сейчас наилучший вариант и есть)
источник

AT

Alexander Tarankov in QA Сибирь
Vitaliy Roshchupkin
Тут получается прикольная вещь. Ты нашел сегодня баг, e2e тест написать очень легко (ты еще в контексте).
А когда программист баг возьмет, он сразу и тест поднимет - тестеров не нужно будет отвлекать от задачек.
Переключений меньше :))
Да, есть плюсы в этом подходе, согласен
источник

E

Ekaterina in QA Сибирь
Vitaliy Roshchupkin
Тут получается прикольная вещь. Ты нашел сегодня баг, e2e тест написать очень легко (ты еще в контексте).
А когда программист баг возьмет, он сразу и тест поднимет - тестеров не нужно будет отвлекать от задачек.
Переключений меньше :))
А если тест не прошел? Тогда надо разбираться кто виноват (тест неверный или программист недофиксил) и переключаться все равно придется.
источник

VR

Vitaliy Roshchupkin in QA Сибирь
Ekaterina
А если тест не прошел? Тогда надо разбираться кто виноват (тест неверный или программист недофиксил) и переключаться все равно придется.
ну это уже вероятности :))
программисту в любом случае надо посмотреть, что его фикс помог. Даже нерабочий тест тут полезнее никакого - можно поправить недостающее )
источник

E

Ekaterina in QA Сибирь
Со стороны программиста да, согласна)
источник

E

Ekaterina in QA Сибирь
Тогда, мне кажется, надо определиться кому делать хорошо: программистам или тестировщикам? Потому что программистам удобнее иметь тест до фикса, тестировщикам логичнее, на мой взгляд, писать тест после проверки фикса.
источник

VR

Vitaliy Roshchupkin in QA Сибирь
тестерам лучше, если к ним придет поменьше багов )
источник

VR

Vitaliy Roshchupkin in QA Сибирь
поэтому кажется, что тест до фикса (или тест, который разработчик написал сам) - самое то
источник

ОН

Олег Неумывакин in QA Сибирь
Не думал, что такое еще раз увижу
источник

OL

Olga Leonova in QA Сибирь
Олег Неумывакин
Не думал, что такое еще раз увижу
источник

ОН

Олег Неумывакин in QA Сибирь
да именно так это и было в живую
источник

ОН

Олег Неумывакин in QA Сибирь
один в один
источник