Многие скажут, чтобы искать баги. Но ведь они их не ищут. Максимум тесты проверяют соответствие полученного результат ожидаемому. И где здесь поиск багов? – «Нет, не видел»!
Имел недавно разговор с одним разработчиком, в результате которого пришли к выводу, что тесты пишутся, чтобы проверить «контракты» между компонентами, на предмет удобства использования, доступа, использования определенных типов данных и некоторых других моментов:
- Пишешь ты новый код, тест твой первый пользователь. Если его написать просто и удобно, значит все хорошо.
- Пишешь тест на имеющийся код, ну не выходит «каменный цветок», приходится костыли подставлять, значит и код такой, и значит на лицо первый звоночек, что код приложения надо улучшать.
- Тоже самое и с автотестами, которые пишут тестировщики. Тесты пишутся на фреймворк, который работает с приложением, как с черным ящиком. Плохо написанный фреймворк, только усложнит написание тестов. (Если у вас нет прослойки фреймворка между приложением и инструментом, то скорее он уже включен в инструмент или же вам следует задуматься над его написанием)
Вы спросите, так зачем тогда писать тесты, если они не находят баги. Ответ прост. Тест проверяет, что «запускатель теста» может пройти от начала до конца. Если нет – значит что-то не так, и при этом в результате не всегда будет баг. Это может быть:
- инфраструктурная проблема
- проблема конфигураций (начиная от тестового стенда, до БД приложения или сети)
- качество теста (не обновленный после изменения кода тест, невалидный сценарий, неправильные тестовые данные)
- и в конце концов – баг.
Таким образом, второе предназначение теста - это сигнализация ситуации, когда «запускатель теста» НЕ может пройти от начала до конца сценария, и уже ваша задача определить причину.
Сообщения
Комментариев нет:
Отправить комментарий