В чем проблема? Есть трудовая книжка, работодатели ее видят. Думаете туда можно приписать что угодно? Не говорю про случаи мошенничества - если уж дипломы покупают, то и тут можно.
Есть же трудовая книжка для тех кто по ТК работает. Если есть подозрение на нарисованный опыт - можно не обращаться к такому ментору или попросить эту информацию (выписка из электронной трудовой или фотографии бумажной).
HR в данном случае, которые не могут сформулировать текст вакансии
Я не HR, нанимаю к себе в отдел, текст вакансии пишу сам (описание проекта, обязанности, требования к опыту), смотрю чтоб на hh было идентично. Делал так в разных компаниях. Где в этом процессе место для неправильной формулировки HR’ами? Для меня выглядит, что нанимающий менеджер максимально безразличен к качеству и скорости выхода сотрудника, если текст вакансии сформулирован плохо.
Сейчас у нас используется похожий стэк: GitlabCI, Python, Appium, Selenium, Allure, FastAPI, Кастомный UI - MaterializeCSS + Plotly.
Действительно удобно видеть всё в одном месте для быстрого понимания состояния сборок по результату прохождения автотестов, особенно когда тестируемое приложение прогоняется на многих платформах (пока у нас 7 платформ). Также есть возможность фильтрации - по платформам, типам сборок, наличию процессных проблем. Вот как выглядит это у нас
Из каждого результата можно провалиться в соответствующий on-demand Allure репорт
КЭта история пока еще не отражает ни качества, ни готовности к релизу, на пути к этому. Однако о дашборде, который в том числе использовался для определения готовности к релизу в другой компании, можно почитать здесь.
Также смотрим на Grafana для мониторинга элементов, составляющих инфраструктуру автотестирования/CI.
4) Тут работает негласное правило - если баг появился в результате выкатки новой фичи (неважно, в существующем ранее коде или в новом), то считаем, что это "Баг после релиза"
Понимаю, что этот показатель адаптирован под вас и вы по нему принимаете какие-то решения. Однако я думаю, что если все-таки учитывать в каком именно коде - в новом коде/новых фичах или в старом - появился баг, то можно прийти к полезным предположениям, может быть и выводам:
Ситуация 1: после релиза обнаружился баг в новом: - предположение 1: что-то пошло не по плану в процессе релиза; - предположение 2: что-то в тестировании фичей пошло не так;
Ситуация 2: после релиза обнаружился баг в старом: - предположение 1: некорректный/неполный регрессионный набор был запущен именно для этого релиза; - предположение 2: в целом регрессионный набор не соответствовал (не успели прогнать, не успели/забыли/не планировали покрывать кейсами старый код)
Думаю что понимание в каком коде появился баг - в старом или новом - важно и поможет выявить разные проблемы: поле для анализа здесь открывается не маленькое.
Метрики тестирования — это определенные показатели, которые дают нам возможность оценить качество программного обеспечения
Здесь нет ошибки? Может быть вы имеете ввиду "возможность определить качество тестирования", а не качество продукта?
Баги в старом коде. Эта метрика нужна для измерения общего качества и понимания, сколько багов мы обнаружили в старом коде.
Подскажите, что значит общее качество и каким образом можно понять степень качественности опираясь на количество багов.
Баги до релиза. Их находит тестировщик. Благодаря этой метрике мы понимаем, сколько дефектов обнаружено в новой фиче до того, как мы ее зарелизили
Баги до релиза могут быть не только в новых фичах, но и там, где новые фичи случайно что-то сломали. Вы такое не учитываете в этой метрике или вообще не учитываете?
Баги после релиза — это баги, найденные тестировщиками, менеджерами, другими сотрудниками или пользователями после выпуска фичи. Собираются автоматически из Jira. Учитываются задачи с типом “Баг” и меткой “баг_в_новом_коде”.
Аналогично - баги могут оказаться и в старом коде, вы их учитываете здесь?
Пожалуйста. Еще интересовался получением MS в Computer Science - https://institute.constructor.org/programs/quantum-software-engineering-and-computer-science - но пока отложил. Из интересного там:
можно обучаться очно в Швейцарии, хотя это не жесткое требование - можно договориться и большую часть времени проходить в онлайне, приезжая несколько раз на сдачу сессий.
обучение платное - 20k CHF в год за обучение + 2к CHF административный платеж за все время обучения; в случае интересного для профессора предложения по магистерской, можно заплатить только 2к, остальное покроют стипендией. Заинтересовать можно попробовать темами, связанными с QA, т.к. профессор сильно связан с этой областью.
консультируют по процессу получения визы и содействуют; говорят - дают пока еще визу для обучения гражданам РФ.
Здесь уже будет нужно и документы о текущем образовании и мотивационное письмо для поступления.
Уже провал.
Это вообще не уместно. CI без разницы какой инструмент использовался для написания тестов.
Смешно. Если у элемента есть id или текст, то и в Appium будут простые локаторы.
Если Appium’у требуется СЛОЖНЫЙ xpath, значит у элемента нет ни id, ни текста, ни других уникальных свойств. В этом случае и maestro не поможет.
Не проблема. Ни разу при нормальном подходе тесты на ожидании элемента не упадут.
Вот это особенно забавно.
В чем проблема? Есть трудовая книжка, работодатели ее видят. Думаете туда можно приписать что угодно? Не говорю про случаи мошенничества - если уж дипломы покупают, то и тут можно.
Есть же трудовая книжка для тех кто по ТК работает. Если есть подозрение на нарисованный опыт - можно не обращаться к такому ментору или попросить эту информацию (выписка из электронной трудовой или фотографии бумажной).
Согласен, хотелось бы чтобы менторство если и было, то более честное - чтобы туда не лезли все, кому не лень
Спасибо за внимательность, поправлю
Сильно.
Всякий негр, амотный, автор, имеет, желание написать, на хабр.
Я не HR, нанимаю к себе в отдел, текст вакансии пишу сам (описание проекта, обязанности, требования к опыту), смотрю чтоб на hh было идентично. Делал так в разных компаниях. Где в этом процессе место для неправильной формулировки HR’ами? Для меня выглядит, что нанимающий менеджер максимально безразличен к качеству и скорости выхода сотрудника, если текст вакансии сформулирован плохо.
Приятно читать о таком подходе.
Сейчас у нас используется похожий стэк: GitlabCI, Python, Appium, Selenium, Allure, FastAPI, Кастомный UI - MaterializeCSS + Plotly.
Действительно удобно видеть всё в одном месте для быстрого понимания состояния сборок по результату прохождения автотестов, особенно когда тестируемое приложение прогоняется на многих платформах (пока у нас 7 платформ). Также есть возможность фильтрации - по платформам, типам сборок, наличию процессных проблем. Вот как выглядит это у нас
КЭта история пока еще не отражает ни качества, ни готовности к релизу, на пути к этому. Однако о дашборде, который в том числе использовался для определения готовности к релизу в другой компании, можно почитать здесь.
Также смотрим на Grafana для мониторинга элементов, составляющих инфраструктуру автотестирования/CI.
Мы тут делаем кеши appium/nodejspython пакетов в локальной сети, свою миниферму, а вы до сих пор расчитываете на >забугорный< >облачный< сервис?
Статью надо было назвать - "как я нашел первую работу в IT в 2011 году". Польза от такой статьи была бы понятна сразу по заголовку.
На мой взгляд, очень удачное сочетание статьи и рекламы. Было интересно и приятно читать
Повышенная концентрация «Я». Первые два мобильных экрана - 8 раз
Не удивительно
Давайте заверифаим баг :)
Необычное ощущение - пролистал статью про дашборды, ни одного дашборда не увидел - монотонный текст
А может лучше новых статей?
Не поздно ли верстать сайты в 9 лет
Как программировать в 10 лет если не хочется
Как программировать в 11 лет если немного начал хотеть но не знаю на чем
Как программировать в 12 лет, если выгорел
Мне было бы интересно
Понимаю, что этот показатель адаптирован под вас и вы по нему принимаете какие-то решения. Однако я думаю, что если все-таки учитывать в каком именно коде - в новом коде/новых фичах или в старом - появился баг, то можно прийти к полезным предположениям, может быть и выводам:
Ситуация 1: после релиза обнаружился баг в новом:
- предположение 1: что-то пошло не по плану в процессе релиза;
- предположение 2: что-то в тестировании фичей пошло не так;
Ситуация 2: после релиза обнаружился баг в старом:
- предположение 1: некорректный/неполный регрессионный набор был запущен именно для этого релиза;
- предположение 2: в целом регрессионный набор не соответствовал (не успели прогнать, не успели/забыли/не планировали покрывать кейсами старый код)
Думаю что понимание в каком коде появился баг - в старом или новом - важно и поможет выявить разные проблемы: поле для анализа здесь открывается не маленькое.
Здесь нет ошибки? Может быть вы имеете ввиду "возможность определить качество тестирования", а не качество продукта?
Подскажите, что значит общее качество и каким образом можно понять степень качественности опираясь на количество багов.
Баги до релиза могут быть не только в новых фичах, но и там, где новые фичи случайно что-то сломали. Вы такое не учитываете в этой метрике или вообще не учитываете?
Аналогично - баги могут оказаться и в старом коде, вы их учитываете здесь?
Именно дашборд качества не был необходимостью, а вот приоритизация требований и контроль за тем, какие задачи берутся в работу, были нужны.
Пожалуйста. Еще интересовался получением MS в Computer Science - https://institute.constructor.org/programs/quantum-software-engineering-and-computer-science - но пока отложил. Из интересного там:
можно обучаться очно в Швейцарии, хотя это не жесткое требование - можно договориться и большую часть времени проходить в онлайне, приезжая несколько раз на сдачу сессий.
обучение платное - 20k CHF в год за обучение + 2к CHF административный платеж за все время обучения; в случае интересного для профессора предложения по магистерской, можно заплатить только 2к, остальное покроют стипендией. Заинтересовать можно попробовать темами, связанными с QA, т.к. профессор сильно связан с этой областью.
консультируют по процессу получения визы и содействуют; говорят - дают пока еще визу для обучения гражданам РФ.
Здесь уже будет нужно и документы о текущем образовании и мотивационное письмо для поступления.