Сообщение Re[26]: Рассказ о Крутом Манагере от 09.02.2015 11:42
Изменено 09.02.2015 11:44 Privalov
Здравствуйте, wety, Вы писали:
P>> Для тестирования на рабочем сервере можно завести пару-тройку фиктивных пользователей. Но проверить на них можно только правильность этих самых сетевых настроек.
W>А вот с этим не совсем согласен. Так как пользователей и данных мало, то проблемы
С чего ты взял, что пользователей мало? Я этого не говорил. Я сказал, что на рабочих (читай — production) серверах заводят пару-тройку фиктивных пользователей. И, как мне показалось, объяснил, для чего.
W>- переполнения списков в dropdown,
Тестирование сервера выполняется в специально созданной среде. Причем таких сред несколько. Одна — в ней тестировщики с данными могуь делать все, что угодно. Например, создать тысячу-другую записей, чтобы загнать их, например, в dropdown. И там смотрят, как оно себя ведет.
W>- отсутствия представителей (заместителей на время отпуска/болезни),
Это не понял.
W>- печатных формам и/или форм отображения/редактирования в случаях, когда данные не умещаются в полях ввода/редактирования, в dropdown,
Выполняется в тестовой среде.
W>- производительности
Ты не слышал о нагрузочном тестировании? Выполняется в своей среде, полностью имитирующей production. Врубают автомат, который шлет гору запросов в секунду и смотрят поведение компонентов системы.
W>выявлены не будут. Так? Так!
Выявляются и еще как.
W>Априори ни один тестовый сценарий не даст 100% гарантии именно от багов на рабочем сервере.
W>Так что чем больше будет данных, тем лучше.
Нужно не количество, а качество. Разнообразие пользователей с разными правами доступа к данным, разным заполнением.
Иногда случается: из QA присылают баг. Разработчик смотрит, пишет в ответ "такого в production быть не может". Баг закоывается. Через пару лет интенсивной эксплуатации именно такой баг выстреливает на рабочих серверах.
W>Это правда, что само по себе тестирование и внедрение, настройка стоят как минимум 65-70% от стоимости разработки?
Специально не считал, но да, до фига.
W>Расскажи, пожалуйста, каков процент времени у тебя занимает именно тестирование или написание кода по защите от текущих или будущих возможных багов?
Немало. И все равно время от времени забываю что-нибудь на null проверить. Сейчас, правда, очень редко.
W>В банковском секторе и в особо критически важных ПО (например ПО на ядерных станциях и испытательных стендов) блоков по отработке аварийных веток кода очень много. Так?
Суровые дядьки, пишущие матан на Фортране, тоже много чего проверяют.
В этой теме речь идет о тестах, выполняемых разработчиком (юнит, функциональные и т. д). QA решает несколько другие задачи (нагрузочное, например).
Есть сложности. В одном проекте я увидел, как на 1 (один) юнит тест выделяли неделю. Выяснилось, что под юнит тестом понималась полная интеграция с поставщиком данных. Зато посторонние, слыша модные слова, думали, что разработка ведется в соответствии с последними достижениями науки.
P>> Для тестирования на рабочем сервере можно завести пару-тройку фиктивных пользователей. Но проверить на них можно только правильность этих самых сетевых настроек.
W>А вот с этим не совсем согласен. Так как пользователей и данных мало, то проблемы
С чего ты взял, что пользователей мало? Я этого не говорил. Я сказал, что на рабочих (читай — production) серверах заводят пару-тройку фиктивных пользователей. И, как мне показалось, объяснил, для чего.
W>- переполнения списков в dropdown,
Тестирование сервера выполняется в специально созданной среде. Причем таких сред несколько. Одна — в ней тестировщики с данными могуь делать все, что угодно. Например, создать тысячу-другую записей, чтобы загнать их, например, в dropdown. И там смотрят, как оно себя ведет.
W>- отсутствия представителей (заместителей на время отпуска/болезни),
Это не понял.
W>- печатных формам и/или форм отображения/редактирования в случаях, когда данные не умещаются в полях ввода/редактирования, в dropdown,
Выполняется в тестовой среде.
W>- производительности
Ты не слышал о нагрузочном тестировании? Выполняется в своей среде, полностью имитирующей production. Врубают автомат, который шлет гору запросов в секунду и смотрят поведение компонентов системы.
W>выявлены не будут. Так? Так!
Выявляются и еще как.
W>Априори ни один тестовый сценарий не даст 100% гарантии именно от багов на рабочем сервере.
W>Так что чем больше будет данных, тем лучше.
Нужно не количество, а качество. Разнообразие пользователей с разными правами доступа к данным, разным заполнением.
Иногда случается: из QA присылают баг. Разработчик смотрит, пишет в ответ "такого в production быть не может". Баг закоывается. Через пару лет интенсивной эксплуатации именно такой баг выстреливает на рабочих серверах.
W>Это правда, что само по себе тестирование и внедрение, настройка стоят как минимум 65-70% от стоимости разработки?
Специально не считал, но да, до фига.
W>Расскажи, пожалуйста, каков процент времени у тебя занимает именно тестирование или написание кода по защите от текущих или будущих возможных багов?
Немало. И все равно время от времени забываю что-нибудь на null проверить. Сейчас, правда, очень редко.
W>В банковском секторе и в особо критически важных ПО (например ПО на ядерных станциях и испытательных стендов) блоков по отработке аварийных веток кода очень много. Так?
Суровые дядьки, пишущие матан на Фортране, тоже много чего проверяют.
В этой теме речь идет о тестах, выполняемых разработчиком (юнит, функциональные и т. д). QA решает несколько другие задачи (нагрузочное, например).
Есть сложности. В одном проекте я увидел, как на 1 (один) юнит тест выделяли неделю. Выяснилось, что под юнит тестом понималась полная интеграция с поставщиком данных. Зато посторонние, слыша модные слова, думали, что разработка ведется в соответствии с последними достижениями науки.
Re[26]: Рассказ о Крутом Манагере
Здравствуйте, wety, Вы писали:
P>> Для тестирования на рабочем сервере можно завести пару-тройку фиктивных пользователей. Но проверить на них можно только правильность этих самых сетевых настроек.
W>А вот с этим не совсем согласен. Так как пользователей и данных мало, то проблемы
С чего ты взял, что пользователей мало? Я этого не говорил. Я сказал, что на рабочих (читай — production) серверах заводят пару-тройку фиктивных пользователей. И, как мне показалось, объяснил, для чего.
W>- переполнения списков в dropdown,
Тестирование сервера выполняется в специально созданной среде. Причем таких сред несколько. Одна — в ней тестировщики с данными могуь делать все, что угодно. Например, создать тысячу-другую записей, чтобы загнать их, например, в dropdown. И там смотрят, как оно себя ведет.
W>- отсутствия представителей (заместителей на время отпуска/болезни),
Это не понял.
W>- печатных формам и/или форм отображения/редактирования в случаях, когда данные не умещаются в полях ввода/редактирования, в dropdown,
Выполняется в тестовой среде.
W>- производительности
Ты не слышал о нагрузочном тестировании? Выполняется в своей среде, полностью имитирующей production. Врубают автомат, который шлет гору запросов в секунду и смотрят поведение компонентов системы.
W>выявлены не будут. Так? Так!
Выявляются и еще как.
W>Априори ни один тестовый сценарий не даст 100% гарантии именно от багов на рабочем сервере.
W>Так что чем больше будет данных, тем лучше.
Нужно не количество, а качество. Разнообразие пользователей с разными правами доступа к данным, разным заполнением.
Иногда случается: из QA присылают баг. Разработчик смотрит, пишет в ответ "такого в production быть не может". Баг закрывается. Через пару лет интенсивной эксплуатации именно такой баг выстреливает на рабочих серверах.
W>Это правда, что само по себе тестирование и внедрение, настройка стоят как минимум 65-70% от стоимости разработки?
Специально не считал, но да, до фига.
W>Расскажи, пожалуйста, каков процент времени у тебя занимает именно тестирование или написание кода по защите от текущих или будущих возможных багов?
Немало. И все равно время от времени забываю что-нибудь на null проверить. Сейчас, правда, очень редко.
W>В банковском секторе и в особо критически важных ПО (например ПО на ядерных станциях и испытательных стендов) блоков по отработке аварийных веток кода очень много. Так?
Суровые дядьки, пишущие матан на Фортране, тоже много чего проверяют.
В этой теме речь идет о тестах, выполняемых разработчиком (юнит, функциональные и т. д). QA решает несколько другие задачи (нагрузочное, например).
Есть сложности. В одном проекте я увидел, как на 1 (один) юнит тест выделяли неделю. Выяснилось, что под юнит тестом понималась полная интеграция с поставщиком данных. Зато посторонние, слыша модные слова, думали, что разработка ведется в соответствии с последними достижениями науки.
P>> Для тестирования на рабочем сервере можно завести пару-тройку фиктивных пользователей. Но проверить на них можно только правильность этих самых сетевых настроек.
W>А вот с этим не совсем согласен. Так как пользователей и данных мало, то проблемы
С чего ты взял, что пользователей мало? Я этого не говорил. Я сказал, что на рабочих (читай — production) серверах заводят пару-тройку фиктивных пользователей. И, как мне показалось, объяснил, для чего.
W>- переполнения списков в dropdown,
Тестирование сервера выполняется в специально созданной среде. Причем таких сред несколько. Одна — в ней тестировщики с данными могуь делать все, что угодно. Например, создать тысячу-другую записей, чтобы загнать их, например, в dropdown. И там смотрят, как оно себя ведет.
W>- отсутствия представителей (заместителей на время отпуска/болезни),
Это не понял.
W>- печатных формам и/или форм отображения/редактирования в случаях, когда данные не умещаются в полях ввода/редактирования, в dropdown,
Выполняется в тестовой среде.
W>- производительности
Ты не слышал о нагрузочном тестировании? Выполняется в своей среде, полностью имитирующей production. Врубают автомат, который шлет гору запросов в секунду и смотрят поведение компонентов системы.
W>выявлены не будут. Так? Так!
Выявляются и еще как.
W>Априори ни один тестовый сценарий не даст 100% гарантии именно от багов на рабочем сервере.
W>Так что чем больше будет данных, тем лучше.
Нужно не количество, а качество. Разнообразие пользователей с разными правами доступа к данным, разным заполнением.
Иногда случается: из QA присылают баг. Разработчик смотрит, пишет в ответ "такого в production быть не может". Баг закрывается. Через пару лет интенсивной эксплуатации именно такой баг выстреливает на рабочих серверах.
W>Это правда, что само по себе тестирование и внедрение, настройка стоят как минимум 65-70% от стоимости разработки?
Специально не считал, но да, до фига.
W>Расскажи, пожалуйста, каков процент времени у тебя занимает именно тестирование или написание кода по защите от текущих или будущих возможных багов?
Немало. И все равно время от времени забываю что-нибудь на null проверить. Сейчас, правда, очень редко.
W>В банковском секторе и в особо критически важных ПО (например ПО на ядерных станциях и испытательных стендов) блоков по отработке аварийных веток кода очень много. Так?
Суровые дядьки, пишущие матан на Фортране, тоже много чего проверяют.
В этой теме речь идет о тестах, выполняемых разработчиком (юнит, функциональные и т. д). QA решает несколько другие задачи (нагрузочное, например).
Есть сложности. В одном проекте я увидел, как на 1 (один) юнит тест выделяли неделю. Выяснилось, что под юнит тестом понималась полная интеграция с поставщиком данных. Зато посторонние, слыша модные слова, думали, что разработка ведется в соответствии с последними достижениями науки.