Очередной совет из книжки Lesson Learned in Software Testing, № 111, оставил очень и очень спорное впечатление. В вольном переводе он звучит так:
Примите во внимание, что во время автоматизации вы не ищите баги.
Когда вы рассчитываете стоимость автоматизации, мы предполагаем, что вы фокусируетесь на непосредственной стоимости. А что еще вы могли бы сделать в то время, которое вы потратили на автоматизацию? Какие тесты вы не прогнали? Какие баги вы не нашли?
Во многих проектах непосредственно автоматизация означает приостановку тестирования и нахождения ошибок. Эта проблема является одним из аргументов использования техник "автоматизации заранее (авансом)", которые позволяют вам подготавливать автоматизированные тесты перед тем, как приложение будет выдано в тестирование. Например, data-driven strategy позволяет описывать тест-кейсы заранее. Вот в этом случае автоматизация как раз не приостанавливает поиск ошибок и даже ускоряет процесс тестирования и поиска ошибок.
В целом, зерно истины здесь есть. Действительно, автоматизация стоит колоссальных усилий. Особенно на этапе проб и ошибок, первых скриптов итд. Хорошо, когда приходишь в компанию - а там уже налаженный процесс. А если все не так?
И действительно, новомодные подходы типа TDD очень крутые и дают огромный выигрыш. НО. Я не согласна с тем, что автотесты на готовую систему не ищут ошибок.
Я помню, как я начинала автоматизировать - взяла свои кейсы и пошла "в дальний путь", к светлому будущему. Так вот, во время автоматизации (а удалось мне покрыть тестами лишь маленький кусочек функционала) я нашла кучу багов.
На простых GUI тестах! А все потому, что, написав скрипт 1 раз, очень легко его повторить, немного видоизменив. Например, в поле "индекс" можно ввести 6 чисел, чтобы система посчитала ввод корректным.
Написали положительный тест, а потом поехали - 5 чисел, 7 чисел, символы, пустая строка итд итп. Если каждое поле так тщательно проверять в каждой регрессии вручную - спятить же можно! Конечно, мы не будем каждый раз проверять каждое поле, это слишком нудно и утомительно.
А писать это в тестах весело и прикольно! И тут, внезапно, находятся баги. Как на тестах, которые когда-то проходил вручную, потом подзабил, так и на тех, о которых додумался только сейчас. Или на что внимания раньше не обращал.
В общем, в тестах ты ищешь каждую мелочь, обращаешь внимание на малейшие детали - ведь робот тупой, что ты скажешь проверять, то он и проверит, поэтому ты выполняешь тест вручную, наблюдаешь за результатом и оп-па! Оно, оказывается, давно не работает!
В общем, я за TDD и все такое, но категорически не согласна с тем, что во время простой GUI автоматизации баги не ищутся. Ищутся! Просто тестирование идет медленнее.
Примите во внимание, что во время автоматизации вы не ищите баги.
Когда вы рассчитываете стоимость автоматизации, мы предполагаем, что вы фокусируетесь на непосредственной стоимости. А что еще вы могли бы сделать в то время, которое вы потратили на автоматизацию? Какие тесты вы не прогнали? Какие баги вы не нашли?
Во многих проектах непосредственно автоматизация означает приостановку тестирования и нахождения ошибок. Эта проблема является одним из аргументов использования техник "автоматизации заранее (авансом)", которые позволяют вам подготавливать автоматизированные тесты перед тем, как приложение будет выдано в тестирование. Например, data-driven strategy позволяет описывать тест-кейсы заранее. Вот в этом случае автоматизация как раз не приостанавливает поиск ошибок и даже ускоряет процесс тестирования и поиска ошибок.
В целом, зерно истины здесь есть. Действительно, автоматизация стоит колоссальных усилий. Особенно на этапе проб и ошибок, первых скриптов итд. Хорошо, когда приходишь в компанию - а там уже налаженный процесс. А если все не так?
И действительно, новомодные подходы типа TDD очень крутые и дают огромный выигрыш. НО. Я не согласна с тем, что автотесты на готовую систему не ищут ошибок.
Я помню, как я начинала автоматизировать - взяла свои кейсы и пошла "в дальний путь", к светлому будущему. Так вот, во время автоматизации (а удалось мне покрыть тестами лишь маленький кусочек функционала) я нашла кучу багов.
На простых GUI тестах! А все потому, что, написав скрипт 1 раз, очень легко его повторить, немного видоизменив. Например, в поле "индекс" можно ввести 6 чисел, чтобы система посчитала ввод корректным.
Написали положительный тест, а потом поехали - 5 чисел, 7 чисел, символы, пустая строка итд итп. Если каждое поле так тщательно проверять в каждой регрессии вручную - спятить же можно! Конечно, мы не будем каждый раз проверять каждое поле, это слишком нудно и утомительно.
А писать это в тестах весело и прикольно! И тут, внезапно, находятся баги. Как на тестах, которые когда-то проходил вручную, потом подзабил, так и на тех, о которых додумался только сейчас. Или на что внимания раньше не обращал.
В общем, в тестах ты ищешь каждую мелочь, обращаешь внимание на малейшие детали - ведь робот тупой, что ты скажешь проверять, то он и проверит, поэтому ты выполняешь тест вручную, наблюдаешь за результатом и оп-па! Оно, оказывается, давно не работает!
В общем, я за TDD и все такое, но категорически не согласна с тем, что во время простой GUI автоматизации баги не ищутся. Ищутся! Просто тестирование идет медленнее.
