Я помню, когда искал коды для VC, обнаружил, что половина сайтов скопировала друг у друга чей-то кривой перевод/фантазию со строчкой "COMEFLYWITHME — вызов мух" :)
Я не говорю, что это универсальное правило, просто шпаргалка для тех, кто [только начинает и] не знает, как лучше сформулировать. Исключения можно придумать для любого формата, у всех разные продукты и процессы. Что я имел в виду на примере вашего примера: "[Что] Кнопка отправки неактивна [Где] на странице комментариев [Когда]после обновления страницы"
Мне запомнились слова тимлида на этот счёт: не переживай, ты не один, мы втроём допустили этот баг [автор, ревьювер и тестировщик, к которым могут добавиться и другие участники процесса] :)
Нас вроде в прошлом году пугали, что какой-то китайский стартап начнет в видео заменять некоторые объекты на рекламируемые продукты, но что-то никого не видно в футболках с логотипом букмекеров.
Оффтоп: жду голосовые модели, чтобы "мгновенно" получать переводы роликов/сериалов/игр... эх, мечта!
У нас фреймворк без BDD, делаем через более-менее стандартный PageObject и иже с ними.
Посмотрел статистику за прошлую неделю: тесты запускались 350+ раз в день, поэтому кажется нецелесообразным подход вместо одного проекта запускать два, т.к. мы стремимся к ускорению прогона тестов.
Во-вторых, начать использовать = начать дублировать всю обвязку и скрины, это тоже время.
В-третьих, остается открытым вопрос с гридом: чистый селеноид не позволяет запускать на гриде ни cypress, ни playwright, а moon, который позволяет, под наши потребности будет стоить $60k+ в год.
Ну и в-четвертых остается не отвеченным вопрос: все эти трудо- и финансовые затраты — чтобы что? :) Нас в целом и так всё устраивает.
~2000 классов — это только с тестами, которые мы начали писать еще 2010-м, так что не было возможности "перейти на современный фреймворк" :)
headless не используем, т.к. контейнеры селеноида запускают хром в Xvfb (X virtual framebuffer), насколько я помню, выигрыш в ресурсах по сравнению с ним у хэдлесса минимальный, а спецэффекты присутствуют, поэтому больше потеряем на разборе проблем, чем выиграем от экономии железа.
Обычно проблем нет или они требуют минимальных правок, поэтому пока нет смысла тратить "человеко-год" на переезд проекта, где одних только тестовых классов почти 2000 :)
Кроме того, насколько я помню, для playwright чистого селеноида недостаточно и нужен moon, а он платный (и нам бы понадобилась максимальная лицензия).
То есть у вас есть список возможных результатов работы модели, и вы для них прописываете вручную список (из 150+?) параметров и "алгоритмы" их вариативности, а потом (пока еще) глазами проверяете, что актуальные результаты сошлись с ожидаемыми?
У нас свой java-фреймворк (поверх Selenoid + TestNG), в котором мы запускаем тесты программно (programmatically), т.е. не через мавен и плагины, соответственно и очередь на запуск формируем сами, и управляем ей на свое усмотрение. (возможно, про это в скором будущем будет статья, есть еще старый доклад на testconf, от него сохранилась только презентация, но она довольно информативная).
Интересно, как раз обсуждали с вашим коллегой в предыдущем посте проблему длинных хвостов, но у нас я пока решил ее другим путем: беру статистику продолжительности тестов, все тесты дольше минуты перемещаю в рандомное место в первой 1/N-й части очереди, а при ретрае — вместо конца — тоже в 1/N-ю от оставшейся очереди (у нас свой раннер, так что можем управлять очередью, как хотим), в итоге даже длинные выбросы по времени равномерно замазываются кучей коротких тестов (в нашем случае немедленный ретрай мы не хотим, чтобы не ддосить, вероятно, и без того нагруженный сейчас сервис, из-за долгого ответа/ошибки которого тест, скорее всего, и упал).
Грустная новость в том, что это работает — метрики в целом растут. Штука в том, что и баннеры на весь экран с ложной кнопкой закрытия (которая в первый раз делает вид, что ты промахнулся), и другие около-дарк-паттерны тоже работают, и у каждого свой моральный лимит того, на что они готовы пойти, но, кажется, часто здравый смысл перевешивает "жадность менеджеров" несколько позже, чем следовало бы.
Мой знакомый в шутку называет это тёмной стороной маркетинга: все метрики в молниях, но и продукт начинает выглядеть как лицо Палпатина...
наверное, имелось в виду форматирование по ctrl+alt+L (или ctrl+shift+alt+L — вызов диалога форматирования)?
А так я коллегам постоянно рекламирую такие хоткеи: - Ctrl+Shift+F — искать по всем файлам (кстати, если выделена директория в списке файлов проекта, то поиск будет ограничен по ней) - Ctrl+Shift+N — перейти к файлу (как если нажать T на гитхабе) - Shift+F6[+F6] — переименовать что угодно - Ctrl+E — список последних файлов (можно, как и много где еще, начать набирать текст, чтобы найти нужный пункт) - Ctrl+Ctrl — выполнить команду (`mvn validate`, 'pip list', 'git log', etc) - и король всех хоткеев — Ctrl+Shift+A — поиск любого действия (по сути любого пункта любого меню)
попробуйте заиспользовать в вашем проекте эту идею
Практически сразу же, как прочитал, заметно помогло, спасибо! :)
У нас пока политика "если тест есть для сервиса, то он запускается", так что я все-таки пробую схему с уплощением хвоста, в целом цифры по сравнению с рандомным распределением очереди получаются приятные (экономия чуть больше 10% времени).
1 видел, но для нас не актуально, 2 у нас, вероятно, уже есть, если это то, о чем я думаю (но я подписался и жду)).
1) может, имеется в виду, что нет защиты от повторного получения вредоносного сообщения?
3) может, инфа о бэкдоре ушла не в те руки, его пофиксили и добавили новый? :)
Я помню, когда искал коды для VC, обнаружил, что половина сайтов скопировала друг у друга чей-то кривой перевод/фантазию со строчкой "COMEFLYWITHME — вызов мух" :)
Я не говорю, что это универсальное правило, просто шпаргалка для тех, кто [только начинает и] не знает, как лучше сформулировать.
Исключения можно придумать для любого формата, у всех разные продукты и процессы.
Что я имел в виду на примере вашего примера: "[Что] Кнопка отправки неактивна [Где] на странице комментариев [Когда]после обновления страницы"
Мне запомнились слова тимлида на этот счёт: не переживай, ты не один, мы втроём допустили этот баг [автор, ревьювер и тестировщик, к которым могут добавиться и другие участники процесса] :)
Если уж на то пошло, п.1 относится и к остальным пунктам комментария: у кого-то может не быть ни спринтов, ни менеджера, итд :)
По самой статье:
про summary — если нет других указаний, мне нравится формат описания "что где когда"
про связи: неплохо было бы рассказать, как их добавлять и какие бывают
А причем здесь тестирование (хабы, тэги), кроме того, что вы тестировщик?
С учётом средней ЗП в Гугле в районе 150к/год, мог бы уволенных целых полтора месяца содержать на свои выплаты, жмот! /s
Нас вроде в прошлом году пугали, что какой-то китайский стартап начнет в видео заменять некоторые объекты на рекламируемые продукты, но что-то никого не видно в футболках с логотипом букмекеров.
Оффтоп: жду голосовые модели, чтобы "мгновенно" получать переводы роликов/сериалов/игр... эх, мечта!
То есть вы сделали фикстуры (инструмент для подготовки окружения в части создания предусловий для тестов)? Круто, но нейминг слегка сбивает с толку)
(мы сейчас пытаемся двигаться ещё дальше, в сторону "всё, что не тестирует непосредственно фронт, не тестировать в е2е")
Я не понял, что именно непонятно :)
У нас фреймворк без BDD, делаем через более-менее стандартный PageObject и иже с ними.
Посмотрел статистику за прошлую неделю: тесты запускались 350+ раз в день, поэтому кажется нецелесообразным подход вместо одного проекта запускать два, т.к. мы стремимся к ускорению прогона тестов.
Во-вторых, начать использовать = начать дублировать всю обвязку и скрины, это тоже время.
В-третьих, остается открытым вопрос с гридом: чистый селеноид не позволяет запускать на гриде ни cypress, ни playwright, а moon, который позволяет, под наши потребности будет стоить $60k+ в год.
Ну и в-четвертых остается не отвеченным вопрос: все эти трудо- и финансовые затраты — чтобы что? :) Нас в целом и так всё устраивает.
~2000 классов — это только с тестами, которые мы начали писать еще 2010-м, так что не было возможности "перейти на современный фреймворк" :)
headless не используем, т.к. контейнеры селеноида запускают хром в Xvfb (X virtual framebuffer), насколько я помню, выигрыш в ресурсах по сравнению с ним у хэдлесса минимальный, а спецэффекты присутствуют, поэтому больше потеряем на разборе проблем, чем выиграем от экономии железа.
Обычно проблем нет или они требуют минимальных правок, поэтому пока нет смысла тратить "человеко-год" на переезд проекта, где одних только тестовых классов почти 2000 :)
Кроме того, насколько я помню, для playwright чистого селеноида недостаточно и нужен moon, а он платный (и нам бы понадобилась максимальная лицензия).
То есть у вас есть список возможных результатов работы модели, и вы для них прописываете вручную список (из 150+?) параметров и "алгоритмы" их вариативности, а потом (пока еще) глазами проверяете, что актуальные результаты сошлись с ожидаемыми?
У нас свой java-фреймворк (поверх Selenoid + TestNG), в котором мы запускаем тесты программно (programmatically), т.е. не через мавен и плагины, соответственно и очередь на запуск формируем сами, и управляем ей на свое усмотрение.
(возможно, про это в скором будущем будет статья, есть еще старый доклад на testconf, от него сохранилась только презентация, но она довольно информативная).
Интересно, как раз обсуждали с вашим коллегой в предыдущем посте проблему длинных хвостов, но у нас я пока решил ее другим путем: беру статистику продолжительности тестов, все тесты дольше минуты перемещаю в рандомное место в первой 1/N-й части очереди, а при ретрае — вместо конца — тоже в 1/N-ю от оставшейся очереди (у нас свой раннер, так что можем управлять очередью, как хотим), в итоге даже длинные выбросы по времени равномерно замазываются кучей коротких тестов (в нашем случае немедленный ретрай мы не хотим, чтобы не ддосить, вероятно, и без того нагруженный сейчас сервис, из-за долгого ответа/ошибки которого тест, скорее всего, и упал).
Грустная новость в том, что это работает — метрики в целом растут. Штука в том, что и баннеры на весь экран с ложной кнопкой закрытия (которая в первый раз делает вид, что ты промахнулся), и другие около-дарк-паттерны тоже работают, и у каждого свой моральный лимит того, на что они готовы пойти, но, кажется, часто здравый смысл перевешивает "жадность менеджеров" несколько позже, чем следовало бы.
Мой знакомый в шутку называет это тёмной стороной маркетинга: все метрики в молниях, но и продукт начинает выглядеть как лицо Палпатина...
UPD: виноват, упустил пункт про А4. Хорошо читается книга 17*23 см. Глянул А4 — видно все четко, но мелковато, с хорошим зрением читать можно.
наверное, имелось в виду форматирование по ctrl+alt+L (или ctrl+shift+alt+L — вызов диалога форматирования)?
А так я коллегам постоянно рекламирую такие хоткеи:
- Ctrl+Shift+F — искать по всем файлам (кстати, если выделена директория в списке файлов проекта, то поиск будет ограничен по ней)
- Ctrl+Shift+N — перейти к файлу (как если нажать T на гитхабе)
- Shift+F6[+F6] — переименовать что угодно
- Ctrl+E — список последних файлов (можно, как и много где еще, начать набирать текст, чтобы найти нужный пункт)
- Ctrl+Ctrl — выполнить команду (`mvn validate`, 'pip list', 'git log', etc)
- и король всех хоткеев — Ctrl+Shift+A — поиск любого действия (по сути любого пункта любого меню)
Читаю pdf с 6" киндла (1072x1448, 300 ppi) — всё видно хорошо.
Практически сразу же, как прочитал, заметно помогло, спасибо! :)
У нас пока политика "если тест есть для сервиса, то он запускается", так что я все-таки пробую схему с уплощением хвоста, в целом цифры по сравнению с рандомным распределением очереди получаются приятные (экономия чуть больше 10% времени).
1 видел, но для нас не актуально, 2 у нас, вероятно, уже есть, если это то, о чем я думаю (но я подписался и жду)).
Спасибо вам за развернутые ответы!