Артем Ерошенко eroshenkoam

ага

1. Скорее «это не покрыто» или «это недопокрыто». Например частный кейс — проверка под авторизацией или с конкретными тестовыми данным.
2. Еще пытаемся использовать когда баг пропущен и нужно посмотреть «тестировалось это или нет»

В самом начале статьи я говорю, что метрика формального покрытия не работает в большинстве случаев. И здесь наши мысли сходятся.

Дальше я сообщаю, что при большом количестве тестов и участников команды встает вопрос о том, какие тесты есть, а каких нет.

Имея на входе эти два пункта я делаю следующий вывод: покрытие само по себе интересно, но текущая его реализация (через линии кода) не работает.

Следом я предлагаю сдалеать следующий трюк: за основу «покрытия» беру более высокоуровневую составляющую продукта, а не строку кода. Например:
1. вызовы Rest API
2. конкретный элемент на странице
3. твой вариант

И в конце я показываю, как могло бы выглядеть покрытие в этом случае.

И теперь вопрос, с чем ты споришь?
Если ты считаешь, что покрытие по строкам не работает, я с тобой согласен.
Если тебе не важно покрытие, то не делай так. Возможно у нас отличаются условия.
Если тебе не нравится конкретная реализация, то расскажи как бы ты это сделал.

В данном случае менеджер — это роль. Можно подразумевать руководителя тестирования, менеджера продукта и всех тех, кому интересно состояние продукта с точки зрения тестирования.
Наличие этой информации помогает им понимать какая часть продукта тестируется и/или не тестируется, точнее составлять планы на расширение покрыти и расставлять приоритеты.
Эти инструменты просто визуализируют то, что проверяется в тестах. Ровно как джира визуализирует то, что будет разрабатываться в ближайшее время.

Мы использовали обычный Listener, который есть в каждом фреймворке. Во время действия с элементом мы берем полный селектор этого элемента и страницу, на которой было выполнено действие.

Я вставил корректную ссылку.

Хороший вопрос.
Прямого упоминания слова «DevOps» ни в одной лекции вы не найдете.

Представим DevOps как пересечение разработки, тестирования и эксплуатации, прям как в wiki, да. Задача DevOps — сделать процесс поставки ПО состоящим из понятных частей, связанных ясным образом.
В лекциях мы рассказали об инструментах, с помощью которых можно эту задачу решить. А именно, автоматизировать процесс поставки ПО от коммита до продакшена.
Конкретный конвейер участники школы изобретают сейчас в рамках практики.

Практика закончится в конце января. Примерно в это же время появится пост, в котором я расскажу детали.

Немного промахнулся — дал ниже ссылку на Диск.

Для того, чтобы скачать видео лекция целиком, можно сходить на Яндекс.Диск:
yadi.sk/d/CVmVoRYBdPRpn

То ли это был хабра-эффект, то ли метеорит упал на датацентр, в котором стояла моя железяка, но ci.qatools.ru временно не работает.
Вы всегда сможете построить отчет из исходников.
Если github.com будет работать, конечно)