Комментарии 4
Каким именно образом избыточная коммуникация из Проблемы 1 приводит к ухудшению качества продукта?
Здравствуйте!
Если кратко, то схема следующая:
1. Команда вновь и вновь тратит время на исследование и устранение последствий, а не первопричин
2. Решая вопросы из п. 1 команда либо проседает по качеству и скорости разработки остальной части проекта, либо откладывает решение проблем «на потом»
3. Неполностью устраненные дефекты накапливаются как снежный ком
4. Если эти дефекты все же обнаруживаются и устраняются любыми методами на стадии разработки продукта, то мы имеем на выходе как минимум потерю времени, как максимум, перенос сроков релиза или исключение некоторых компонентов из релиза
5. Если первопричины дефектов не устраняются, то такие дефекты проходят в релиз и вызывают проблемы уже у конечных пользователей
Приведу пример из жизни: мы как-то тестировали приложение, которое управляет одновременно двумя базами: MySQL и LDAP. При этом операция чтения/записи должна была быть транзакцией, т.е. либо вся последовательность действий должна выполниться успешно, либо, в случае хотя бы одной ошибки, вся транзакция должна была отменяться. На уровне взаимодействия с пользователем через Web-интерфейс ребята постоянно замечали странные хаотичные баги, которые было практически невозможно воспроизвести.
Тогда мы сделали автотест, который выполнял те же самые операции + делал вырезки из логов + делал выборку из трейса сниффера. Проблема выявилась моментально: оказалось, что код, работающий с базами, не гарантировал выполнения транзакции. Часть данных не записывалась / не считывалась, и продукт пытался работать дальше, игнорируя это. Таким образом, мы выявили и устранили первопричину, впоследствии доработав тестовое покрытие.
Возвращаюсь к источнику: на все эти операции было потрачено определенное время работы целого ряда людей. К счастью, в данном случае причина выявилась поздно, но все же была обнаружена и устранена.
Если кратко, то схема следующая:
1. Команда вновь и вновь тратит время на исследование и устранение последствий, а не первопричин
2. Решая вопросы из п. 1 команда либо проседает по качеству и скорости разработки остальной части проекта, либо откладывает решение проблем «на потом»
3. Неполностью устраненные дефекты накапливаются как снежный ком
4. Если эти дефекты все же обнаруживаются и устраняются любыми методами на стадии разработки продукта, то мы имеем на выходе как минимум потерю времени, как максимум, перенос сроков релиза или исключение некоторых компонентов из релиза
5. Если первопричины дефектов не устраняются, то такие дефекты проходят в релиз и вызывают проблемы уже у конечных пользователей
Приведу пример из жизни: мы как-то тестировали приложение, которое управляет одновременно двумя базами: MySQL и LDAP. При этом операция чтения/записи должна была быть транзакцией, т.е. либо вся последовательность действий должна выполниться успешно, либо, в случае хотя бы одной ошибки, вся транзакция должна была отменяться. На уровне взаимодействия с пользователем через Web-интерфейс ребята постоянно замечали странные хаотичные баги, которые было практически невозможно воспроизвести.
Тогда мы сделали автотест, который выполнял те же самые операции + делал вырезки из логов + делал выборку из трейса сниффера. Проблема выявилась моментально: оказалось, что код, работающий с базами, не гарантировал выполнения транзакции. Часть данных не записывалась / не считывалась, и продукт пытался работать дальше, игнорируя это. Таким образом, мы выявили и устранили первопричину, впоследствии доработав тестовое покрытие.
Возвращаюсь к источнику: на все эти операции было потрачено определенное время работы целого ряда людей. К счастью, в данном случае причина выявилась поздно, но все же была обнаружена и устранена.
Мне кажется вы путаете причину (найденные слишком поздно баги) и следствие (избыточная коммуникация). И, похоже, подразумеваете под «избыточной коммуникацией» нечто большее. Обсуждение погоды во время исследования бага — вот избыточное общение.
Еще стоило бы разнести проблему из статьи и приведенный пример. В статье говорится об ошибках, которые не были найдены вовремя (при первом проходе) — они вредят в основном тем, что разработчику приходится возвращаться к решенной, и скорее всего уже забытой, задаче, что требует дополнительных затрат на смену контекста.
Пример же из комментария отлично демонстрирует проблему локализации дефекта.
Но как мне показалось, и в том и другом случае, «избыточной коммуникацией» вы называете работу, которую пришлось сделать сверх того, чего хватило бы в случае «идеального» тестирования.
Так что не думаю, что исправление ошибок явным образом (само по себе) ухудшает качество продукта :)
Еще стоило бы разнести проблему из статьи и приведенный пример. В статье говорится об ошибках, которые не были найдены вовремя (при первом проходе) — они вредят в основном тем, что разработчику приходится возвращаться к решенной, и скорее всего уже забытой, задаче, что требует дополнительных затрат на смену контекста.
Пример же из комментария отлично демонстрирует проблему локализации дефекта.
Но как мне показалось, и в том и другом случае, «избыточной коммуникацией» вы называете работу, которую пришлось сделать сверх того, чего хватило бы в случае «идеального» тестирования.
Так что не думаю, что исправление ошибок явным образом (само по себе) ухудшает качество продукта :)
Мы перешли от обсуждения главного вопроса к обсуждению взятой из контекста фразы про избыточную коммуникацию, мне кажется, отсюда идет недопонимание. :-)
В проблеме 1 я говорил о том, что логически непоследовательное и неструктурированное тестирование (причина) приводит к тому, что продукт обрастает багами, и команда может потерять контроль за функциональным здоровьем продукта. В том числе, в комментарии я описывал, как такие дефекты и нерешенные проблемы накапливаются и сваливаются на команду перед релизом, когда сроки «горят», и продукт нужно быстро довести до ума, несмотря ни на что. Дальше, как я описал в пунктах 4-5 комментария, возможны варианты-следствия:
1. «Снежный ком» разгребается, но все равно теряется время, которое можно было бы потратить на другие цели (например, на более качественную проработку какого-то функционала)
2. «Снежный ком» разгребается не полностью — продукт в целом выпускается, но из него исключается часть функционала
3. «Снежный ком» не разгребается — и тогда срываются сроки релиза, либо релиз делается по принципу «авось пронесет», и баги попадают в продукт.
Сюда входят те самые «избыточные коммуникации», под которыми я понимаю дополнительную нагрузку на инженеров по взаимодействию с коллегами из команды. Упомянутые Вами затраты на смену инженером рабочего контекста я тоже предлагаю относить сюда.
Таким образом, я не имел в виду буквально, что избыток общения, или, как Вы заметили, «обсуждение погоды вместо анализа бага» напрямую ухудшает качество продукта. Я описывал комплексную проблему с причиной и цепочкой следствий. С такой же позиции ответил и в прошлом комментарии.
Решая локальные задачи, очень важно не терять комплексное видение, об этом я говорил на протяжении всего интервью. :-)
В проблеме 1 я говорил о том, что логически непоследовательное и неструктурированное тестирование (причина) приводит к тому, что продукт обрастает багами, и команда может потерять контроль за функциональным здоровьем продукта. В том числе, в комментарии я описывал, как такие дефекты и нерешенные проблемы накапливаются и сваливаются на команду перед релизом, когда сроки «горят», и продукт нужно быстро довести до ума, несмотря ни на что. Дальше, как я описал в пунктах 4-5 комментария, возможны варианты-следствия:
1. «Снежный ком» разгребается, но все равно теряется время, которое можно было бы потратить на другие цели (например, на более качественную проработку какого-то функционала)
2. «Снежный ком» разгребается не полностью — продукт в целом выпускается, но из него исключается часть функционала
3. «Снежный ком» не разгребается — и тогда срываются сроки релиза, либо релиз делается по принципу «авось пронесет», и баги попадают в продукт.
Сюда входят те самые «избыточные коммуникации», под которыми я понимаю дополнительную нагрузку на инженеров по взаимодействию с коллегами из команды. Упомянутые Вами затраты на смену инженером рабочего контекста я тоже предлагаю относить сюда.
Таким образом, я не имел в виду буквально, что избыток общения, или, как Вы заметили, «обсуждение погоды вместо анализа бага» напрямую ухудшает качество продукта. Я описывал комплексную проблему с причиной и цепочкой следствий. С такой же позиции ответил и в прошлом комментарии.
Решая локальные задачи, очень важно не терять комплексное видение, об этом я говорил на протяжении всего интервью. :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Automated QA System: таблетка от головной боли для тестировщиков на примере игры Star Crusade