Очередной спринт, месяц, год прошел с лозунгом «автотесты нам нужны, но делать мы их не будем, так как есть чем заняться поважнее». Я понимаю руководство всех уровней. Им нужен функционал и клиенты. Автотесты не дают второго и мешают делать первое. Однако с ростом функциональности продукта – необходимость в автоматизированном тестировании будет расти, на мой взгляд, экспоненциально. Так как любые изменения могут «задеть» все больше и больше функционала. Отсюда у меня родилось несколько мыслей про автоматизированное тестирование.
Сразу оговорюсь – я не тестировщик и не разработчик автотестов. Следовательно, могу заблуждаться в этом вопросе. Я говорю от лица человека, который будет править баг, который в лучшем случае будет найден на этапе тестирования релизной сборки, а в худшем – найденный клиентом.
Вообще говоря – разработка автотестов, на мой субъективный взгляд, может быть очень неплохой практикой для начинающего программиста или студента.
Во-первых, придется писать рабочий код с теми же самыми инструкциями языка, что и в разработке программного продукта.
Во-вторых, вы никому не навредите ошибкой. В худшем случае проглядите баг, который и так есть в продукте.
В-третьих, можно немножко нагумнокодить. Требования по архитектуре, разумеется, есть, но они ниже, чем к тестируемому программному продукту и в самый раз, чтобы попрактиковаться.
В чем, на мой взгляд, кроются нюансы разработки автотестов. На мой взгляд, нюанс один – требуется понимать, что вы вообще тестируете. Возьмем, к примеру, такой инструмент как katalon recorder. Поверхностный поиск по названию продукта быстро вас приведет к статье на Хабре, описывающий возможности продукта. Что я там не нашел, так это проверки состояния приложения. Т.е. фактически это тестирование интерфейсной части системы. В чем проблема? Ну, например, я могу реализовать метод, который будет возвращать хардкодные данные для интерфейса, а сей продукт будет их проверять. Тест будет зеленый, а система не работает «от слова совсем», просто возвращает статику. Можно ли это применять на практике? Да, полностью. Но только с полным пониманием, что вы тестируете. Хотите проверить поведение интерфейсной части – ради бога. Думаете, что комплексно проверили систему? Ну, у меня для вас не очень хорошие новости.
Что нужно для полноценного комплексного тестирования? Тут правильный ответ может быть только перфекционистским и идеализированным - «проверять всё». Система должна отправлять письмо? Проверяйте почтовый ящик. То, что на экране написано «мы отправили вам письмо» не значит, что действительно отправили. Вдруг у вас странный адрес и оно застряло в очереди отправки. На экране показано, что вы сохранили свои действия? Ну, будьте добры тестом сходить и проверить что сохранили. И так далее до бесконечности.
Каков итог всех моих бессвязных мыслей? Как всегда – никакого. Мне нужны автотесты. Обращаю внимание – автотесты. Тестировщики-автоматизаторы у меня есть. Но в текущем состоянии они заняты какой-угодно полезной деятельностью кроме написания автотестов. А еще у меня в очереди пласт задач, которые надо реализовывать и тестировать.
Вроде немножко выговорился. Везде ли так поставлена работа как у меня? Не знаю. Лично мне кажется, что почти везде так и причина отражена во вступлении. У компании вряд ли найдется желание и ресурсы на данный процесс и скорее будет нанят еще один программист и тестировщик, чем будет выделяться время на разработку автотестов, которые освободят руки текущих специалистов.