1. Программисту дают задачу: разработать фичу X.
2. Через неделю он приходит и даёт отчёт о том, что он пофиксил баг (написал тесты) Y.
3. Вопрос: сколько подобных ситуаций продержится программист на рабочем месте?
Конечная цель же не платить человеку, а разработать качественный софт.
Ха ха ха. Вы, явно, не владелец бизнеса, а работаете на какую-то компанию.
Тут очень много вопросов к сравнили и подсчитали.
И юнит тесты и акцептант тесты и ручное тестирование — они независимо ценны.
Опять это вопрос к бизнесу
Я не спорю с тестированием и с TDD, не говорю о бесполезности тестирования программистами своего ПО. Я говорю о ситуации, когда начальник сознательно заложил (или не заложил, или неполностью заложил, или заложил отсутствие в цену ПО) тесты тому или иному работнику.
И я говорю, что, возможно, бизнесу всё-таки стоит больше использовать тесты чем вероятности.
Почему же странное? Возможно, это были 30 тикетов с багтрекера. А клиенты уже на сидят на игле. Менеджер понимает, что, даже если тикеты не закрывать, клиентам будет очень сложно слезть с иглы.
Вы ведь тоже не перестаёте ходить в магазин после ежегодного роста цен на 10% или резкого повышения тарифов на городской транспорт.
С другой стороны, возможно, это 30 задач из бета версии, которую пока не планируют выпускать на рынок, а просто тихо-мирно тестируют на клиентах.
А быть может, необходимо срочно закрыть 20 важнейших задач до конца года.
Смысл автоматизированных тестов — это возможность их работы без участия человека.
Нет, это смысл автоматических тестов. А автоматизированные тесты предполагают разомкнутый процесс тестирования, контролируемый и управляемый человеком.
1. Нажал кнопку — всё сломалось.
2. Починил — некоторые тесты не прошли проверку.
3. Создал тикет/задачу.
4. Дождался фикса и по новой с п. 1.
Вы описываете waterfall подход?
Не совсем. Просто классическое планирование бизнеса и его процессов, которое включает контроль качества и анализ рисков.
Во-первых, автоматизированные тесты необходимо:
1. кому-то придумать,
2. кому-то автоматизировать,
3. кому-то выполнить и оценить результаты (они ведь не автоматические).
Во-вторых, почему тестировщик обязательно должен выполнять всё вручную? Он что, слишком тупой? По-вашему, только программисты разбираются во всех этих девопсах?
В третьих, сценарии и юнит-тесты — это одно, а контроль качества — это другое. Все необходимые сценарии, критерии и нормы закладываются ещё до того, как программист начинает что-то писать. Возможно, программист захочет протестировать эти 50 API endpoints, а менеджеру важны лишь 20 из них, а остальные — это доп. функциональность, которая не влияет на покупательную способность (а лишь на лояльность клиентов). Возможно, рынок и так уже захвачен или наоборот, компания решила покинуть рынок, снять сливки (привет, iphone). Получается:
1. программист сделал дополнительные 50 тестов
2. программист выполнил 30 лишних тестов
3. кпд тестирования = 20/(20+50) = 30%.
2. Через неделю он приходит и даёт отчёт о том, что он пофиксил баг (написал тесты) Y.
3. Вопрос: сколько подобных ситуаций продержится программист на рабочем месте?
Ха ха ха. Вы, явно, не владелец бизнеса, а работаете на какую-то компанию.
Я не спорю с тестированием и с TDD, не говорю о бесполезности тестирования программистами своего ПО. Я говорю о ситуации, когда начальник сознательно заложил (или не заложил, или неполностью заложил, или заложил отсутствие в цену ПО) тесты тому или иному работнику.
И я говорю, что, возможно, бизнесу всё-таки стоит больше использовать тесты чем вероятности.
Вы ведь тоже не перестаёте ходить в магазин после ежегодного роста цен на 10% или резкого повышения тарифов на городской транспорт.
С другой стороны, возможно, это 30 задач из бета версии, которую пока не планируют выпускать на рынок, а просто тихо-мирно тестируют на клиентах.
А быть может, необходимо срочно закрыть 20 важнейших задач до конца года.
Нет, это смысл автоматических тестов. А автоматизированные тесты предполагают разомкнутый процесс тестирования, контролируемый и управляемый человеком.
1. Нажал кнопку — всё сломалось.
2. Починил — некоторые тесты не прошли проверку.
3. Создал тикет/задачу.
4. Дождался фикса и по новой с п. 1.
Не совсем. Просто классическое планирование бизнеса и его процессов, которое включает контроль качества и анализ рисков.
1. кому-то придумать,
2. кому-то автоматизировать,
3. кому-то выполнить и оценить результаты (они ведь не автоматические).
Во-вторых, почему тестировщик обязательно должен выполнять всё вручную? Он что, слишком тупой? По-вашему, только программисты разбираются во всех этих девопсах?
В третьих, сценарии и юнит-тесты — это одно, а контроль качества — это другое. Все необходимые сценарии, критерии и нормы закладываются ещё до того, как программист начинает что-то писать. Возможно, программист захочет протестировать эти 50 API endpoints, а менеджеру важны лишь 20 из них, а остальные — это доп. функциональность, которая не влияет на покупательную способность (а лишь на лояльность клиентов). Возможно, рынок и так уже захвачен или наоборот, компания решила покинуть рынок, снять сливки (привет, iphone). Получается:
1. программист сделал дополнительные 50 тестов
2. программист выполнил 30 лишних тестов
3. кпд тестирования = 20/(20+50) = 30%.