D
Ildar Bekmansurov
в Казани сейчас продолжительность светового дня 7 часов 6 минут) хотя и не Сибирь и не крайний север
представляю как вы радуетесь солнышку
Size: a a a
2018 December 12
IB
представляю как вы радуетесь солнышку
А что такое солнце?
R(
Ildar Bekmansurov
А есть у кого в компании практика такая, что тесты отправляются на ревью разрабам?
Если автопроверки то они шли на коллективное ревью программистам айпа-платформы, но код-ревью.
R(
Ildar Bekmansurov
А есть у кого в компании практика такая, что тесты отправляются на ревью разрабам?
Еще один вариант всплывал в какой-то статье как пример того как подсказать девелоперам на что ты будешь проверять фичу. Но там были скорее "тестовые идеи".
В
Еще один вариант всплывал в какой-то статье как пример того как подсказать девелоперам на что ты будешь проверять фичу. Но там были скорее "тестовые идеи".
А это разве не критерии приемки? Мы такое практиковали на прошлой конторе. Когда к таске которую создавали на девелоперов, писали критерии приемки и узкие какие-то кейсы
R(
Лол, а зачем тогда ты нужен? Если ты не умеешь писать тесты? Тратить время программиста на ревью?
Ну вот Ildar правильно сказал:
"Ну он типа тебе говорит - вот этот тест смысла скорее всего не имеет, так как то-то и сё-то, а вот такой следовало бы добавить, так как там вот так и сяк."
Допустим разработчик знает что 35 сущностей на низком уровне тестируемого функционала проходят через 10 функций. Можно идти "черным ящиком" и писать проверки на все 35, а можно написать так чтобы более полно гонялись обработчики десяти, а для 25 остальных проверялось только что их дергает нужный из обработчиков.
"Ну он типа тебе говорит - вот этот тест смысла скорее всего не имеет, так как то-то и сё-то, а вот такой следовало бы добавить, так как там вот так и сяк."
Допустим разработчик знает что 35 сущностей на низком уровне тестируемого функционала проходят через 10 функций. Можно идти "черным ящиком" и писать проверки на все 35, а можно написать так чтобы более полно гонялись обработчики десяти, а для 25 остальных проверялось только что их дергает нужный из обработчиков.
IB
Ну вот Ildar правильно сказал:
"Ну он типа тебе говорит - вот этот тест смысла скорее всего не имеет, так как то-то и сё-то, а вот такой следовало бы добавить, так как там вот так и сяк."
Допустим разработчик знает что 35 сущностей на низком уровне тестируемого функционала проходят через 10 функций. Можно идти "черным ящиком" и писать проверки на все 35, а можно написать так чтобы более полно гонялись обработчики десяти, а для 25 остальных проверялось только что их дергает нужный из обработчиков.
"Ну он типа тебе говорит - вот этот тест смысла скорее всего не имеет, так как то-то и сё-то, а вот такой следовало бы добавить, так как там вот так и сяк."
Допустим разработчик знает что 35 сущностей на низком уровне тестируемого функционала проходят через 10 функций. Можно идти "черным ящиком" и писать проверки на все 35, а можно написать так чтобы более полно гонялись обработчики десяти, а для 25 остальных проверялось только что их дергает нужный из обработчиков.
Евгений ответил, что он читает код коммита и обо всем этом знает, так что ему помощь программиста не нужна.
D
Ситуация:
1. У кого-то наверху возникла идея внедрить подробные тест-кейсы
2. У меня есть подозрение, что от этого будет больше вреда, чем пользы, потому что
2.1. Увеличатся затраты времени на документирование и поддержку.
2.2. Кейсы потом не будут переиспользоваться, (потому что сейчас чек-листы идут к своей задаче и устаревают вместе с ней). Для уточнения ситуации - уже есть очень хорошее покрытие юнит/системными тестами, которые пишут разработчики, и есть автотесты на UI уровне, которые дополнительно проверяют базовый функционал.
2.3. Мне пока непонятно, какую задачу этим собираются решить
3. Так что на случай возможного спора я хочу иметь аргументы от людей авторитетней меня, которыми можно пользоваться
1. У кого-то наверху возникла идея внедрить подробные тест-кейсы
2. У меня есть подозрение, что от этого будет больше вреда, чем пользы, потому что
2.1. Увеличатся затраты времени на документирование и поддержку.
2.2. Кейсы потом не будут переиспользоваться, (потому что сейчас чек-листы идут к своей задаче и устаревают вместе с ней). Для уточнения ситуации - уже есть очень хорошее покрытие юнит/системными тестами, которые пишут разработчики, и есть автотесты на UI уровне, которые дополнительно проверяют базовый функционал.
2.3. Мне пока непонятно, какую задачу этим собираются решить
3. Так что на случай возможного спора я хочу иметь аргументы от людей авторитетней меня, которыми можно пользоваться
на прошлом месте мы писали подробные тест-кейсы по всяким исправленным факапам, и это было мудро, потому что когда тестируешь релиз-кандидата, то фиг ты сам вспомнишь какую-нибудь специфическую багу, даже если сам проверял ее исправление полгода назад. А тут прочитал, проверил. Но там был ваще не аджайл, на минуточку. Никто никуда не торопился.
D
Тему тест-кейсов полностью отбрасывать чревато, имхо
R(
Коллеги, никому не попадалось мнение признанного авторитета QA о том, что тест-кейсы нужны для случая большого количества малоквалифицированных тестировщиков, а если их мало и они квалифицированы, то лучше чек-листы?
Джеймс Бах и Майкл Болтон это много раз повторили. И даже охарактеризовали "большое количество малоквалифицированых с тесткейсами" как "фабричную школу".
DA
на прошлом месте мы писали подробные тест-кейсы по всяким исправленным факапам, и это было мудро, потому что когда тестируешь релиз-кандидата, то фиг ты сам вспомнишь какую-нибудь специфическую багу, даже если сам проверял ее исправление полгода назад. А тут прочитал, проверил. Но там был ваще не аджайл, на минуточку. Никто никуда не торопился.
О, был у меня такой опыт с вообще не аджайлом. Когда я туда пришёл - через полгода был готов релиз-кандидат. Когда я оттуда ушёл - через год ещё не было релиза и уволили менеджера проекта. Зато начальник отдела тестирования вполне по RUP описал все входящие и выходящие артефакты и чётко следил за их полнотой.
R(
Ildar Bekmansurov
я бы добавил, что в областях с высоким риском нанести смерть, кейсы нужны даже высококвалифицированным специалистам)
С этим Бах и Болтон не согласны.
1) У них есть пример того как кейсы в этом случае не сработали (Бах с сыном за один день тестирования довели медицинское устройство до смерти через самосжижгание).
2) Они ссылаются на то что американская FDA, строго говоря, не требует кейсов
3) Кейсы могут быть неполны или плохо написаны (в случае с вышеупомянутым устройством Баха привлекли на позднем этапе). Поэтому может получиться интересная ситуация когда кейсы не сделали того что надо сделать, и оказались менее нужны.
1) У них есть пример того как кейсы в этом случае не сработали (Бах с сыном за один день тестирования довели медицинское устройство до смерти через самосжижгание).
2) Они ссылаются на то что американская FDA, строго говоря, не требует кейсов
3) Кейсы могут быть неполны или плохо написаны (в случае с вышеупомянутым устройством Баха привлекли на позднем этапе). Поэтому может получиться интересная ситуация когда кейсы не сделали того что надо сделать, и оказались менее нужны.
R(
Ildar Bekmansurov
можно вообще не тестировать, как в гугле
Виттэкер, написавший "Как тестируют в Гугле", страшно бы удивился :)
D
О, был у меня такой опыт с вообще не аджайлом. Когда я туда пришёл - через полгода был готов релиз-кандидат. Когда я оттуда ушёл - через год ещё не было релиза и уволили менеджера проекта. Зато начальник отдела тестирования вполне по RUP описал все входящие и выходящие артефакты и чётко следил за их полнотой.
ну там касалось сферы телевидения, релизы раз в год - норма. На телеканалах народ всё равно годами не перегружает сервера. Типа, работает - не трогайте.
AS
@mitserdof зачем вам еще тестер? Не вывозишь?
R(
Ildar Bekmansurov
можно вообще не тестировать, как в гугле
А, и еще есть интересное видео 10-minute test plan , правда оно, говорят, несколько контроверсийное. Но идея интересная.
R(
Ситуация:
1. У кого-то наверху возникла идея внедрить подробные тест-кейсы
2. У меня есть подозрение, что от этого будет больше вреда, чем пользы, потому что
2.1. Увеличатся затраты времени на документирование и поддержку.
2.2. Кейсы потом не будут переиспользоваться, (потому что сейчас чек-листы идут к своей задаче и устаревают вместе с ней). Для уточнения ситуации - уже есть очень хорошее покрытие юнит/системными тестами, которые пишут разработчики, и есть автотесты на UI уровне, которые дополнительно проверяют базовый функционал.
2.3. Мне пока непонятно, какую задачу этим собираются решить
3. Так что на случай возможного спора я хочу иметь аргументы от людей авторитетней меня, которыми можно пользоваться
1. У кого-то наверху возникла идея внедрить подробные тест-кейсы
2. У меня есть подозрение, что от этого будет больше вреда, чем пользы, потому что
2.1. Увеличатся затраты времени на документирование и поддержку.
2.2. Кейсы потом не будут переиспользоваться, (потому что сейчас чек-листы идут к своей задаче и устаревают вместе с ней). Для уточнения ситуации - уже есть очень хорошее покрытие юнит/системными тестами, которые пишут разработчики, и есть автотесты на UI уровне, которые дополнительно проверяют базовый функционал.
2.3. Мне пока непонятно, какую задачу этим собираются решить
3. Так что на случай возможного спора я хочу иметь аргументы от людей авторитетней меня, которыми можно пользоваться
Ну вот все так и происходит: увеличивается время на документирование и поддержку, кейсы все равно недостаточно подробны ибо случаи разные бывают, где-то будет неточно написан, где-то не проапдейтится, где-то устареет....
Имеет смысл детально описывать вход и выход если они действительно детальны, скажем "если мы сначала встретили сущность типа MS с вариантами AB, а потом сущность того же типа с вариантами ABC, то ABC дожны быть видимы. А если наоборот, сначала ABC а потом AB, то AB можно спрятать".
Имеет смысл детально описывать вход и выход если они действительно детальны, скажем "если мы сначала встретили сущность типа MS с вариантами AB, а потом сущность того же типа с вариантами ABC, то ABC дожны быть видимы. А если наоборот, сначала ABC а потом AB, то AB можно спрятать".
R(
можно ли доверять коду, который проверяется кодом? И не нужны ли тесты, которые будут тестировать тесты?
- нельзя доверять :)
- могут быть нужны. Я делал.
Вернее самым простым вариантом оказалось сделать "ломалку", которая правила тестовые данные на неверные (откатить можно было через Git). Если "ломалка" поломала, скажем, 15 случаев, а ошибок только 14, значит где-то что-то не проверилось.
- могут быть нужны. Я делал.
Вернее самым простым вариантом оказалось сделать "ломалку", которая правила тестовые данные на неверные (откатить можно было через Git). Если "ломалка" поломала, скажем, 15 случаев, а ошибок только 14, значит где-то что-то не проверилось.
FT
Джеймс Бах и Майкл Болтон это много раз повторили. И даже охарактеризовали "большое количество малоквалифицированых с тесткейсами" как "фабричную школу".
Во, спасибо, теперь я по ключевым словам сам все нашел
IB
- нельзя доверять :)
- могут быть нужны. Я делал.
Вернее самым простым вариантом оказалось сделать "ломалку", которая правила тестовые данные на неверные (откатить можно было через Git). Если "ломалка" поломала, скажем, 15 случаев, а ошибок только 14, значит где-то что-то не проверилось.
- могут быть нужны. Я делал.
Вернее самым простым вариантом оказалось сделать "ломалку", которая правила тестовые данные на неверные (откатить можно было через Git). Если "ломалка" поломала, скажем, 15 случаев, а ошибок только 14, значит где-то что-то не проверилось.
это типа внедрения ошибок? Мутационное или как называется вид тестирования?