Добрый день. Наверное, потому что я человек и могу допускать ошибки как и многие другие) Странно ожидать от меня, как ИТ специалиста, исключительных навыков копирайтинга и редактирования текста.
Что-то подборка не особо трендовых инструментов. А где WebDriver.IO, Playwright, Cypress? И в целом даже из того, что есть не очень понятны “особенности разработки автотестов”.
Описан достаточно типовой процесс тестирования, в чем именно повышение эффективности непонятно. Выглядит как если все смежные процессы будут эффективными, то и тестирование будет эффективным. А на самом деле интересно совсем другое, как максимально выжать из тестирования, если вокруг все на костылях работает, но тут про это нет к сожалению ?♂️
Метрика не равно KPI. Жаль что многие начинают это смешивать.
KPI - показатели эффективности бизнеса или подразделения
Метрики - вспомогательные показатели, которые могут указать на проблемы, почему тот или иной KPI снизился или не был достигнут. В приведенных примерах есть в основном только числа, а вот как понять, что полученные данные - это нормально? или это плохо? Каждой метрике необходимо определять целевое значение и граничное. Целевое - это то, куда мы стремимся, граничное - это сигнал, что есть большие проблемы, а вот все что между целевым и граничным - это повод отслеживать динамику и видеть насколько изменяются показали результативности процесса. На основе динамики можно управлять метриками и изменять целевые показатели. Плюс метрики стоит приводить к единому виду.
Все зависит от сложности системы и то как на неё посмотреть.
Компонентой может быть как функция в коде, так и модуль большой монолитной программы. А интеграция может проверять как взаимодействие модулей одной системы, так и взаимодействие двух функций в рамках одного модуля. Поэтому однозначно относить unit тестирование к компонентному не всегда корректно. Также всегда почему то не упоминается про интеграционный уровень после системного, так как на этом этапе возможно тестирование интеграции нескольких систем в рамках одного e2e процесса, и ещё после приёмка в виде Альфа или Бэта тестирования.
мой вывод: эту модель можно повторять по спирали, но не стоит привязывать к конкретным методам тестирования.
Спасибо за комментарий! Я отчасти в Вами согласен, но тем не менее все зависит от задачи и от роли тестировщика в проекте.
Чтобы хотел дополнить:
1. Тест-дизайн — это больше правила, чем стандарт. Никто не обязывает ими пользоваться, и более, как я писал в статье, их применяют в зависимости от ситуации. Описанные здесь техники — лишь часть. Они характерны больше для полностью нового ПО, которее пишется с нуля. Для ПО, которое в эксплуатации, более подходят техники принятия решений, переходов состояний и другие техники, ориентированные на бизнес процесс. В следующей статье я постараюсь их рассмотреть.
2. Искать уязвимое место — это больше относиться к тестированию, основанному на рисках. Для тестирования на основе рисков совсем другой подход. Но если честно, я все чаще и чаще сталкиваюсь именно с ним.
3.
Найти ошибку в программе — не сложная задача.
Все зависит от задачи. Если мы тестируем веб-приложение какого-нибудь агрегатора, то возможно да, но если мы тестируем формирование банковских резервов или автопилот для самолета, то найти дефект не такая уж и легкая задача становится.
4.
Все эти формальные методики, если ставить их на первое место — быстро превратят вас в одноклеточных.
Как я писал в статье, мы так или иначе на интуитивном уровне применяем их. И я согласен с Вами, что рисовать матрицы и таблицы — не айс. Поэтому тестровщик должен уметь формировать проверки в голове. А техники позволяют ему думать в правильном направлении.
Аудит ИТ — это обязательный процесс в любой организации, которая использует в своей работ какую либо методологию. Советую Вам ознакомится поближе с такими методологиями, как Cobit5 или ITIL\TIPA (для оценки по ITIL). Процесс совершенствования согласно этим методологиям должен быть обязательным для организации. В более зрелых организациях ежегодно выделяют бюджеты на проведения аудитов, есть даже целые отделы внутреннего аудита. Поэтому Вы не правы, и к сожалению в нашей стране аудиты ИТ не так популярны как за рубежом, хотя крупные компании проводят их на ежегодной основе.
Работа организации должна строиться по принципу цикла Демминга PDCA.
Да и в целом во время аудита получать информацию исключительно от людей, которых этот аудит непосредственно затрагивает, не самый хороший метод.
Я говорил о заинтересованных сторонах. Это могут быть даже акционеры компании или пользователи.
Добрый день. Наверное, потому что я человек и могу допускать ошибки как и многие другие) Странно ожидать от меня, как ИТ специалиста, исключительных навыков копирайтинга и редактирования текста.
Что-то подборка не особо трендовых инструментов. А где WebDriver.IO, Playwright, Cypress? И в целом даже из того, что есть не очень понятны “особенности разработки автотестов”.
Описан достаточно типовой процесс тестирования, в чем именно повышение эффективности непонятно. Выглядит как если все смежные процессы будут эффективными, то и тестирование будет эффективным. А на самом деле интересно совсем другое, как максимально выжать из тестирования, если вокруг все на костылях работает, но тут про это нет к сожалению ?♂️
Метрика не равно KPI. Жаль что многие начинают это смешивать.
KPI - показатели эффективности бизнеса или подразделения
Метрики - вспомогательные показатели, которые могут указать на проблемы, почему тот или иной KPI снизился или не был достигнут. В приведенных примерах есть в основном только числа, а вот как понять, что полученные данные - это нормально? или это плохо? Каждой метрике необходимо определять целевое значение и граничное. Целевое - это то, куда мы стремимся, граничное - это сигнал, что есть большие проблемы, а вот все что между целевым и граничным - это повод отслеживать динамику и видеть насколько изменяются показали результативности процесса. На основе динамики можно управлять метриками и изменять целевые показатели. Плюс метрики стоит приводить к единому виду.
Достаточно интересный список проверок, спасибо!
Спасибо статью. В целом для общего понимания картины очень подходит.
Подбор задачек отличный, спасибо!
Все зависит от сложности системы и то как на неё посмотреть.
Компонентой может быть как функция в коде, так и модуль большой монолитной программы. А интеграция может проверять как взаимодействие модулей одной системы, так и взаимодействие двух функций в рамках одного модуля. Поэтому однозначно относить unit тестирование к компонентному не всегда корректно. Также всегда почему то не упоминается про интеграционный уровень после системного, так как на этом этапе возможно тестирование интеграции нескольких систем в рамках одного e2e процесса, и ещё после приёмка в виде Альфа или Бэта тестирования.
мой вывод: эту модель можно повторять по спирали, но не стоит привязывать к конкретным методам тестирования.
Хорошая статья. Спасибо!
Чтобы хотел дополнить:
1. Тест-дизайн — это больше правила, чем стандарт. Никто не обязывает ими пользоваться, и более, как я писал в статье, их применяют в зависимости от ситуации. Описанные здесь техники — лишь часть. Они характерны больше для полностью нового ПО, которее пишется с нуля. Для ПО, которое в эксплуатации, более подходят техники принятия решений, переходов состояний и другие техники, ориентированные на бизнес процесс. В следующей статье я постараюсь их рассмотреть.
2. Искать уязвимое место — это больше относиться к тестированию, основанному на рисках. Для тестирования на основе рисков совсем другой подход. Но если честно, я все чаще и чаще сталкиваюсь именно с ним.
3. Все зависит от задачи. Если мы тестируем веб-приложение какого-нибудь агрегатора, то возможно да, но если мы тестируем формирование банковских резервов или автопилот для самолета, то найти дефект не такая уж и легкая задача становится.
4. Как я писал в статье, мы так или иначе на интуитивном уровне применяем их. И я согласен с Вами, что рисовать матрицы и таблицы — не айс. Поэтому тестровщик должен уметь формировать проверки в голове. А техники позволяют ему думать в правильном направлении.
Работа организации должна строиться по принципу цикла Демминга PDCA.
Я говорил о заинтересованных сторонах. Это могут быть даже акционеры компании или пользователи.