Комментарии 8
Давно хотел автогенерацию смоук тестов
Интересная задача для разработчика (пишем какую-то софтину для автоматизации чего-то вместо тестов), но бесполезные расходы для бизнеса.
Даже не так, можно еще больше понизить планку для нашего smoke-теста поисковой строки. Заходишь на страничку гугла — а он тебе показывает что-то похожее на то, что показывал в течение последних двух месяцев. Сообщение об ошибке или пустой экран не очень похожи на поисковую строчку — в этом случае тест упадет. Во всех остальных — пройдет.
Мне кажется, это очень однобокий взгляд на Smoke-тесты. Взять ваш же пример со страничкой гугла. Вы делаете акцент на "что-то похожее", наверное, потому, что всё-таки готовы к каким-то изменениям на странице. Проблема в том, что очень трудно понять, когда изменения позитивные, а когда негативные. Например, зайдёт такой "умный" тест на страничку гугла, а поисковой строки не будет вовсе. "Достаточно похоже", — подумает алгоритм, и тест пройдёт. Если Вы думаете, что поисковая строка слишком большой элемент, чтобы его проигнорировать, представьте интернет магазин, у которого удалили кнопку + ("плюс") для добавления товара в корзину. Ничего купить нельзя, зато мы сэкономили время на написании Smoke-тестов.
На моей практике, все попытки масштабной автогенерации тестов сводятся к фразе: "ну мы же не обязаны использовать только сгенерированные тесты!". Это правда, и по факту данные сгенерированные тесты занимают лишь малую часть тестирования, и уж точно не способны целиком заменить smoke-тестирование.
Обычно сгенерированные тесты оказываются хороши для каких-то специфических проверок, в тех случаях, когда никакого интеллекта не нужно, но объём тестов либо очень большой, либо динамически меняется. Например, если команда делает конструктор для создания страниц компании в одинаковом стиле. Имея список созданных страниц, может быть полезно при релизе пройти по ним и проверить, что ни одна из них не возвращает 500.
Насколько я понимаю, у нас с Вами разное понимание smoke-тестирования. Возможность выполнить один из самых основных юзкейсов, на мой взгляд, это тоже часть smoke-сценариев (проверил заодно, что ISTQB думает по этому поводу). Судя по
Smoke-тест должен проверить, что все работает на выходе и не сломалось минимально. Совсем примитивный smoke-тест о том, что система запустилась и как-то работает, в нашем случае не приносит никакой пользы. Допустим, мы проверили, что подключение к базе есть, что-то запускается, UI получает какой-то API. А потом шаг влево, шаг вправо — и ничего не работает. То есть smoke-тест как бы есть, но с продакшена все равно летят ошибки.
команда Юлии тоже воспринимала smoke, как к проверку на "невозможность выполнить никакие юзкейсы", и это не приносило практической пользы. И в итоге, проблема была решена unit-тестами, что хорошо (shift-left, все дела).
В целом, я вроде понял, про какие тесты Вы говорите. Кажется, это то, про что я написал "лишь малая часть тестирования" в предыдущем комментарии. Дискуссия оказалась только о терминологии.
1. Отсутствие адекватных требований, по которым можно составить интерфейс, а затем его протестировать. Почему-то многие думают, что писать и проектировать — это одно и тоже. Однако в действительности очень редко ставятся чёткие задачи и, соответственно, очень редко проводится адекватное тестирование. Как задача поставлена, так её и выполняют, а остальное не принесёт денег в краткосрочной перспективе.
2. Некоторые тесты покрывают другие тесты. Поэтому проще протестировать какой-то большой блок и с вероятностью 5% ошибки, писать отдельные тесты. В противном случае 95% тестов не приносят результата, но тратят ресурсы.
Как заставить машину написать тесты из кода за тебя