Хочу поделиться мыслями об одном из качеств программного обеспечения: сопровождаемости.
В проектах не всегда обращают внимание на сопровождаемость. В результате с изменением команды начинаются сложности. Особенно если команда меняется неожиданно и большим составом.
На проектах я исполнял роль QA. В числе прочих качеств надо было позаботиться и о сопровождаемости. Со стороны программистов в первую очередь подразумевается сопровождаемость кода: наличие комментариев и хорошей структуры. Меж тем сопровождаемость — это нечто большее. Хорошая сопровождаемость позволяет получить выгоду производителю программного продукта. Неспроста в крупных компаниях можно встретить древние программы, имеющие далеко не самый дружелюбный интерфейс, но зато хорошую сопровождаемость. За счет этого их не спешат заменять на разработки конкурирующих фирм.
Можно привести аналогию с прокладкой электрики в здании:
Как тестировщик, могу предложить обратить внимание на следующие аспекты для повышения сопровождаемости.
Документация нужна не только для “пользователей где-то там”, но и для того, чтоб в 12 ночи любой человек, малознакомый с продуктом, мог его использовать, не обращаясь за помощью к другим. Например:
Для создания продукта наверняка используется много инструментов. В их числе:
Все это привязано к проекту. И было бы хорошо иметь детальное описание структуры, чтоб можно было легко восстановить ее при выходе из строя жесткого диска с машинами структуры. Или чтоб можно без особых усилий внести изменения в инфраструктуру, не затрачивая время на изучение каждой мелочи.
В процессе создания и эксплуатации продукта наверняка возникают проблемы. Их можно классифицировать и описать базу решений.
Некоторые дефекты могут иметь способ обхода. Если дефект серьезный, то должна быть возможность отыскать способ его обхода в базе проблем. Например, если какие-либо настройки можно задать лишь в определенном браузере.
Если при разработке обнаруживается информация о том, что в будущем могут возникнуть проблемы, то такая информацию стоит описать в виде рисков. Например, если в системе со 100 пользователями используется модуль, который наверняка сломается при 500 пользователях.
Может существовать документ с техническим описанием всех модулей, в том числе включающий все архитектурные схемы.
Например, о том, какие инструменты и как использовать для отладки и тестирования.
Иногда программисту могут потребоваться инструменты тестировщика для отладки функционала. Либо тестировщику может потребоваться информация об инструментах разработчика для сбора информации при нахождении дефекта.
В том числе стоит обратить внимание на распространенность инструментов. Даже если какой-то инструмент хорошо подходит для решаемой задачи, но он стар и не поддерживается – с ним могут возникнуть сложности.
Как гласит принцип Парето: на выполнение 20% работы уходит 80% времени.
И если что-то не доделано, то наверняка был повод. Скорее всего, это требовало больших затрат.
В проектах не всегда обращают внимание на сопровождаемость. В результате с изменением команды начинаются сложности. Особенно если команда меняется неожиданно и большим составом.
На проектах я исполнял роль QA. В числе прочих качеств надо было позаботиться и о сопровождаемости. Со стороны программистов в первую очередь подразумевается сопровождаемость кода: наличие комментариев и хорошей структуры. Меж тем сопровождаемость — это нечто большее. Хорошая сопровождаемость позволяет получить выгоду производителю программного продукта. Неспроста в крупных компаниях можно встретить древние программы, имеющие далеко не самый дружелюбный интерфейс, но зато хорошую сопровождаемость. За счет этого их не спешат заменять на разработки конкурирующих фирм.
Можно привести аналогию с прокладкой электрики в здании:
- Хороший электрик еще до прокладки проводки предоставит вам ее схему. Не будет необходимости даже через много лет обращаться к нему, чтоб понять, что куда ведет и как работает. Не будет проблем при эксплуатации.
- Если электрик не делает схему проводки, чтоб в следующий раз обращались лишь к нему, т.к. кроме него никто не знает, как все устроено – то следует подумать стоит ли с ним вести дела.
Как тестировщик, могу предложить обратить внимание на следующие аспекты для повышения сопровождаемости.
Документированность функционала.
Документация нужна не только для “пользователей где-то там”, но и для того, чтоб в 12 ночи любой человек, малознакомый с продуктом, мог его использовать, не обращаясь за помощью к другим. Например:
- нанятый вчера программист мог отлаживать фичу,
- сотрудник техподдержки мог ответить на вопрос пользователя
- тестировщик мог проверить, не поломалось ли чего в незнакомой фиче.
Документированность инфраструктуры
Для создания продукта наверняка используется много инструментов. В их числе:
- система сборки. Возможно, состоит из нескольких машин, каждая из которых имеет множество настроек;
- иные сервисы инфраструктуры, такие, как файловые серверы, система хранения кода (особенно если есть зависимости библиотек от других систем) и др.;
- тестовые стенды. Их настройки и описание должны быть в тест-планах.
Все это привязано к проекту. И было бы хорошо иметь детальное описание структуры, чтоб можно было легко восстановить ее при выходе из строя жесткого диска с машинами структуры. Или чтоб можно без особых усилий внести изменения в инфраструктуру, не затрачивая время на изучение каждой мелочи.
Документированность проблем и рисков
В процессе создания и эксплуатации продукта наверняка возникают проблемы. Их можно классифицировать и описать базу решений.
Некоторые дефекты могут иметь способ обхода. Если дефект серьезный, то должна быть возможность отыскать способ его обхода в базе проблем. Например, если какие-либо настройки можно задать лишь в определенном браузере.
Если при разработке обнаруживается информация о том, что в будущем могут возникнуть проблемы, то такая информацию стоит описать в виде рисков. Например, если в системе со 100 пользователями используется модуль, который наверняка сломается при 500 пользователях.
Наличие комментариев и описания кода
Может существовать документ с техническим описанием всех модулей, в том числе включающий все архитектурные схемы.
Наличие информации об используемых инструментах
Например, о том, какие инструменты и как использовать для отладки и тестирования.
Иногда программисту могут потребоваться инструменты тестировщика для отладки функционала. Либо тестировщику может потребоваться информация об инструментах разработчика для сбора информации при нахождении дефекта.
В том числе стоит обратить внимание на распространенность инструментов. Даже если какой-то инструмент хорошо подходит для решаемой задачи, но он стар и не поддерживается – с ним могут возникнуть сложности.
Завершенность задач
Как гласит принцип Парето: на выполнение 20% работы уходит 80% времени.
И если что-то не доделано, то наверняка был повод. Скорее всего, это требовало больших затрат.
