Речь пойдет о важности тщательного тестирования ПО в двух разных случаях:
Для удобства первый вариант я дальше буду называть “Offline”, а второй — “Online”.
Основная мысль статьи — для варианта “Offline” наличие качественного тестирования жизненно необходимо, для варианта “Online” — хорошо отлаженный процесс разработки важнее тщательного тестирования.
Приведу немного примеров.
Вариант “Offline”
Вариант “Online” — проект, над которым разработчики работают непрерывно, и обновления попадают к пользователям автоматически
Понятно, что в последнее время Online-решения становятся всё более популярными, а Offline остаются только там, где без это го действительно не обойтись. Вспоминая предыдущую статью про борьбу за выживание, можно сказать, что Online являются более гибкими решениями, чем Offline, что обеспечивает им преимущество.
Online-решения снимают с разработчиков массу проблем. Ведь если в ПО обнаружен баг — ничего страшного, можно откатиться к предыдущей версии и быстро исправить ошибку. При этом большая часть пользователей может даже не заметить проблемы (ошибки бывают у всех, но важно чтобы пользователи были уверены — разработчики уже трудятся над исправлением только что обнаруженной ошибки). В Offline-варианте такое невозможно. Отсюда вытекает естественный вывод — требования к тестированию разрабатываемого ПО для Offline должны быть на порядок выше, чем для Online.И наоборот — в Online-решениях можно перенести часть сил с тестирования на реализацию новых фич.
Похоже, именно поэтому в таких продуктах как Facebook разработчики не стремятся покрыть весь код надежными юнит-тестами (недавно читал про это на Хабре).
Немного из личного опыта:
Непрерывно дорабатывая внутренний портал организации, который постоянно используется большим количеством сотрудников, я почувствовал себя “слесарем на заводе”, которому периодически поступают от сотрудников жалобы и предложения типа “было бы неплохо вот эту трубу, проложенную по полу, закрепить под потолком” или “вот в этом месте у нас поток регулируется двумя кранами, а давайте сделаем четыре крана для большего удобства” или “срочно! сборочная линия не работает из-за вчерашнего улучшения, нужно вернуть всё как было”.
То есть в данном случае я делаю не готовые “заводы” под ключ, а непрерывно ремонтирую и улучшаю уже работающий комплекс. И хотя из-за отсутствия параноидального тестирования вероятность проблем при таком подходе довольно высокая — ничего страшного, ведь бригада “слесарей” всегда на низком старте и готова оперативно решать проблемы (ну это в идеале).
Конечно, наличие хорошего автоматического тестирования в каком-то объеме всегда необходимо, особенно для критических функций. Но в Online-решениях на первый план выходит организация взаимодействия разработчиков и пользователей. Если взаимодействие тесное и оперативное — любые проблемы будут быстро решены.
- когда дальнейшая поддержка продукта затруднительна
- когда разработка и поддержка продукта слиты в единый процесс
Для удобства первый вариант я дальше буду называть “Offline”, а второй — “Online”.
Основная мысль статьи — для варианта “Offline” наличие качественного тестирования жизненно необходимо, для варианта “Online” — хорошо отлаженный процесс разработки важнее тщательного тестирования.
Приведу немного примеров.
Вариант “Offline”
- программа управления полетом ракеты (если ракета вдруг полетит не туда — успеть накатить на нее патч вряд ли удастся);
- приложение для продажи в киоске (если в проданном софте будет обнаружен баг — быстро исправить его у всех купивших будет непросто);
- нетиражируемый продукт для одного заказчика (когда проект сделан и сдан заказчику, команда обычно переключается на новый проект).
Вариант “Online” — проект, над которым разработчики работают непрерывно, и обновления попадают к пользователям автоматически
- Браузер Chrome (постоянно автоматически обновляется);
- Facebook, ЖЖ (разработчики постоянно что-то там меняют);
- gMail.
Понятно, что в последнее время Online-решения становятся всё более популярными, а Offline остаются только там, где без это го действительно не обойтись. Вспоминая предыдущую статью про борьбу за выживание, можно сказать, что Online являются более гибкими решениями, чем Offline, что обеспечивает им преимущество.
Online-решения снимают с разработчиков массу проблем. Ведь если в ПО обнаружен баг — ничего страшного, можно откатиться к предыдущей версии и быстро исправить ошибку. При этом большая часть пользователей может даже не заметить проблемы (ошибки бывают у всех, но важно чтобы пользователи были уверены — разработчики уже трудятся над исправлением только что обнаруженной ошибки). В Offline-варианте такое невозможно. Отсюда вытекает естественный вывод — требования к тестированию разрабатываемого ПО для Offline должны быть на порядок выше, чем для Online.И наоборот — в Online-решениях можно перенести часть сил с тестирования на реализацию новых фич.
Похоже, именно поэтому в таких продуктах как Facebook разработчики не стремятся покрыть весь код надежными юнит-тестами (недавно читал про это на Хабре).
Немного из личного опыта:
Непрерывно дорабатывая внутренний портал организации, который постоянно используется большим количеством сотрудников, я почувствовал себя “слесарем на заводе”, которому периодически поступают от сотрудников жалобы и предложения типа “было бы неплохо вот эту трубу, проложенную по полу, закрепить под потолком” или “вот в этом месте у нас поток регулируется двумя кранами, а давайте сделаем четыре крана для большего удобства” или “срочно! сборочная линия не работает из-за вчерашнего улучшения, нужно вернуть всё как было”.
То есть в данном случае я делаю не готовые “заводы” под ключ, а непрерывно ремонтирую и улучшаю уже работающий комплекс. И хотя из-за отсутствия параноидального тестирования вероятность проблем при таком подходе довольно высокая — ничего страшного, ведь бригада “слесарей” всегда на низком старте и готова оперативно решать проблемы (ну это в идеале).
Конечно, наличие хорошего автоматического тестирования в каком-то объеме всегда необходимо, особенно для критических функций. Но в Online-решениях на первый план выходит организация взаимодействия разработчиков и пользователей. Если взаимодействие тесное и оперативное — любые проблемы будут быстро решены.
