Все зависит от базы и направления. Во фронте люди растут быстрее. На бэкенде со сложной архитектурой и высокими нагрузками 5 лет действительно может быть недостаточно.
Если вкратце, то в автотестах есть метод, который логирует каждый вызов API — URL, параметры и теги, с которыми был запущен тест, совершивший этот вызов. После выполнения тестов вручную (или силами CI) запускается утилита для анализа лога.
Утилите указываются все теги, для которых рассчитывается покрытие (например, smoke), а она выбирает из файла записи, соответствующие указанным тэгам.
Затем она идёт по нужному адресу в Swagger и вытягивает оттуда информацию об «энд-поинтах», методах, и параметрах — ну и сопоставляет эти данные, выводя статистику относительно всех эндпоинтов и методов.
В файле лога большинство вызовов содержат какие-то идентификаторы и на самом деле их сложно сопоставить с тем, что лежит в Swagger. Поэтому в утилиту заложена хитрая логика, которая умеет выделять идентификаторы из URL и делать на их основе пометки, впоследствии используемые при сопоставлении.
Помимо развёрнутой информации (что покрыто, что не покрыто, что покрыто частично — когда использованы не все параметры) она генерит ещё и svg-плашку, которая выводится в описании проекта gitlab.
При написании тестов удобно пользоваться и PyCharm, и Atom с соответствующими плагинами. Некоторые не гнушаются даже стандартным Блокнотом. Дебаг в общепринятом смысле тут недоступен — да. Но как мы уже писали в статье, у робота прекрасный лог и его вполне достаточно для тех нужд, для которых обычно используется дебаг.
Да, для интеграции тег соответствует Jira Issue ID. Кроме того, Robot Framework надо запускать в ключиком, чтобы из лога можно было напрямую перейти в Jira.
Допустим у Вашего проекта в Jira префикс RF, то есть баг у Вас с идентификатором RF-123456. Тогда Вы привязываете к тесту тэг RF-123456, а в строке запуска робота пишете
Мне знакома позиция: «Никто никому ничего не должен. Работает — не трогай!»
Но как тогда делать рабочий процесс лучше? Откуда менеджмент узнает о проблемах Ларри, если Ларри не укажет на них и не подскажет возможный вариант решения?
Мне бы на месте Ларри было стыдно, что я не сделал все, что мог — ни для себя, ни для коллег, которые так же мучаются в тех же самых рутинных процессах…
Софт-скиллы — это о других вопросах. Здесь мы говорим о подходах к работе.
На собеседовании мы договариваемся про 3 часа — для кандидата это не должно быть новостью. После начала работы он может договориться о какой-то большей гибкости с конкретной командой, в зависимjсти от расписания митингов и т.п. Однако мы не можем этого гарантировать в общем случае.
У каждого кандидата мы запрашиваем контакты людей с прошлых мест работы, которые могли бы дать рекомендации. Но чаще обратная связь положительная. Мы предполагаем, что кандидаты стараются давать контакты лояльных «сослуживцев» (иногда даже друзей). Откровенно говоря, мы даже не можем законно проверить, является ли этот человек, например руководителем. Допустим, кандидат дал телефон своего друга-коллеги, который во время звонка представится его начальником. Естественно, он даст о нем наилучший отзыв. А на расследования у нас нет ни времени, ни ресурсов. Для бизнеса проще и дешевле выработать собственную процедуру оценки кандидатов.
Вообще опасно полагаться исключительно на субъективное мнение в коротком разговоре, да еще и в удаленном режиме. Все эти лайфхаки по примеру сериала «Lie to me» научной базы под собой не имеют. Очень легко промахнуться из-за чрезмерной веры в собственную проницательность.
Напрямую — нет. Но мы ориентируемся на миддлов и сениоров, а опыт, который позволяет перейти на эти уровни, формируется не за один год. Поэтому к нам приходят в основном сотрудники старше определенного возраста. Но есть и исключения.
Однако студентов у нас нет по понятным причинам.
Забавная история.
Кандидаты, с которыми мы общаемся, зачастую используют 2 монитора (как и большинство действующих сотрудников компании). Так что у нас фокус с наблюдением за глазами изначально не работает.
Утилите указываются все теги, для которых рассчитывается покрытие (например, smoke), а она выбирает из файла записи, соответствующие указанным тэгам.
Затем она идёт по нужному адресу в Swagger и вытягивает оттуда информацию об «энд-поинтах», методах, и параметрах — ну и сопоставляет эти данные, выводя статистику относительно всех эндпоинтов и методов.
В файле лога большинство вызовов содержат какие-то идентификаторы и на самом деле их сложно сопоставить с тем, что лежит в Swagger. Поэтому в утилиту заложена хитрая логика, которая умеет выделять идентификаторы из URL и делать на их основе пометки, впоследствии используемые при сопоставлении.
Помимо развёрнутой информации (что покрыто, что не покрыто, что покрыто частично — когда использованы не все параметры) она генерит ещё и svg-плашку, которая выводится в описании проекта gitlab.
Допустим у Вашего проекта в Jira префикс RF, то есть баг у Вас с идентификатором RF-123456. Тогда Вы привязываете к тесту тэг RF-123456, а в строке запуска робота пишете
tagstatlink RF-*:https://ваш-хост-с-jira/browse/RF-%1:Open_in_Jira
и все тэги, начинающиеся с RF- получат ссылки в Jira (из моего любимого лога).
Но как тогда делать рабочий процесс лучше? Откуда менеджмент узнает о проблемах Ларри, если Ларри не укажет на них и не подскажет возможный вариант решения?
Мне бы на месте Ларри было стыдно, что я не сделал все, что мог — ни для себя, ни для коллег, которые так же мучаются в тех же самых рутинных процессах…
На собеседовании мы договариваемся про 3 часа — для кандидата это не должно быть новостью. После начала работы он может договориться о какой-то большей гибкости с конкретной командой, в зависимjсти от расписания митингов и т.п. Однако мы не можем этого гарантировать в общем случае.
Однако студентов у нас нет по понятным причинам.
Кандидаты, с которыми мы общаемся, зачастую используют 2 монитора (как и большинство действующих сотрудников компании). Так что у нас фокус с наблюдением за глазами изначально не работает.