Выпуская их. (судя по глючным кучам .... которые выходят из крупных учреждений)
Orbling
Они проводят очень агрессивную кампанию по продажам и маркетингу, передают разработку другим странам и избегают любых ошибок, которые они могут ... пока они "неожиданно" не потеряют огромную долю рынка.
Работа
Как вы думаете, почему для больших компаний это отличается от маленьких?
JohnFx
Ответы:
30
Вот некоторые из методов, которые использует Google.
Нанимайте хороших разработчиков, которые могут создавать надежный код.
Отдельные отделы контроля качества. Имеются в виду как тестирование людей, так и автоматизированные программы (например, с использованием Selenium), которые имитируют конечных пользователей.
Проводите мониторинг на производстве, чтобы уловить признаки плохого поведения.
Я оценил их в том, что я подозреваю, в порядке убывания ошибок.
Хотя это и неплохой ответ, вы используете множество терминов, таких как «QA», «unit test» и «непрерывная сборка», которые, вероятно, неизвестны для человека, который задаст такой вопрос. Было бы лучше, если бы вы связались или дали определения.
Гейб
@gabe: я добавил указатели к используемой терминологии.
btilly
3
+1 - На самом деле это довольно хороший порядок (1-> 6), когда ЛУЧШИЙ (то есть, самый дешевый, по времени и сложности) ловить ошибки также.
Оз
1
может быть, также и тестирование юзабилити, до того, как лента 90% запросов к функциям слова была для функций, которые уже были у слова, пользователи просто не могли их найти
jk.
@jk: чья это статистика? Цитировать, пожалуйста.
JBRWilkinson
19
В больших компаниях обычно есть целые отделы Q / A, которые отвечают за тестирование кода и следят за тем, чтобы он работал должным образом. Обычно это так, как вы описали - группа людей, тестирующих множество машин. Иногда тесты автоматизированы, иногда нет. См. Обеспечение качества - Википедия
Часто разработчики сами находят ошибки в процессе разработки. Кроме того, клиенты часто первыми обнаруживают ошибку.
Небольшие компании, такие как та, в которой я сейчас работаю, используют практику Agile Testing
+1: Это именно то, как мы это делаем, команда тестирования (в которой я работаю) пишет планы тестирования и пишет весь тестовый код, за исключением тривиальных модульных тестов (разработчики пишут те, некоторые из которых практикуют TDD, но это не обязательно). Мы сосредоточены на принятии, интеграции и регрессах. Когда разработчики находят ошибки, они регистрируют это, исправляют, и мы проверяем это и напишем автоматизацию для этого.
Стивен Эверс
18
Я бы сказал, что речь идет о зрелости компании, а не о ее размере :). Существуют крупные компании с плохой практикой разработки и небольшие компании, находящиеся на переднем крае.
В целом, зрелая команда разработчиков будет заниматься следующими видами деятельности до 1; свести к минимуму внесение новых ошибок в систему и 2; найти ошибки в существующей системе.
Модульное тестирование: это «мини-драйверы» для отдельных методов, чтобы гарантировать, что метод делает то, что говорит. Это всегда автоматизированные тесты.
Интеграционное тестирование. Эти тесты направлены на проверку работы большей функциональности в системе. Это может включать тестирование интеграции базы данных или интеграции со сторонними библиотеками. Это и автоматизированные тесты.
Приемочные испытания: Приемочные испытания написаны для проверки требований пользователя. Обычно они просто проверяют «счастливый путь». В моей команде эти тесты предназначены для того, чтобы показать, что если пользователь использует функциональность, предназначенную для использования, у него не возникнет проблем. Может быть ручным или автоматическим.
Функциональное тестирование: эти тесты похожи на приемочные тесты, но они также проверяют «несчастный путь». Эти тесты предназначены для тестирования не столь очевидных сценариев. Может быть ручным или автоматическим.
Регрессивное тестирование. Мы используем этот термин для «полного тестирования» системы перед ее выпуском клиентам. Ручной или автоматический.
Горилла тестирование: (только руководство). Это тот тип тестирования, когда очень умные люди намеренно пытаются взломать приложение.
Тестирование производительности. Цель - убедиться, что производительность приемлема и не ухудшается с течением времени. Обычно автоматизирован.
Тестирование стабильности. Эти тесты предназначены для обеспечения стабильности системы с течением времени. Автоматизированный.
Непрерывная интеграция. Это система, которая автоматически проверяет ваш код, компилирует его и запускает ваши автоматические тесты. Ваши более быстрые тесты (модуль, интеграция) будут выполняться каждый раз, когда разработчик фиксирует код. Некоторые другие работают еженедельно (приемочные, функциональные) или еженедельные (производительность, стабильность).
Отчеты о покрытии кода: показывает, сколько кода проверено. Код, который не имеет тестового покрытия, с большей вероятностью сломается.
Различные инструменты, которые анализируют код: они обычно показывают, где код должен быть пересмотрен, чтобы сделать его менее подверженным потенциальным ошибкам.
Парное программирование: два разработчика работают вместе для обеспечения функциональности. «Сплоченная пара лучше, чем сумма ее частей».
Самое главное, что нужно убрать: автоматизация и постоянная интеграция .
Не согласен по поводу зрелости компании - вполне возможно, что руководитель разработки программного обеспечения заботится о качестве и в маленькой / молодой компании, и это сообщение направлено сверху вниз. Зрелость инженеров, да, это возможно.
JBRWilkinson
1
@JBRWilkinson: Я думаю, мы можем начать говорить о том, что значит для компании быть «зрелой». Я не хотел сказать, что это связано с возрастом, больше похоже на «мудрость». Стартап может быть зрелым / мудрым, даже если ему всего год или два.
c_maker
4
Это зависит от компании и продуктов, которые она разрабатывает.
Во-первых, многие компании применяют методы кодирования, такие как проверки кода и обязательное связывание (инструменты автоматического обнаружения ошибок), чтобы уменьшить количество ошибок, поступающих в хранилище. Многие компании также приняли модульное тестирование. Это тот случай, когда я работаю (Google). Когда код проверяется, тесты запускаются против всего, чтобы убедиться, что новые ошибки не внесены.
Во-вторых, во многих компаниях есть отделы контроля качества, которые отвечают за проверку поведения. Это особенно распространено в финансах (где ошибки могут быть дорогими, а правила проверки сложными), но также существует в компаниях, продающих продукты пользователям, где отзыв может быть дорогим (например, Intel, Microsoft и т. Д.).
В-третьих, когда это возможно, компании проводят Dogfooding (имеют своих собственных пользователей, которые используют продукт внутри), а затем выпускают ограниченные бета-версии. Многие ошибки обнаруживаются на этом этапе. Например, люди, работающие в Microsoft, используют более новые внутренние версии Office и Windows и DevStudio, чем те, что у вас есть снаружи. Затем ограниченные группы пользователей или компании-подрядчики получают возможность попробовать его. Точно так же в Google мы используем внутренние версии GMail и Docs до выпуска. Игровые компании организуют открытые бета-версии для тестирования своих продуктов, нагрузки на серверы и т. Д.
Конечно, ответ «Это зависит», но я приведу пример из моего крупнейшего проекта, в котором в пиковое время участвовало около 50 разработчиков.
Базовая настройка: базовое программное обеспечение для обработки больших объемов данных с помощью BizTalk.
Первая линия защиты - это юнит-тесты. В нашем случае они выполнялись ежедневно для всего, что проверено в системе контроля версий, и обычно некоторые из них выполнялись разработчиком вручную перед регистрацией. Модульные тесты были написаны в основном разработчиками, но иногда дополнялись тестерами дополнительными тестами.
Следующим этапом была еженедельная сборка Virtual PC, на которой тестировщики выполняли серию в основном автоматических сквозных тестов потока данных на основе документов спецификации для каждого компонента.
После этого тот же Виртуальный ПК был обогащен некоторыми бизнес-данными, весьма близкими к реальным, и снова протестирован с некоторыми конкретными случаями использования.
Затем виртуальный ПК был объединен с другими компонентами системы (также в основном виртуальными) из других отделов для цикла интеграционных испытаний, основанного на сквозном тестировании пользователя, вводящего данные в конец потока данных.
С другой стороны, установочные пакеты были проверены системным провайдером, чтобы определить, правильно ли они установлены в производственной среде и можно ли откатить их в случае сбоя.
После установки в производственной среде мы провели там нагрузочные и стресс-тесты, чтобы проверить общую стабильность (не то, что можно легко принять, когда вы работаете на 10 серверах BizTalk, 8 серверах SQL и куче другого специализированного оборудования, такого как ускоритель XML). и выделенный архив - все кластерно, конечно).
Когда мы были удовлетворены всеми тестами, код был запущен в производство. Вы получаете довольно большую задержку для исправления ошибок в коде (например, 4-6 недель на весь цикл тестирования), и все эти тесты обходятся дорого, но общая стабильность была довольно хорошей. На самом деле лучшее, что я видел до сих пор. Опять же, это очень важно для системы, которая обрабатывает несколько миллионов долларов каждый день. Ваши требования могут отличаться, но вот как мы это сделали, и это сработало.
Первоначальный вопрос кажется более концептуально общим, чем большинство очень подробных ответов, которые были предоставлены.
Давайте посмотрим на это с более высокого уровня (менее подробно). Программное обеспечение разработано, чтобы удовлетворить определенные потребности от кого-то (человек, компания, что угодно).
Эти потребности должны быть сопоставлены с отдельными историями / требованиями, которые в последнее время (на этапе строительства) будут реализованы в исходном коде.
Четкое определение историй / требований имеет важное значение для группы обеспечения качества (QA) (реальных тестировщиков программного обеспечения) для проверки окончательного кода, когда он выполняется, удовлетворяет требованиям этих историй и требований. Таким образом, для этой цели команда QA создает «контрольные примеры» для выполнения этой проверки.
После того, как код будет передан команде QA, он будет протестирован и найдены ошибки. Ошибки разных типов и серьезностей. Эти ошибки отслеживаются, и разработчики назначают их для окончательного исправления.
В настоящее время использование виртуальных машин позволяет одному тестеру запускать разные среды на одном и том же реальном оборудовании. Но иногда вам в конечном итоге нужны компьютеры, предназначенные для фазы контроля качества.
Я надеюсь, что это поможет вам понять (примерно) общий процесс.
Ну, я ненавижу быть циничным, но с количеством открытых ошибок в определенной операционной системе «устройства» кажется, что чем больше и богаче компания, тем больше ошибок они способны создавать и доставлять конечному пользователю. Если программное обеспечение работает и выглядит круто, тогда они все равно его выпускают. Если менеджеры считают, что он готов, значит, он готов. Именно тогда из дерева начинают появляться действительно неприятные ошибки, и конечными пользователями становятся морские свинки. Примерно через десять лет большинство ошибок будет устранено (а некоторые добавлены для хорошей оценки), и компания будет готова перейти к следующей большой идее.
Ответы:
Вот некоторые из методов, которые использует Google.
Я оценил их в том, что я подозреваю, в порядке убывания ошибок.
источник
В больших компаниях обычно есть целые отделы Q / A, которые отвечают за тестирование кода и следят за тем, чтобы он работал должным образом. Обычно это так, как вы описали - группа людей, тестирующих множество машин. Иногда тесты автоматизированы, иногда нет. См. Обеспечение качества - Википедия
Часто разработчики сами находят ошибки в процессе разработки. Кроме того, клиенты часто первыми обнаруживают ошибку.
Небольшие компании, такие как та, в которой я сейчас работаю, используют практику Agile Testing
источник
Я бы сказал, что речь идет о зрелости компании, а не о ее размере :). Существуют крупные компании с плохой практикой разработки и небольшие компании, находящиеся на переднем крае.
В целом, зрелая команда разработчиков будет заниматься следующими видами деятельности до 1; свести к минимуму внесение новых ошибок в систему и 2; найти ошибки в существующей системе.
Модульное тестирование: это «мини-драйверы» для отдельных методов, чтобы гарантировать, что метод делает то, что говорит. Это всегда автоматизированные тесты.
Интеграционное тестирование. Эти тесты направлены на проверку работы большей функциональности в системе. Это может включать тестирование интеграции базы данных или интеграции со сторонними библиотеками. Это и автоматизированные тесты.
Приемочные испытания: Приемочные испытания написаны для проверки требований пользователя. Обычно они просто проверяют «счастливый путь». В моей команде эти тесты предназначены для того, чтобы показать, что если пользователь использует функциональность, предназначенную для использования, у него не возникнет проблем. Может быть ручным или автоматическим.
Функциональное тестирование: эти тесты похожи на приемочные тесты, но они также проверяют «несчастный путь». Эти тесты предназначены для тестирования не столь очевидных сценариев. Может быть ручным или автоматическим.
Регрессивное тестирование. Мы используем этот термин для «полного тестирования» системы перед ее выпуском клиентам. Ручной или автоматический.
Горилла тестирование: (только руководство). Это тот тип тестирования, когда очень умные люди намеренно пытаются взломать приложение.
Тестирование производительности. Цель - убедиться, что производительность приемлема и не ухудшается с течением времени. Обычно автоматизирован.
Тестирование стабильности. Эти тесты предназначены для обеспечения стабильности системы с течением времени. Автоматизированный.
Непрерывная интеграция. Это система, которая автоматически проверяет ваш код, компилирует его и запускает ваши автоматические тесты. Ваши более быстрые тесты (модуль, интеграция) будут выполняться каждый раз, когда разработчик фиксирует код. Некоторые другие работают еженедельно (приемочные, функциональные) или еженедельные (производительность, стабильность).
Отчеты о покрытии кода: показывает, сколько кода проверено. Код, который не имеет тестового покрытия, с большей вероятностью сломается.
Различные инструменты, которые анализируют код: они обычно показывают, где код должен быть пересмотрен, чтобы сделать его менее подверженным потенциальным ошибкам.
Парное программирование: два разработчика работают вместе для обеспечения функциональности. «Сплоченная пара лучше, чем сумма ее частей».
Самое главное, что нужно убрать: автоматизация и постоянная интеграция .
источник
Это зависит от компании и продуктов, которые она разрабатывает.
Во-первых, многие компании применяют методы кодирования, такие как проверки кода и обязательное связывание (инструменты автоматического обнаружения ошибок), чтобы уменьшить количество ошибок, поступающих в хранилище. Многие компании также приняли модульное тестирование. Это тот случай, когда я работаю (Google). Когда код проверяется, тесты запускаются против всего, чтобы убедиться, что новые ошибки не внесены.
Во-вторых, во многих компаниях есть отделы контроля качества, которые отвечают за проверку поведения. Это особенно распространено в финансах (где ошибки могут быть дорогими, а правила проверки сложными), но также существует в компаниях, продающих продукты пользователям, где отзыв может быть дорогим (например, Intel, Microsoft и т. Д.).
В-третьих, когда это возможно, компании проводят Dogfooding (имеют своих собственных пользователей, которые используют продукт внутри), а затем выпускают ограниченные бета-версии. Многие ошибки обнаруживаются на этом этапе. Например, люди, работающие в Microsoft, используют более новые внутренние версии Office и Windows и DevStudio, чем те, что у вас есть снаружи. Затем ограниченные группы пользователей или компании-подрядчики получают возможность попробовать его. Точно так же в Google мы используем внутренние версии GMail и Docs до выпуска. Игровые компании организуют открытые бета-версии для тестирования своих продуктов, нагрузки на серверы и т. Д.
источник
Конечно, ответ «Это зависит», но я приведу пример из моего крупнейшего проекта, в котором в пиковое время участвовало около 50 разработчиков.
Базовая настройка: базовое программное обеспечение для обработки больших объемов данных с помощью BizTalk.
Первая линия защиты - это юнит-тесты. В нашем случае они выполнялись ежедневно для всего, что проверено в системе контроля версий, и обычно некоторые из них выполнялись разработчиком вручную перед регистрацией. Модульные тесты были написаны в основном разработчиками, но иногда дополнялись тестерами дополнительными тестами.
Следующим этапом была еженедельная сборка Virtual PC, на которой тестировщики выполняли серию в основном автоматических сквозных тестов потока данных на основе документов спецификации для каждого компонента.
После этого тот же Виртуальный ПК был обогащен некоторыми бизнес-данными, весьма близкими к реальным, и снова протестирован с некоторыми конкретными случаями использования.
Затем виртуальный ПК был объединен с другими компонентами системы (также в основном виртуальными) из других отделов для цикла интеграционных испытаний, основанного на сквозном тестировании пользователя, вводящего данные в конец потока данных.
С другой стороны, установочные пакеты были проверены системным провайдером, чтобы определить, правильно ли они установлены в производственной среде и можно ли откатить их в случае сбоя.
После установки в производственной среде мы провели там нагрузочные и стресс-тесты, чтобы проверить общую стабильность (не то, что можно легко принять, когда вы работаете на 10 серверах BizTalk, 8 серверах SQL и куче другого специализированного оборудования, такого как ускоритель XML). и выделенный архив - все кластерно, конечно).
Когда мы были удовлетворены всеми тестами, код был запущен в производство. Вы получаете довольно большую задержку для исправления ошибок в коде (например, 4-6 недель на весь цикл тестирования), и все эти тесты обходятся дорого, но общая стабильность была довольно хорошей. На самом деле лучшее, что я видел до сих пор. Опять же, это очень важно для системы, которая обрабатывает несколько миллионов долларов каждый день. Ваши требования могут отличаться, но вот как мы это сделали, и это сработало.
источник
Первоначальный вопрос кажется более концептуально общим, чем большинство очень подробных ответов, которые были предоставлены.
Давайте посмотрим на это с более высокого уровня (менее подробно). Программное обеспечение разработано, чтобы удовлетворить определенные потребности от кого-то (человек, компания, что угодно).
Эти потребности должны быть сопоставлены с отдельными историями / требованиями, которые в последнее время (на этапе строительства) будут реализованы в исходном коде.
Четкое определение историй / требований имеет важное значение для группы обеспечения качества (QA) (реальных тестировщиков программного обеспечения) для проверки окончательного кода, когда он выполняется, удовлетворяет требованиям этих историй и требований. Таким образом, для этой цели команда QA создает «контрольные примеры» для выполнения этой проверки.
После того, как код будет передан команде QA, он будет протестирован и найдены ошибки. Ошибки разных типов и серьезностей. Эти ошибки отслеживаются, и разработчики назначают их для окончательного исправления.
В настоящее время использование виртуальных машин позволяет одному тестеру запускать разные среды на одном и том же реальном оборудовании. Но иногда вам в конечном итоге нужны компьютеры, предназначенные для фазы контроля качества.
Я надеюсь, что это поможет вам понять (примерно) общий процесс.
источник
Ну, я ненавижу быть циничным, но с количеством открытых ошибок в определенной операционной системе «устройства» кажется, что чем больше и богаче компания, тем больше ошибок они способны создавать и доставлять конечному пользователю. Если программное обеспечение работает и выглядит круто, тогда они все равно его выпускают. Если менеджеры считают, что он готов, значит, он готов. Именно тогда из дерева начинают появляться действительно неприятные ошибки, и конечными пользователями становятся морские свинки. Примерно через десять лет большинство ошибок будет устранено (а некоторые добавлены для хорошей оценки), и компания будет готова перейти к следующей большой идее.
источник