При этом мы (тестировщики/тестеры/вставьтечтонравится) совсем не исключение.
И когда это случается, то ощущения получаются примерно такие:
Источники таких факапов можно грубо раскидать на три группы:
- Факап при реализации. Т.е. действия, совершаемые тестировщиком/его скриптом во время теста неправильные. В скрипте пропустили шаг. Ручками забыли кликнуть. Или сделали лишний шаг/кликнули лишний раз. Наконец просто говнотесты вроде AssertTrue(True).
- Факап при интерпретации. False negative/positive практически, только у них причины могут быть разными, а в данную группу мы отнесем именно ошибки толкования правильного результата. Это не только проблема автоматизации. Когда мы выполняем тесты ручками такое тоже может случиться.
- Факап в предпосылках. Кривые библиотеки используемые в автоматических тестах, ошибки спецификации, ошибки во время дизайна. Продолжать можно бесконечно. Все это может случиться и, будучи пропущенным на стадии работы с библиотечками/спекой/дизайном, грозит нам ошибками в самих тестах.
В лучшем случае пораженный тараканами тест даст нам false positive. Т.е. мы будем ожидать, что тест должен пройти, получим провал и начнем разбираться. Возможно это приведет к тому, что в процесса разбора завалов тест будет проанализирован, пересмотрен и поправлен. Только (внимание!) никто на не гарантирует что новый тест будет без багов. Не важно делаем мы его руками или это автоматический тест - от регрессии он не застрахован, ровно как и все остальное.
В худшем случае мы получим false negative и никаких оснований подозревать бажный тест в плохой работе у нас не будет. Ну пока исполнитель теста не заметит что тест-то бажный или не случится какая-нибудь катастрофа.
И нет серебрянной пули (если есть - скажите мне пожалуйста!), чтобы этих проблем избежать.
Автоматические тесты не помогут потому, что:
- Единожды сломанный автоматический тест так и будет оставаться сломанным, пока не случится что-то чтобы мы начали подозревать, что тест с багами.
- Да, автоматическими тестами проще работать с false positive, но от регрессий никто не застрахован.
- В результате непрерывного, длительного повторения баги, которые упорно отказываются находить наши бажные автоматические тесты, могут расти и пухнуть.
Ручные тесты не помогут потому, что:
- У людей, как правило, не идеальная память. Есть пресловутая "естесвенная девиация", которая может принести пользу в обнаружении вещей, которые автоматический скрипт обнаружить не способен. Например false negative в случае автомата рискует быть постоянным, а в случае ручного исполнения есть какой-то шанс его все же обнаружить. Но у нее есть и обратная сторона - у нас всегда есть риск "естественной девиации" в интерпритации результатов, например.
- Иногда очень сложно отловить false positive, допущенный в ручном тесте, так как процесс работы с ними несколько другой. Автоматический тест падает и мы идем разбираться что случилось. Ручной тест показал что все плохо - скорее всего мы уже поразбирались.
То есть проблема эта лежит не в плоскости автоматический/не автоматический тест.
Скорее всего корень зла где-то тут:
- У тестов (как и у тестируемого софта) есть простая тенденция - чем сложнее тест, тем больше шансов получить в нем баги. И этот шанс растет вне зависимости от того автоматический это тест или нет - меняются только точки возможного внесения дефектов в тесты. Но и одними простыми тестами, как правило, мы обойтись не можем.
- Мы можем набрать очень прокаченных тестировщиков, но даже они не застрахованы от багов в тестах. Багов, возможно, будет меньше. Но шансы их получить все еще останутся.
Спасибо за статью о наболевшем. Поделюсь своим опытом - у нас в проекте была отдельная команда для Разработки Тестов (Test Development Team). Когда я начала в ней работать я сама была в недоумении - зачем? зачем выделять так много отдельных людей, которые пишут сценарии, не выполняя на потоке, и чаще даже не имея до этого такого опыта (это прокол местного менеджмента). Но потом я начала понимать почему это важно - процесс разработки тестов был очень хорошо отлажен - Планирование, Разработка, Инспекция, Исправление, Выпуск, Валидация и куча документации на тесты во время процесса, но всё было настолько по книжному, что поработав в таком режиме пару лет я научилась классно планировать и писать тесты почти с закрытыми глазами. Но плюс этого процесса конечно же в том, что за тесты отвечает отдельная команда, и если кто-то находил багу в тестах, он заводил багу на тесты и решалась она по процессу. Понятно, что это применимо только для большого и длинного проекта, зато вот имеет место быть и хорошо работать.
ОтветитьУдалитьЯ очень плохо понимаю как можно писать тесты не имея при этом практики их исполнения. Более того - это плохая обратная связь, т.к. человек занимающийся разработкой теста в итоге знает о продукте в разы меньше чем исполнитель, что просто нонсенс. Отлов проблем в исполнении усложняется из-за увеличения цепочки. Отлов проблем интерпритации становится практически невозможным. И размер продукта тут ни на что не влияет.
ОтветитьУдалитьКо всему я очень плохо себе представляю как такое может функционировать в гибкой разработке, например.
ЗЫ: Хотя опыт, наверное, интересный
http://www.slideshare.net/VLDCORP/ss-1367042
ОтветитьУдалитьК сожалению звук в то время я не записывал. Если непонятно могу в личке объяснить суть идеи. Есть где-то даже пилотная реализация. Есть желание/возможность помочь мне довести идею до рабочей реализации?
Очень похоже на мутационное тестирование.
ОтветитьУдалитьЕсли да, то мы пробуем подобные вещи (есть уже готовые решения), возможно когда-нибудь попробуем их систематически делать, но там есть серьезные ограничения в применимости (и unit-test'ы тут ни при чем, кстати). Могу рассказать про имеющийся небольшой опыт, если интересно, но лучше почтой.
Любопытно узнать про опыт. Мои контакты есть тут http://sqagroup.spb.ru/contacts/
ОтветитьУдалитьИ да, мою идею можно считать kind of mutation testing и очевидно используется подход fault injection. Я изучал все это прежде чем подать на патент. Но в отличие от мутационного тестирования тут не надо знать логику работы метода.