Круто. Особенно понравилось про каретку. Я в свое время не додумался до такого. Только вот вопрос, это вообще правильно идеалогически тестировать что-то специально сгенерированное? Есть гарантия что это будет 100% то что надо? Про микросервис тоже странно мне показалось, проблема кросплатформенности и кроссбаузерности безспорно решена, а по-факту это тестирование в одном браузере.
сорри может я невнимательно прочитал, но тут был описан процесс обновления новых эталонных скриншотов?
Стенгазета была реально хороша. Пойдешь чего-нибудь пожевать и узнаешь немного «легких» новостей. Формат новостей тоже идеальный. Онлайн я бы не стал конечно читать, но для кухни это самое то. Стыдно, но я даже не знал кто это делал, но спасибо вам. А те кто еще не делает стенгазету мотайте на ус, это реально крутая штука, как и синабоны по понедельникам. Благодаря таким мелочам я считаю что ИБТ — это лучшее место где я работал. В мелочи конечно не только это входит. Тематические граффити на стенах, цветочки в едальне… Я вообще всем советую идти работать к вам, но люди очкуют даже прийти на собеседование, считают что вы слишком крутые. Наверное они просто бездельники. Но если вы не бездельник, то вам нет оправданий почему вы еще не там.
Я тоже на одном проекте такую штуку реализовывал. Но коллеги потом сказали, что это не по богу и не надо так. В общем-то я по итогу с ними согласился. Ведь может что первый раз тест упал потому-что словил какой-то баг, а второй раз не словил. Мы тест помечаем как прошедший, а по факту от нас спрятался баг.
Хорошо сказано. Но в данном обсуждении хотелось бы выяснить наиболее эффективный способ их создания (функциональных авто-тестов), а то они нужны принять за факт.
Если я правильно уловил, то ваша мысль такая — «Если можно так подробно описать последовательность действий, то можно самому и все это запрограммировать»?
Нет, не может. Я плохо возможно мысль выразил. Изменения могут быть абсолютно любые, ну, скажем, есть в автотесте шаг экспорта продуктов. Там последовательно запускаются какие-то процессы по имени. Потом кто-то решил что название процесса не совсем отражает его суть и переименовал его. Тест упал потому-что процесс с таким именем не нашелся. С понятностью теста проблем нет, но как реагировать на это не понятно.
Все действительно так. На обновление тест-кейсов забивается повсеместно, особенно при наличии авто-тестов. Меняется функционал — на ходу меняется код тестов, а тестовые сценарии как лежали в стороне так и лежат. В итоге имеем безнадежно устаревшие артефакты в виде тест-кейсов и набор авто-тестов которые что-то тестируют, но непонятно что. Проблемы начинаются когда тест падет при попытке нажать на кнопку, которой нет. И вот сиди и думай то ли это баг, то ли ее и не должно быть.
Похоже при аутсорсном подходе дисциплина даже должна повыситься, у нее нет другого выхода. Например упали тесты из-за изменения какой-то функциональности (добавили шаг при покупке товара). Местный QA, назовем его тест дизайнер, видит это дело и оперативно правит тест-кейсы в соответствии с изменениями, потому что это единственная его задача, авралы на него не распространяются, поскольку в написании кода он не задействован. Далее изменения передаются удаленщикам и они делают свою часть работы. Профит. + 100% свежие и актуальные тест-кейсы и зеленые тесты. А важность актуальных тест-кейсов сложно переоценить, и и заказчику можно в случае чего показать и быстро ввести в курс дела новых сотрудников.
Поддерживаю. Мне тоже кажется странным аутсорсить юнит-тесты. Изменил код, измени сразу тесты, или в обратной последовательности. Может пока у удаленной команды руки дойдут до ваших тестов, они уже поменяются. Честно говоря, вообще не представляю себе такую модель.
Последний абзац понял только частично. Про измениния гуя могу сказать, что при правильном подходе к проектированию тестов это не проблема совершенно. Сейчас уже наверное и не встретишь нигде линейного написания, где тест написан, как последовательность низкоуровневых взаимодействий с гуем. (клик туда — клик сюда) А при отделении бизнес-логики от кода, все изменения от смены локаторов до изменения логики, рефакториться довольно безболезненно.
Флоу при функциональном тестировании франтэнда обычно такое: свежая функциональность тестируется вручную и после нескольких итераций правок, когда функционал готов и оттестирован на него пишется функциональный тест, который может запускаться по каким-то триггерам, по коммиту, по расписанию, вручную etc.
Это конечно так, но функциональные тесты-то нужны в любом случае. Пусть не не в CI, а хотя бы on demand. Нажал на кнопочку, посмотрел что все тесты зелененькие и успокоил немного нервы что ничего не сломалось. Уже неплохо я считаю. А когда из 100 тестов зелененьких 70% при том что весь функционал 100% рабочий, начинаешь задумываться зачем вообще нужны такие тесты. Т.е. основная идея в том, что в теории, если некая внешняя команда занимается исключительно написанием функциональных тестов в промышленных масштабах, то они уже наступили на все грабли и научились их избегать. А грабель на этом поприще хватает.
Мне это видилось таким образом: на входе тестеры получают человекопонятные тесткейсы (пример: открыть страницу такую-то, найти товар такой-то положить в корзину, перейти в корзину и убедиться что он там) с описанием пошаговых действий и ожидаемым результатом. Гоняют тесты у себя (на своих серверах, в облаках). Деплоить у себя проект это имхо слишком, просто доступ до него, возможно по впн-у и, если нужно, то доступ к БД или API. Заказчик теоретически может поднять Selenium Grid и на своей стороне, но это какая-то полумера что ли, зачем?
Допускаю что у кого-то процесс поддержки проходит гладко, но в моем опыте гладко не было никогда. Банально такой собирательный пример: был один энтузиаст что-то делал-делал, потом уволился, пришел другой и, посмотрев на доставшееся наследие, прослезился. Пришел другой с предложением переписать этот говнокод под какой-нибудь фреймвок типа thucydides, но в процессе получил более интересное предложение и перебрался в Москву. Как-то так.
а есть такие (без кулеров)? судя по яндекс.маркету 35 дБ это самый минимум на что можно расчитывать. конечно же важно как он шумит в простое, когда отключили электричество он еще и пищать начинает.
А расскажите про шум, пожалуйста. Я думал, что в неактивном режиме они полностью бесшумны, а когда возникла идея купить и я начал читать обзоры, то мне показалось, что ИБП может стать самой шумной штукой в моем компе. И, поскольку сплю в одной комнате с постоянно работающим компом, как-то побаиваюсь его покупать.
сорри может я невнимательно прочитал, но тут был описан процесс обновления новых эталонных скриншотов?
Похоже при аутсорсном подходе дисциплина даже должна повыситься, у нее нет другого выхода. Например упали тесты из-за изменения какой-то функциональности (добавили шаг при покупке товара). Местный QA, назовем его тест дизайнер, видит это дело и оперативно правит тест-кейсы в соответствии с изменениями, потому что это единственная его задача, авралы на него не распространяются, поскольку в написании кода он не задействован. Далее изменения передаются удаленщикам и они делают свою часть работы. Профит. + 100% свежие и актуальные тест-кейсы и зеленые тесты. А важность актуальных тест-кейсов сложно переоценить, и и заказчику можно в случае чего показать и быстро ввести в курс дела новых сотрудников.
Последний абзац понял только частично. Про измениния гуя могу сказать, что при правильном подходе к проектированию тестов это не проблема совершенно. Сейчас уже наверное и не встретишь нигде линейного написания, где тест написан, как последовательность низкоуровневых взаимодействий с гуем. (клик туда — клик сюда) А при отделении бизнес-логики от кода, все изменения от смены локаторов до изменения логики, рефакториться довольно безболезненно.
Флоу при функциональном тестировании франтэнда обычно такое: свежая функциональность тестируется вручную и после нескольких итераций правок, когда функционал готов и оттестирован на него пишется функциональный тест, который может запускаться по каким-то триггерам, по коммиту, по расписанию, вручную etc.
Допускаю что у кого-то процесс поддержки проходит гладко, но в моем опыте гладко не было никогда. Банально такой собирательный пример: был один энтузиаст что-то делал-делал, потом уволился, пришел другой и, посмотрев на доставшееся наследие, прослезился. Пришел другой с предложением переписать этот говнокод под какой-нибудь фреймвок типа thucydides, но в процессе получил более интересное предложение и перебрался в Москву. Как-то так.