Задумывались ли вы, почему, когда издают книжку или учебник, то в длинном списке участников подготовки издания числятся редактор и корректор. Неужели причина в том, что автор малограмотный? Нет конечно. Просто автор книжки может легко пропустить ошибки, неточности по причине своей сосредоточенности на содержимом. Именно поэтому нужен критик, сторонний человек, который скрупулезно вычитывает текст. И воспринимает его с позиций читателя.
По той же самой причине, выпуск софта в продакшн требует предварительного тестирования и выявления багов. Разработчики, хотя и знают свой продукт лучше других, зачастую пропускают ошибки и не видят проблем так, как это видит совершенно посторонний человек. Более того, тестировщик (классный, имеется ввиду) часто наделен качествами, позволяющими находить ошибки там, где их быть не может (с точки зрения разработчика) быть по определению. Именно поэтому, в жизненном цикле разработки софта (сайтов в том числе) предусмотрено тестирование продукта.
Надо понимать, что крупные проекты требуют тестирования еще на стадии разработки. Дело в том, что если будет найдена глобальная проблема (например, с безопасностью) уже на стадии подготовки выпуска софта, то это может привести к необходимости радикальной переработки всего и вся. А это - время и деньги. И провал дедлайнов. Модульность же архитектуры софта или проекта позволяет проводить и модульное тестирование отдельных модулей, плагинов и тому подобного.
И вот тут всплывает проблема выбора стратегии тестирования: ручное или автоматическое.
Преимущества и недостатки разных способов тестирования
Надо отметить, что тема плюсов и минусов автоматического и ручного тестирования довольно таки заезженная и на специализированных сайтах тестировщиков и для тестировщиков обсуждалась уже не раз, например, можно почитать тут: https://agilie.com/en/blog/manual-vs-automation-testing-do-you-need-both. Поэтому мы тут попробуем назвать не очевидные плюсы и минусы разных способов тестирования.
- Бесспорный плюс ручного тестирования в том, что разработчик знает, что его работу будут смотреть под микроскопом и каждая выявленная ошибка будет вольно или невольно давить на его самолюбие. Отсюда - стремление допускать как можно меньше ошибок. Если тесты автоматические, то эмоциональная составляющая нивелируется. Внезапно?
- Недостаток автоматического тестирования в том, что его реализации пишется скрипт. А это некий софт снова и он тоже может быть не лишен ошибок. А в результате можем получить удивительное совпадение двух ошибок: в разработанном софте и в скрипте для тестирования, в результате которых получим баг на выходе. Закон подлости тут просто радуется.
- Есть такое негласное правило - исправление бага (ошибки) приводит к порождению одной или даже большего числа новых ошибок. И тут чаще всего, чаще всего новые ошибки пропускаются при автоматическом тестировании (скрипты ж не переписывались).
- Очень скрытую, неочевидную ошибку тестировщики чащу всего находят на уровне интуиции (это почти магия). Автотесты же в большей степени настраивают на типовые ошибки, которые могут появляться в результате каких-то массовых изменений в коде. Зачастую тестировщик даже не может объяснить как он догадался, что есть ошибка.
Выводы. Для поиска системных, типовых ошибок в большой массе кода или операций стоит применять автоматическое тестирование, чтобы заменить рутинные повторяющиеся тесты. А ручное тестирование работает лучше там, где требуется интеллект и интуиция.
Похожие публикации
