TN
На регресс это вообще не влияет
смотря как оценивать время, здесь мы оцениваем сохраненное время на поддержку и дебаг регрессионных тестов, которые затрагивают функции, которые будут покрыты юнит тестами
Size: a a a
2021 February 18
IS
Отчасти. Но это не уменьшит никаким образом объем тестов на регресс.
TN
но конечно если брать чистое время выполнения регрессионных тестов, то оно останется прежним, и нужна автоматизация именно регрессионного набора, да )
VS
вы каких то выдуманных слонов считаете, которые «могли бы быть если бы…»
VS
связи там нет никакой, это разные уровни покрытия тестов
TN
ок, не буду спорить
I
@yuya_94 можешь дать оценку времени на тестирование, которая обоснует время, которое тратится
O
выяснила у разрабов, что юнит тесты нам не помогут. нужны UI
Они вас обманывают :)
O
если у кого-то были ситуации, когда в компании было только ручное тестирование, а потом позвали автотестировщика и он ускорил/замедлил скорость релизов, буду рада узнать о вашем кейсе побольше в личке)
Ну у нас в общем примерно так и было, правда автотестировщика вырастили в своем коллективе, ну... есть у этого подхода минусы, скажем ))
Но вообще мне кажется у вас какая-то проблема в первую очередь с коммуникацией и пониманием менеджером сути тестирования.
По опросу, бывает же что буквально сразу наступаешь на критикал, дальше тестить нет смысла, и тогда несколько минут. А бывает много миноров, ловишь их как блох на дворовой собаке. Ну естественно это дольше. Вам надо как-то свести вместе ожидания ваши, менджера и девов, например почему бы им не фиксить баги по мере поступления, а не ждать "возврата на доработку".
Но вообще мне кажется у вас какая-то проблема в первую очередь с коммуникацией и пониманием менеджером сути тестирования.
По опросу, бывает же что буквально сразу наступаешь на критикал, дальше тестить нет смысла, и тогда несколько минут. А бывает много миноров, ловишь их как блох на дворовой собаке. Ну естественно это дольше. Вам надо как-то свести вместе ожидания ваши, менджера и девов, например почему бы им не фиксить баги по мере поступления, а не ждать "возврата на доработку".
YT
Olga
Ну у нас в общем примерно так и было, правда автотестировщика вырастили в своем коллективе, ну... есть у этого подхода минусы, скажем ))
Но вообще мне кажется у вас какая-то проблема в первую очередь с коммуникацией и пониманием менеджером сути тестирования.
По опросу, бывает же что буквально сразу наступаешь на критикал, дальше тестить нет смысла, и тогда несколько минут. А бывает много миноров, ловишь их как блох на дворовой собаке. Ну естественно это дольше. Вам надо как-то свести вместе ожидания ваши, менджера и девов, например почему бы им не фиксить баги по мере поступления, а не ждать "возврата на доработку".
Но вообще мне кажется у вас какая-то проблема в первую очередь с коммуникацией и пониманием менеджером сути тестирования.
По опросу, бывает же что буквально сразу наступаешь на критикал, дальше тестить нет смысла, и тогда несколько минут. А бывает много миноров, ловишь их как блох на дворовой собаке. Ну естественно это дольше. Вам надо как-то свести вместе ожидания ваши, менджера и девов, например почему бы им не фиксить баги по мере поступления, а не ждать "возврата на доработку".
Спасибо, конструктивный совет)
ВК
какая у меня ситуция:
1 начальство жалуется, что тестирование медленное, тормозит релизы
2 я предлагаю нанять автотестировщика, чтобы в первую очередь покрыть регресс на мобилках
3 начальство говорит заставь наших разработчиков писать автотесты
4 я не согласна, потому что думаю, что это только замедлит релизы
1 начальство жалуется, что тестирование медленное, тормозит релизы
2 я предлагаю нанять автотестировщика, чтобы в первую очередь покрыть регресс на мобилках
3 начальство говорит заставь наших разработчиков писать автотесты
4 я не согласна, потому что думаю, что это только замедлит релизы
Все логично. Если сами разрабы будут писать тесты, им некогда будет делать задачи в таком объеме и тестирование начнет справляться :)
ВК
Но, само собой, если без шуток - это не очень эффективно.
YT
Все логично. Если сами разрабы будут писать тесты, им некогда будет делать задачи в таком объеме и тестирование начнет справляться :)
😂👍
AK
2021 год, люди все еще считают, что писать тесты на свой код - не царское дело.
С
2021 год, люди все еще считают, что писать тесты на свой код - не царское дело.
не всегда дело в "царском деле", очень часто просто не можешь развить шизу до такой степени, чтобы не доверять себе на 100% и покрыть то, что сделает человек не писавший конкретный код.
O
не всегда дело в "царском деле", очень часто просто не можешь развить шизу до такой степени, чтобы не доверять себе на 100% и покрыть то, что сделает человек не писавший конкретный код.
при чем тут шиза, это ведь по сути все равно что, допустим, с вечера написать список "что не забыть завтра утром перед поездкой: паспорт, документы, перекрыть газ, отключить воду"
С
Olga
при чем тут шиза, это ведь по сути все равно что, допустим, с вечера написать список "что не забыть завтра утром перед поездкой: паспорт, документы, перекрыть газ, отключить воду"
)) давайте мух отдельно от котлет. Поверхностные смоуки (дев.тест) о том, что оно хоть как-то работает - это обязанность девелопера перед закрытием задачи, да. А писать полноценные бизнес-тесты под свой код - это та ещё приколюха и совершенно не список с "не забыть паспорт".
O
ну вы вроде про "тесты на свой код" отвечали насчет шизы :) но может я не так поняла последнюю фразу
SB
в моей иерархии типичной айти-компании слабо представляется как тестировщик заставляет разработчиков писать тесты
что мешает регламентироаать процесс? например, для передачи таски в тестирование должно быть аппрувы в PR, пройдены регресс автотесты (если есть). Для передачи в релиз должно быть пройдено ручное тестирование, добавлены автотесты на новую фичу.
тесты может писать разработчик, тестировщик может помочь с кейсами.
тесты может писать разработчик, тестировщик может помочь с кейсами.
SB
что мешает регламентироаать процесс? например, для передачи таски в тестирование должно быть аппрувы в PR, пройдены регресс автотесты (если есть). Для передачи в релиз должно быть пройдено ручное тестирование, добавлены автотесты на новую фичу.
тесты может писать разработчик, тестировщик может помочь с кейсами.
тесты может писать разработчик, тестировщик может помочь с кейсами.
если тестировщику время и навыки позволяют, может по примерам и сам часть кейсов автоматизировать