Когда команда задумывается о том, что надо бы начать писать тесты и автоматизировать процесс запуска тестов в будущем, редко есть понимание, что будет дальше. Просто обычно об этом не рассказывают. А дальше количество тестов сильно вырастает, и если сразу не начать писать тесты правильно, то впоследствии это приведет сначала к дискомфорту, а потом и вообще к глобальным проблемам.
Типичный вариант развития тестов в компании:
- У нас сейчас 5 тестов, они проходят за 2 минуты. Круто.
- У нас 50 тестов, ждем 10 минут. Вообще классно. Мы столько написали!
- У нас 500 тестов. Ожидаем 2 часа – но оно того стоит, мы столько кейсов покрыли, а программист успевает пообедать, так что все отлично.
- У нас 1000 тестов, и мы ждем всего лишь 5 часов. Для нас это не критично, ведь программист успевает сделать пару подходов, и QA успевает дописать что-то и перезапустить.
- У нас 2000 тестов, и нам надо всего лишь 9 часов, чтобы это все проверить. Тестами же покрыта половина критической функциональности. Тесты успевают проходит за ночь, так что утром у нас всегда свежий прогон и все неплохо.
- У нас 4000 тестов, так что 16 часов – это вообще не проблема. Мы покрыли почти весь критический функционал, и если программист успеет написать код до обеда, то завтра утром он получит результат, так что все нормально.
- У нас 6000 тестов… А давайте мы часть тестов вырубим, ведь нам не надо столько, а ждать сутки – это долго. А эту фичу тестить не будем: она горит и там программист вроде не налажал. А еще, если мы в этой подсистеме ничего не делали, то и тестировать не надо, пусть QA ручками проклацает.
- Ааааа!…
Увы, но это так. Мы периодически сталкиваемся с проблемами компаний, которым тесты уже мешают, а не помогают. И там всё на негативе.
И самое печальное – отрефакторить тысячи тестов очень сложно.
Поэтому в этой статье мы поговорим о том:
- Как писать тесты правильно
- Почему QA не может дать быстрый отклик программисту
- Что делать, чтобы тесты приносили радость, а не боль
- Зачем про все это надо знать как можно раньше, пока не пройдена точка невозврата.
История
С приходом тестов в мир 1С случилось чудо: теперь можно не держать целый штат консультантов, которые, как роботы, пробегают по всем формам, и с замыленным взглядом пытаются найти ошибки в конфигурации после очередного обновления.
Давайте окунемся в этот дивный мир тестирования и поймем, что от него ожидать.
Итак, есть некая компания, в которой сейчас нет никакого тестирования доработок. Там работает наш герой QA (хотя он еще никакой не QA, а просто консультант первой линии техподдержки).
И вот он после универа, прочитал желтые книжки, сидит и отвечает на звонки клиентов. Звонит ему клиент, наш герой берет трубку, просит включит “тимку”, подключается к клиенту и видит, что документ реализации не проводится при некой комбинации параметров. Он выслушивает от клиента целую историю о том, что, если вот сейчас они не продадут этот карандаш за 10 рублей, то их бизнес остановится, и что виноват в этом будет лично этот консультант и вся его “много лестных слов” конторка.
Консультант, в свою очередь, тоже злится, потому что программист, который делал обновление, не проверил эту доработку (хотя программист-то проверил, но не все, и это важно).
И вот “висят” на линии два разозленных человека: один из них клиент, а второй – консультант. В итоге, консультант обещает все исправить и обращается к программисту. А программист сейчас другую ошибку исправляет, ему не до консультанта. В итоге – компания-внедренец нанимает нового программиста, чтобы они успевали фиксить баги. НО! Раз в компании теперь два программиста, компания решает взять еще проекты, чтобы они не сидели без дела.
И история с клиентом повторяется, но уже в большем масштабе.
Так проходит какое-то время, пока наш герой, чисто случайно, не узнает про то, что оказывается – есть тестирование. Причем автоматизированное, т.е. достаточно написать тесты и просто запускать их перед обновлением.
Наш герой – человек умный, он идет в чаты телеграм, чтобы узнать – а что это “за зверь” такой – “тесты”. Ему в чате присылают статьи, ссылки, видео с конференций.
Он смотрит видео с конференции, где докладчик рассказывает, как он у себя в компании написал и применил тесты, и теперь у них меньше ошибок, проще деплой и обновления как по взмаху волшебной палочки.
Далее наш герой читает статьи с красивыми графиками и хвалебными отзывами о тестировании. И ему становится понятно, что надо просто начать писать тесты.
А после этого у него возникает ощущение, что ему нужна система тестирования.
И в этот момент наш герой превращается в начинающего QA.
Продолжение
Так как наш герой – человек “пробивной”, он собирает всю эту информацию, идет к руководителю и обосновывает, что тесты нужны, и число ситуаций, когда прод летит на критических моментах, значительно уменьшится. Руководство дает добро, и наш QA начинает писать первые тесты.
Мы оставим за скобками то, где он их хранит, как запускает на компе и т.д., это не очень важно.
Важно то, что QA пишет тесты. И вот он написал первые 10 тестов. И теперь перед тем, как программисту дать отмашку на обновление, он запускает их, ждет 10 минут и дает вердикт – работоспособны ли ключевые операции или нет.
Обновления накатывают на прод, и на проде что-то опять падает, но уже не такое критичное, и клиент в принципе готов подождать час-два, пока эту багу пофиксят.
А QA инженер, “войдя во вкус”, пишет еще 10-20 тестов. Уже и на эти случаи тоже.
В итоге, написав суммарно 50 тестов, QA покрыл критические процессы. И теперь, буквально за полчаса – час, он может быть уверен, что прод не вылетит в критический момент.
Далее наш QA, устав постоянно писать разработчику тикеты, просто приходит к нему и показывает, как запускать Vanesa Automation, как нажать кнопку F5, подождать, пока пройдут тесты, и, если тесты упадут, то у разработчика сразу же сработает точка останова, и он сможет пофиксить ошибки, и не дергать QA. QA, в это время, может делать то же самое, но уже для другого клиента и программиста.
Наступила утопия
И вот, спустя полгода у этих ребят количество тестов уже перевалило за 500, они развернули отдельный сервер для тестов, чтобы, пока идут тесты, можно было заниматься другими вещами, например, смотреть котиков в интернете :)
Все радуются и даже подумывают о контурах сборок, потому что “А зачем вручную, если можно автоматически?”. И, некоторым образом, автоматизируют этот процесс.
Обеденные перерывы стали проходить спокойнее, так как срочных работ стало меньше, критические ошибки отлавливаются до того, как попадут в релиз. И единственное, что их беспокоит – что нужно немного дорабатывать тесты с выходом нового релиза обновления типовой конфигурации. Но это же нормально – не сидеть же QA без дела :)
В итоге процесс такой: программист внес доработки, поместил в хранилище, QA или сам программист зашел на сервер, запустил тесты. Подождал 4 часа, получил результат, а после этого провел обновления или начал фиксить обнаруженные ошибки.
И так продолжается еще полгода.
Хаос
И вот, спустя год ребята начинают слышать фразы, суть которых “Давайте обновлять без тестов, у нас нет времени ждать по 15 часов”.
QA инженер начинает жить в дедлайне, так как тесты падают, перезапуск долгий, за день успевают исправить один-два фикса.
Руководитель нервничает, так как теперь уже все завязаны на тесты, все понимают, зачем они нужны, но что со всем этим делать не понимает никто.
Системные инженеры разводят руками, так как купили сервер, а прирост он дал только 5-10%.
Программисты начинают писать код так, чтобы тесты прошли, и чтобы не ждать по 15 часов.
Мораль
Кто виноват в результате? Виноваты, в целом, все. Но основная вина, все же, будет лежать на QA инженере, который писал зависимые тесты.
Экспресс-анализ
Приведем пример зависимых тестов, которые, как мы считаем, писать не то что нежелательно, а даже вредно!
Допустим, у нас есть задача, когда нам надо протестировать цепочку продажа-возврат, и потребуется создать элементы справочников “Номенклатура” и “Контрагенты”.
Приведем несколько вариантов выполнения такого тестирования.
1. Все тестируется в одной базе
Т.е. берется некая база, в самом неправильном случае – какая-то шаблонная база с некоторыми данными (т.е. товары, контрагенты и прочее).
И пишется тест, который создает документ продажи, подставляет из этих баз существующие товары, контрагентов и прочее, проводит и закрывает документ. Потом создает и проводит документ возврата на основании этой реализации. В самом критическом случае делаем привязку к явным датам и номерам документов. И потом остальные тесты выполняются в этой же базе, все последовательно. Иногда еще в тесте прибегают к удалению созданных данных.
(Но тут надо сказать, что иногда такой подход оправдан, когда, например, мы тестируем переход с версии на версию, но обычно это проблема вендоров).
2. Тесты “Цепочка”
Это когда не используется шаблонная база, или используется, но в этой базе нет никаких данных, кроме выполненных настроек (установлены соответствующие настройки, включены функциональные опции, настроены виды учета и т.д.).
Далее тестом создается контрагент и товар, потом создается реализация, куда подтягиваются эти товары и контрагенты, и потом создается документ возврата.
Это самый опасный вид тестов, хотя, на первый взгляд, он кажется довольно таки логичным и правильным.
3. Тесты “Цепочка” + одна база
Это то, к чему внедренцы приходят из варианта 2, когда они через сотню тестов начинают обращаться к результатам первых тестов. То есть во втором варианте они пишут зависимые тесты цепочкой, когда есть задача проверить операцию Продажа+Возврат, и потом еще проверить операцию Поступление+Возврат. Но это два отдельных фича файла, и в начале каждого из них мы способом “накликивания” создаем товар отдельно под продажу, и отдельно под поступление.
А в третьем варианте в тесте используется одни и те же созданные номенклатура и контрагент, которые далее используются и для Поступлений.
Почему это опасно?
Пока у вас 100 тестов – это не страшно, и даже больше – это удобно. Вы запустили один файл, или несколько файлов последовательно, и получили хороший результат.
Но что происходит, когда тестов станет тысяча? Две тысячи? Вот об этом не рассказывает почти никто.
Вот где проблема. Нередко на конференциях появляются доклады, где спикер рассказывает, как они работают с базами в 10Тб, или как решают проблемы с тысячью одновременно работающих мобильных приложений. Но попробуйте загуглить фразы “оптимизация тестов”, “скорость автотестов” или что то в таком духе – и информации об этом почти не будет.
Итак, проблема – не думать об оптимизации заранее. Давайте подумаем, в чем же проблема тех трех кейсов, которые я привел выше. Но договоримся, что в нашем примере есть пара тысяч тестов.
- Первая проблема в том, что, используя шаблонную базу и проводя в ней тесты, мы должны эту базу актуализировать, и при актуализации (а обычно это обрезанная база прод), мы натыкаемся на то, что контрагент “ООО Ромашка” уже больше не с типом “Поставщик”, или что у нас изменились условия оплаты, или что в товарах появились некие обязательные реквизиты для заполнения. Таким образом, просто подготавливать шаблонную базу мы можем неделями, пока на ней отработают все кейсы и тесты (а тестов у нас тысячи), и в итоге, пока мы актуализировали тесты под новый шаблон, он уже устарел.
- Вторая проблема в том, что мы должны четко понимать, что именно мы тестируем. Приведу пример: если у меня тест упал на создании контрагента, то теперь у меня будут падать все остальные тесты, по сути – по цепочке. А с падением тестов есть проблема, потому что пока все тесты проходят – вы ждете 10 часов, а если упал один тест на создание товара, то у вас упадет почти вся тысяча тестов, и процесс тестирования тогда будет идти часов 20-30, пока вы его не остановите. И, казалось бы, то, что тест создания товара упал, – это же баг, давайте его пофиксим.
Согласен, однако, у вас должен был упасть еще и тест на проведение реализации, так как там возникла ошибка, а вы про это не узнали. Вы исправили проблему с товаром, и опять ждете 10 часов. Т.е. по сути, на каждом падении зависимых данных мы теряем день на то, чтобы сделать перезапуск тестов.
И самая основная проблема – масштабируемость. Т.е. так как тесты у нас написаны по цепочке, то мы не можем их никак разделить. И это приводит к тому, что мы можем запустить только один поток тестов.
Решение
Наша команда IRP Team была в точно такой же ситуации: у нас всего лишь 1500 тестов проходило в течение 18 часов. Это было настолько долго, что мы уже начали отчаиваться.
Но сейчас наши тесты проходят за 2 часа, а их количество стало более 2300.
Что же мы сделали и как мы пришли к этому? Надеемся, что наши советы подскажут вам, как выйти из этой ситуации, если вы в нее попали, или предупредить такую ситуацию в будущем.
Первое
Ситуация: есть тысяча тестов, они связаны, разделить их почти нереально, так как они были изначально написаны без понимания проблемы.
Мы выяснили, что больше всего времени в Vanessa Automation уходило на передачу контекста и отражение дерева фич. В новой VA – дерево уже не так часто используется, а используется редактор фич, но, “низом” это дерево никуда не делось, и вы можете на него переключиться.
Итак, первое наше решение было таким – мы во все фичи добавили теги, на уровне “Тег1”, “Тег2” и т.д. Да, вот просто взяли и все фичи разбили на 30 тегов, приблизительно в равных частях и написали скрипт, который запускал каждый тег в цикле.
Это дало нам прирост в 20-30%, т.е. просто за счет глюков 1С, когда она пытается генерировать большие деревья.
Мы потратили на это максимум пару часов. И получили прирост. И можно было бы на этом остановиться, прирост немаленький, но он не масштабируется. Т.е. когда у нас будет 3000 тестов, мы все равно упремся в 20+ часов прохождения тестов. И мы не сможем никак их ускорить. Ну, разве что запустить 1С на квантовом компьютере.
Второе
Мы начали строить независимые тесты. С нуля. И на перестраивание тестов у нас ушло 6-7 месяцев.
И мы для себя вывели следующий свод правил:
- Надо иметь возможность перезапустить тесты в той же базе, в которой они выполнялись. Т.е. никаких номеров документов в константах и т.д.
- Фича должна тестировать то, для чего она была создана. Т.е., если фича тестирует документ продажи, то товары, партнеры, контрагенты, цены – все это должно подгружаться из тестовых данных. Таким образом, у нас есть два отдельных независимых теста: один тестирует создание товара, а второй – документ продажи. Если у нас появится ошибка при открытии формы товара, то упадет только тест с товаром, а тест с продажей – отработает корректно.
- Никаких шаблонных баз, конфигурация должна быть в git, вместе с тестами. В самих тестах происходит загрузка данных. Я могу взять любую версию, любого разработчика, запустить ее на тестах, и мне не надо подсовывать никакие специальные шаблоны баз именно для этой версии или именно для этой задачи.
- Все тесты дробятся по тегам. Один тег не должен выполняться более чем 20 минут.
- Каждый тег сам под себя загружает только ему нужные тестовые данные и не ссылается на результаты выполнения других тестов.
Следуя этим правилам мы получили возможность масштабироваться, и, если мы сейчас выделим на контур не 10 ядер, а 30 ядер, – то у нас тесты будут идти 20-30 минут. Т.е. ровно столько, сколько идет самый длинные тег.
Итог
Начинать писать тесты нужно правильно. Иначе придет момент, когда потребуется их переписывать. И о том, как писать тесты правильно, информации нет почти нигде. Более того, нередко можно встретить и явно “вредные советы”, которые новички принимают за чистую монету.
Увы, но не существует QA инженеров для QA инженеров, и ваши ошибки покажет только время. И этот случай – всего лишь один из самых частых случаев. Более детально об этом рассказывается в нашем курсе по тестированию.