FT
Ildar Bekmansurov
я бы добавил, что в областях с высоким риском нанести смерть, кейсы нужны даже высококвалифицированным специалистам)
Это специфический случай, который для данного вопроса неприменим
Size: a a a
2018 December 12
FT
вообще в этом есть некий смысл)
То, что в этом есть смысл, я знаю. Но хочется хороших аргументов на случай важных переговоров :)
IB
Это специфический случай, который для данного вопроса неприменим
можно вообще не тестировать, как в гугле
FT
Ildar Bekmansurov
можно вообще не тестировать, как в гугле
Это уже не в ту степь. Потому что ЕМНИМС а) в гугле есть SDET, и б) тестирование они аутсорсят
IB
да я так, набрасываю)
E
То, что в этом есть смысл, я знаю. Но хочется хороших аргументов на случай важных переговоров :)
тест-кейсы в основном описывают функционал продукта, а если тестировщики например работают с ним продолжительное время, то они знают о продукте все и в тест-кейсы перед выкаткой и т.п. заглядывают довольно редко, а чек-листы как раз помогают быстро проверить не задел ли выкаченный фун-нал чего-то важного и т.п. Врятли это прям убедительный ответ, но и утверждение тоже довольно противоречивое)
EK
в гугле тестируют
EK
там есть
EK
Testing engineer's
EK
и SDET's
FT
тест-кейсы в основном описывают функционал продукта, а если тестировщики например работают с ним продолжительное время, то они знают о продукте все и в тест-кейсы перед выкаткой и т.п. заглядывают довольно редко, а чек-листы как раз помогают быстро проверить не задел ли выкаченный фун-нал чего-то важного и т.п. Врятли это прям убедительный ответ, но и утверждение тоже довольно противоречивое)
Ситуация:
1. У кого-то наверху возникла идея внедрить подробные тест-кейсы
2. У меня есть подозрение, что от этого будет больше вреда, чем пользы, потому что
2.1. Увеличатся затраты времени на документирование и поддержку.
2.2. Кейсы потом не будут переиспользоваться, (потому что сейчас чек-листы идут к своей задаче и устаревают вместе с ней). Для уточнения ситуации - уже есть очень хорошее покрытие юнит/системными тестами, которые пишут разработчики, и есть автотесты на UI уровне, которые дополнительно проверяют базовый функционал.
2.3. Мне пока непонятно, какую задачу этим собираются решить
3. Так что на случай возможного спора я хочу иметь аргументы от людей авторитетней меня, которыми можно пользоваться
1. У кого-то наверху возникла идея внедрить подробные тест-кейсы
2. У меня есть подозрение, что от этого будет больше вреда, чем пользы, потому что
2.1. Увеличатся затраты времени на документирование и поддержку.
2.2. Кейсы потом не будут переиспользоваться, (потому что сейчас чек-листы идут к своей задаче и устаревают вместе с ней). Для уточнения ситуации - уже есть очень хорошее покрытие юнит/системными тестами, которые пишут разработчики, и есть автотесты на UI уровне, которые дополнительно проверяют базовый функционал.
2.3. Мне пока непонятно, какую задачу этим собираются решить
3. Так что на случай возможного спора я хочу иметь аргументы от людей авторитетней меня, которыми можно пользоваться
DA
в гугле тестируют
В основном автоматизируют, кстати, а потом ешё тестируют тесты, чтобы тестировали нормально
ЕЛ
можно ли доверять коду, который проверяется кодом? И не нужны ли тесты, которые будут тестировать тесты?
IB
Ситуация:
1. У кого-то наверху возникла идея внедрить подробные тест-кейсы
2. У меня есть подозрение, что от этого будет больше вреда, чем пользы, потому что
2.1. Увеличатся затраты времени на документирование и поддержку.
2.2. Кейсы потом не будут переиспользоваться, (потому что сейчас чек-листы идут к своей задаче и устаревают вместе с ней). Для уточнения ситуации - уже есть очень хорошее покрытие юнит/системными тестами, которые пишут разработчики, и есть автотесты на UI уровне, которые дополнительно проверяют базовый функционал.
2.3. Мне пока непонятно, какую задачу этим собираются решить
3. Так что на случай возможного спора я хочу иметь аргументы от людей авторитетней меня, которыми можно пользоваться
1. У кого-то наверху возникла идея внедрить подробные тест-кейсы
2. У меня есть подозрение, что от этого будет больше вреда, чем пользы, потому что
2.1. Увеличатся затраты времени на документирование и поддержку.
2.2. Кейсы потом не будут переиспользоваться, (потому что сейчас чек-листы идут к своей задаче и устаревают вместе с ней). Для уточнения ситуации - уже есть очень хорошее покрытие юнит/системными тестами, которые пишут разработчики, и есть автотесты на UI уровне, которые дополнительно проверяют базовый функционал.
2.3. Мне пока непонятно, какую задачу этим собираются решить
3. Так что на случай возможного спора я хочу иметь аргументы от людей авторитетней меня, которыми можно пользоваться
ну вот исходя из пункта 2.3 и надо думать. Что-то их не устраивает в текущем подходе значит?
IB
можно ли доверять коду, который проверяется кодом? И не нужны ли тесты, которые будут тестировать тесты?
TDTDD
DA
можно ли доверять коду, который проверяется кодом? И не нужны ли тесты, которые будут тестировать тесты?
Ну там смотрятся всякие метрики тестов, чтобы не работали слишком долго, чтобы не проваливались случайно если не было изменений, чтобы код покрывали, вот это вот всё
ЕЛ
Ну там смотрятся всякие метрики тестов, чтобы не работали слишком долго, чтобы не проваливались случайно если не было изменений, чтобы код покрывали, вот это вот всё
тесты покрывают весь код, но их написал тот же разработчик, что и написал этот код
ЕЛ
ВДРУГ ТАМ ЛОЖНОПОЛОЖИТЕЛЬНОЕ
