Очередной совет из книжки 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 автоматизации баги не ищутся. Ищутся! Просто тестирование идет медленнее.
Надо прочесть эту книжку.
ОтветитьУдалитьЦенность книги не в том, что там написано, а в том, какие мысли тебя посещают при прочтении, и какие выводы ты делаешь. Очень полезная книга, судя по всему )
Да, да, Тимур, очень полезная! Именно тем, что иногда хочется поспорить, иногда соглашаешься... Но среди 350+ советов наверняка найдутся те, к которым не останешься равнодушным!
УдалитьТоже не согласен с тем, что при автоматизации, баги не ищутся. При написании кейсов к автотестам, при написании, отладки самих автотестов, у меня постоянно находится куча багов )
ОтветитьУдалитьНаходятся! Просто немного медленнее :)
Удалить> Просто немного медленнее :)
ОтветитьУдалитьНу, если в 50 раз теперь считается "немного", то, да, немного.
Не согласна, Сергей.
УдалитьТут все индивидуально. Смотря какой проект. Смотря какие тесты. Смотря какой опыт у автоматизатора... Нельзя просто обобщить, что всегда в 50 раз медленнее
Я видел проект, где это было в сотни раз медленнее.
УдалитьНо вы конечно правы, зависит от проекта. Давайте собирать статистику.
Сколько багов находят автотесты, в расчете на человекогод вложенных усилий?
Нет, Сергей, давайте начнем с того, что тестирование мерить числом багов в принципе некорректно.
УдалитьВася нашел 20 багов, а Петя всего 2, зато каких... Кто лучше тестирует? МОжно ли это измерить только лишь числом ошибок?
Так же и автотесты. Не спорю, те, кто собирает все грабли на пути развития в автоматизации, может не приносить плоды, однако это ведь не всегда так.
Тесты вообще не должны искать баги. Они должны их предотвращать.
> Тесты вообще не должны искать баги. Они должны их предотвращать.
ОтветитьУдалитьНеверно.
Отличная аргументация, Сергей :)
УдалитьНу, не совсем предотвращать - предотвращать до передачи тестировщикам. Разработчик внес изменение, прогнал сборку билда с тестами, сразу увидел, что разломал и починил