В своей недавней статье, опубликованной на TechBeacon, я утверждал, что тесты на уровне API копают золотую жилу скорости выполнения, стабильности (как стабильности запуска, так и стабильности требуемой поддержки) и тестового покрытия. Однако я забыл упомянуть, что именно сподвигло меня написать такую статью. Об этом я и расскажу.
На самом деле причина для такой темы у меня была только одна: я слишком часто вижу, как все идет наперекосяк, когда люди начинают писать автотесты. Сейчас я работаю с несколькими клиентами над двумя разными проектами, и их объединяет стремление к end-to-end тестам (зачастую при помощи инструментов вроде Selenium или Protractor), с проверками, которые выходят за рамки юнит-тестов.
Вот вам пример. Я работаю над проектом, в котором мы собираемся создать автоматические проверки для веб-магазина, который продает электронные сигареты и аксессуары для них в Соединенных Штатах Америки. В магазине несколько продуктовых категорий, возрастных групп покупателей (некоторые продукты можно приобретать, если вам больше 18, некоторые – если вам больше 21, некоторые продукты не учитывают возраст, и так далее). К тому же это США – 50 разных штатов, и в каждом свои правила и законодательство. Короче говоря, возможных комбинаций тут куча (я не считал, но точно в районе сотен). К тому же из-за жестких правил США, и штрафов за нарушение этих правил, автотесты должны включать абсолютно все возможные комбинации.
Звучит логично, но проблема в том, что заказчик предлагает написать автоматизированный end-to-end тест для каждой из возможных комбинаций. Следовательно, нам нужно создать заказ для каждой комбинации продуктовой группы, возрастной группы и штата, и каждый заказ включает заполнение трех или четырех разных форм и несколько переходов по страницам. Другими словами, такой тест будет медленно запускаться (счет пойдет на часы), и его будет тяжело поддерживать.
Продолжаю серию семинаров за чашкой чая. Пока попробовали три сорта и несколько видов вкусняшек. К сожалению, кому-то неудобен вторник, кому-то среда... По просьбе не попавших на семинары повторяю два последних.
По духу семинары близки к "байкам для оруженосца". Вероятно, часть семинаров впоследствии сами станут байками. Вероятно, и обратное. Что часть баек станет семинарами.
На следующем, вероятно, будет деловая игра в сбалансированную производственную цепочку. Потом... Даже не знаю.
Просьба регистрироваться заранее, т.к. количество мест в "Доме белого журавля" крайне ограничено. А менять площадку не хочу. Уж больно там атмосфера хорошая.
Я как прилежный ученик начал создавать архитектуру тестов используя Parameterized Controller => Module Controller => Simple Controller, последний из которых находится в отдельной группе Action Storage, тем самым получив единое хранилище действий. С течением времени, объем этого хранилища да и само число тестов выросло до неудобного и возник вопрос разнесения их как-то друг от друга. Так вот, можно ли как-то вынести это хранилище отдельно от тестов и обращаться к нему через Include controller? Или это делается как-то по другому?
Мне же в конечном результате, хотелось бы иметь несколько файлов с тестами, один файл с хранилищем и запуск нужного файла с тестом через командую строку.
И буду крайне признателен за любую информацию организации архитектуры для большое количества тестов, ибо быть может я изначально пошел не потому пути...
Верно ли утверждение, что руководить распределенной командой сложнее? И если верно, то существуют ли какие-то способы упростить жизнь менеджерам, управляющим такими командами?
Мы предлагаем вам посмотреть записи докладов с конференции SQA Days-20, в которых наши коллеги рассказали об особенностях работы в распределенной команде и путях преодоления трудностей, которые часто возникают при этом. Кроме того, докладчики подкрепили все сказанное собственными примерами.
Как управлять распределенной командой и сделать ее эффективной?,Анна Бурундукова, Омск, Россия
Синергия распределенной QA-команды. Преодолеваем трудности,Инна Смирнова, Санкт-Петербург, Россия