Те, кто не знаком с продуктовой разработкой согласятся с этим выражением, остальные же злорадно ухмыльнуться и пожелают удачи. А удача действительно понадобится, без неё дальше никуда.
Почему же тестирование - настолько важная часть разработки ПО? Любое ПО начинается с планирование, что будем делать, как оно будет работать и зачем вообще мы будем это делать. На основании этих и не только вопросов вырисовывается общий функционал проекта, пишется ТЗ, подбирается архитектура. И! Подготавливается инфраструктура для тестирования.
Что же тут тестировать? Ничего же не готово. Но на самом деле готово уже довольно много. Так как планирование завершено и технологии выбраны, то уже можно задумываться о тестах. А именно - их автоматизации. Поэтому на данном этапе выбираем технологии, с помощью которых будем тестировать приложение.
Да, никакого ручного тестирования. Да, это относительно дёшего, да - это разгрузит разработчиков и снимит с них необходимость написания тестов, но принесёт с собой много боли. Мануальное тестирование должно быть там, где дорого и сложно автоматизировать процесс тестирования и в идеале в будущем всё же тоже должно быть автоматизировано.
Автоматизация позволит ускорить процесс тестирования, а следовательно и скорость разработки (как бы абсурдно это не звучало). Запустить автоматику - пара секунд/минут, отдать QA мануальщику - лишние операции и всё зависит от расторопности и профессионализма тестировщика. Да и человеческий фактор никто не отменял, ошибок может быть в разы больше, чем при автоматизированном тестировании.
И так, разобрались с фрэймворками. Теперь можем уже начать разрабатывать проект? Тесты и потом можем прикрутить.
Нет, процесс разработки идёт параллельно с написанием тестов. Как только добавляется какой-либо значимый функционал - он должен быть покрыт тестами.
Но это же наоборот замедлит разработку!
Да, замедлит, но только на начальном этапе, зато сохранит кучу времени в будущем. При активной разработке будут гарантированно активно меняться различные части ПО и может быть нечаянно сломан уже готовый, ранее корректно работавший функционал.
Да, тесты спасают не только при рефакторинге и расширении продукта, но уже начинают помогать на ранних этапах разработки ПО.
И что? Мне теперь каждый метод надо покрывать тестами? Писать юнит (https://habr.com/ru/post/169381/) тесты на всё?
Нет, на всё смысла писать тесты нет, тесты пишутся для покрытия значимого функционала. Что будет значимым, а что нет - решать уже вам. Простой пример: запрос к БД и получение данных с минимальной бизнес-логикой - скорее всего будет значимым функционалом; Метод, который вызывает под собой хеш функцию и добавляет хеш к строке - скорее всего будет работать корректно всегда, если только это не собственная реализации хеш функции, поэтому смысла писать туда тест нет, 99%, что всё будет работать корректно всегда.
Всё, что идёт из фрэймворков и уже протестированного за тебя готового кода - тестировать смысла нет, это сделали другие разработчики.
Ну ок, юнит тесты пишем для всего ЗНАЧИМОГО функционала, но есть же ещ куча других видов тестирования (https://habr.com/ru/post/351756/). Когда их писать?
По мере необходимости. Если уже готовы отдельные рабочие модули ПО, то для них можно написать стресс тесты, если есть несколько модулей, которые коммуницирует между собой, да ещё и систему оплаты стороннюю уже подключили, то самое время написать интеграционные тесты. Для каждого фикса бага - тоже необходимо написать тест, воспроизводящий этот самый баг и убедиться, что он больше не воспроизводится. А если в будущем и вылезет, то это будет сразу видно благодаря тесту. (https://habr.com/ru/post/358142/)
И что? Всем этим тоже разработчики должны заниматься? Кто будет поддерживать всю инфраструктуру, где будет крутиться автоматика?
DevOps инженеры (https://habr.com/ru/post/469277/), которые и будут заниматься поддержкой CI/CD (https://habr.com/ru/company/otus/blog/515078/). Разработчик будет её только использовать.
А что делать с остальными тестами? Кто их писать будет? Опять разработчики?
Нет, для этого можно нанять пару SDET (Software development engineer in test) (https://habr.com/ru/post/414563/), они помогут с написанием автоматики. Но Unit тесты всё же придётся писать разработчикам, тем более это не так уж и сложно, да и SDET тут тоже может помочь.
И что, QA больше не нужны?
Почему же, они могут работать совместно с SDET, помогая им составлять тест планы (https://habr.com/ru/post/246463/). Но да, если всё покрыто тестами, а покрытие в идеале должно быть не ниже 90% функционала ПО, а в самом идеальном мире и вообще 100%, то QA (мануальщики) инженеры уже не так и нужны и можно их переквалифицировать в SDET'ов.
В дальнейшем тесты помогут избежать ошибок, при изменении/доработке/расширении функционала ПО. Ну и само собой избежать множества багов и повысить качество вашего продукта, а следовательно и прибыль от довольных клиентов.
И что же, багов совсем не будет и протестировать получится всё?
Нет, покрыть всё тестами не получится, как бы этого не хотелось. Всегда будет что-то, что ускользнуло от нас. Качественное покрытие тестами поможет ЗНАЧИТЕЛЬНО снизить кол-во багов. Но не избавит нас от них. Тесты будут продолжать писаться на каждый новый найденный баг, новый функционал и так далее, на протяжении жизни проекта.
То есть если у меня 100% покрытие тестами, то я могу им доверять и руками ничего не надо тестировать?
Нет, руками тоже придётся тестировать. Полностью доверить автоматике не стоит. Сложный и критичный функционал необходимо тестировать отдельно и мануально, чтобы убедиться в корректности его работы.
Ну и UI, верно? Потыкать по кнопкам, посмотреть, что и как меняется, все ли уведомления показываются и всё ли на своих местах.
Тестирование UI тоже можно и нужно автоматизировать, тут прекрасно подойдёт Selenium (https://habr.com/ru/company/badoo/blog/337126/), это один из самых популярных фрэймворков для тестирования UI, он полностью имитирует работу пользователя в браузере. Для десктопных и мобильных приложений тоже подойдёт. Он доступен для большинства популярных языков (C++/C#/Java/PHP/JS/Python...), а его подключение крайне тривиальное. (https://habr.com/ru/company/simbirsoft/blog/459292/)
Звучит круто, а с чего начать?
Начать стоит с этого: https://habr.com/ru/post/549054/