Сколько из этих багов можно было предотвратить на этапе тестирования? А разработки? А аналитики?
Сложно придумать баг который нельзя было бы предотвратить. Крайнего можно найти всегда.
Через 6 месяцев легко можно посмотреть, приведут ли изменения в процессах к какому-то результату, считать нужные цифры ребята научились.
Через десять лет или я помру, или ишак. За 6 месяцев в команде любого масштаба может накопиться столько изменений, что любое изменение в такой метрике можно будет объяснить чем угодно. Ушел/пришел ведуший разраб, новые тестировщики; сменился стек, продукт, вектор разработки; зима, всем холодно, лето, всем жарко.
В малой команде будет анализироваться выборка из ~12 релизов, которые все были разные по всем измеримым и неизмеримым параметрам, в большой компании метрика будет измняться на очень значительные +-1.5%, потому что все команды разные по всем измеримым и т.д.
Оказалось, что страницу логина всё-таки задели.
Очень сильно надеюсь, что это синтетический пример. Это не проблема "стабильности" автотестов, это проблема "зачем тестировать вручную если мы писали автотесты". Уж простите, минимальный смок могут позволить себе все.
Вопрос в том, насколько? Как давно они стали нестабильными? Какой процент нестабильных тестов в вашей сборке?
Без ответа на эти вопросы работать с нестабильностями невозможно. А работать с ними нужно, иначе ваши тесты бесполезны.
Сегодня я увидел оповещение о том, что один из моих регулярных скриптов упал. Скрипт выгружает картинки, обрезает их, заливает в хранилище. Скрипт упал из-за того, что съел картинку, в tiff-теге был NaN, а библиотека для работы с изображениями, которую я использовал, не ожидала NaN в метках. Я исправил скрипт таким образом, чтобы он работал с этим случаем, и перезапустил его.
Для этого мне не потребовалось подсчитать, сколько раз за последние N дней этот скрипт падал, кто тот негодяй, что создал картинку с NaN в теге, какой процент моих скриптов может бросить ошибку от неожиданного ввода. Мне потребовалось только открыть текстовый редактор и исправить скрипт.
Я согласен с тем, что если программа не работает, то тот, кто ответственен за ее поддержку, зря ест свой хлеб. Но сомневаюсь в том, что такая метрика дармоедов может быть полезна. Один нерабочий тест может привести к пропуску ошибки так же, как и сотня нерабочих тестов.
По моему мнению, статья не убеждает, что ошибка - это не единичный независимый случай, который должен быть азобран индивидуально и стать толчком (в совокупности с подобными случаями) для выработки практики, которая позолит избежать схожих случаев. И не предлагает никаких подходов, которые помогли бы установить закономерности в цикле разработки, за исключением фрагмента:
часть этих багов совсем не критичные, их необязательно править asap, отвлекая людей от текущей работы;
что предполагало индивидуальный разбор каждой ошибки.
Автор, прошу подумать над тем, чтобы рассказать о вашем опыте внедрения метрик тестирования с упором на то, как это помогло найти закономерности и изменить рабочие практики. И в том числе повлиять на глобальные метрики, которые вы описали в этой статье. Потому что ваша статья рассказывает о том "что?", но не говорит "зачем?".
Я правильно понял что единственная претензия к джаве это то, что некое комьюнити в большинстве своем перешло на котлин?
Они скорее всего до этого на скалу переходили все повально.
Сомневаюсь что джава (даже якобы мертвая) намного менее поддерживаемая чем избраный автором Free Pascal.
Проекты на джаве прекрасно собираются в андроид студии, а целевой уровень апи как был, так и остался (скорее всего) девятнадцатым - киткат. То есть спокойно можно писать приложения так же, как это делали еще до появления котлина.
Другое дело что писать на джаве может просто не нравиться, и товарищ автор искал повод от нее отказаться. Но если цель найти такой язык, на котором можно написать кучу логики и адаптировать под тучу платформ - кажется что лучше и мощнее чем джава ничего найти не получится.
Вот что действительно умерло - так это джава апплеты, так что для браузера писать gui на джаве уже не получится. А так бы был полный фарш.
Сложно придумать баг который нельзя было бы предотвратить. Крайнего можно найти всегда.
Через десять лет или я помру, или ишак. За 6 месяцев в команде любого масштаба может накопиться столько изменений, что любое изменение в такой метрике можно будет объяснить чем угодно. Ушел/пришел ведуший разраб, новые тестировщики; сменился стек, продукт, вектор разработки; зима, всем холодно, лето, всем жарко.
В малой команде будет анализироваться выборка из ~12 релизов, которые все были разные по всем измеримым и неизмеримым параметрам, в большой компании метрика будет измняться на очень значительные +-1.5%, потому что все команды разные по всем измеримым и т.д.
Очень сильно надеюсь, что это синтетический пример. Это не проблема "стабильности" автотестов, это проблема "зачем тестировать вручную если мы писали автотесты". Уж простите, минимальный смок могут позволить себе все.
Сегодня я увидел оповещение о том, что один из моих регулярных скриптов упал. Скрипт выгружает картинки, обрезает их, заливает в хранилище. Скрипт упал из-за того, что съел картинку, в tiff-теге был NaN, а библиотека для работы с изображениями, которую я использовал, не ожидала NaN в метках. Я исправил скрипт таким образом, чтобы он работал с этим случаем, и перезапустил его.
Для этого мне не потребовалось подсчитать, сколько раз за последние N дней этот скрипт падал, кто тот негодяй, что создал картинку с NaN в теге, какой процент моих скриптов может бросить ошибку от неожиданного ввода. Мне потребовалось только открыть текстовый редактор и исправить скрипт.
Я согласен с тем, что если программа не работает, то тот, кто ответственен за ее поддержку, зря ест свой хлеб. Но сомневаюсь в том, что такая метрика дармоедов может быть полезна. Один нерабочий тест может привести к пропуску ошибки так же, как и сотня нерабочих тестов.
По моему мнению, статья не убеждает, что ошибка - это не единичный независимый случай, который должен быть азобран индивидуально и стать толчком (в совокупности с подобными случаями) для выработки практики, которая позолит избежать схожих случаев. И не предлагает никаких подходов, которые помогли бы установить закономерности в цикле разработки, за исключением фрагмента:
что предполагало индивидуальный разбор каждой ошибки.
Автор, прошу подумать над тем, чтобы рассказать о вашем опыте внедрения метрик тестирования с упором на то, как это помогло найти закономерности и изменить рабочие практики. И в том числе повлиять на глобальные метрики, которые вы описали в этой статье. Потому что ваша статья рассказывает о том "что?", но не говорит "зачем?".
Я правильно понял что единственная претензия к джаве это то, что некое комьюнити в большинстве своем перешло на котлин?
Они скорее всего до этого на скалу переходили все повально.
Сомневаюсь что джава (даже якобы мертвая) намного менее поддерживаемая чем избраный автором Free Pascal.
Проекты на джаве прекрасно собираются в андроид студии, а целевой уровень апи как был, так и остался (скорее всего) девятнадцатым - киткат. То есть спокойно можно писать приложения так же, как это делали еще до появления котлина.
Другое дело что писать на джаве может просто не нравиться, и товарищ автор искал повод от нее отказаться. Но если цель найти такой язык, на котором можно написать кучу логики и адаптировать под тучу платформ - кажется что лучше и мощнее чем джава ничего найти не получится.
Вот что действительно умерло - так это джава апплеты, так что для браузера писать gui на джаве уже не получится. А так бы был полный фарш.
Посортировать в обратном алфавитном порядке как строки. Слишком много подсказок про строки и сортировку в одну строку.