Сообщений в теме: 32

[SALar]

Добавлю еще немного.
Тестирование не единственный способ контроля качества ПО.
И не всегда самый эффективный.

Впрочем, это другая сказка.

SALar,

полагаю, что ты не совсем корректно выразил свою мысль.

Тестирование - это единственный и самый эффективный способ контроля качества.

Но это далеко не единственный способ ОБЕСПЕЧЕНИЯ качества. Другими словами, достижение качества может осуществляться разными путями (всякого рода тестирование, как динамическое, так и статическое, такое как ревью кода, автоматизированные сборки, повышение квалификации участников проектной команды, повышение менеджерских навыков, планирование и бюджетирование, применение стандартов и бест практик и много чего еще - все это приведет к повышению качества продукта).

Наиболее эффективный путь достижения высокого уровня качества - сочетание разных способов обеспечения качества.

Нет, я выразился достаточно определенно. Тестирование не единственный способ контроля качества ПО.
ревью кода - другой метод, позполяет контролировать один из аспектов качества
Акт приемо передачи (не документ, но действие) - третий
Приемо сдаточные испытания, иногда называемые премочным тестированием - четвертый
Опытно промышленная эксплуатация, так популярная в XP - пятый, и это уж точно не тестирование

Причем некоторые методы контролируют одни аспекты качества, другие - другие. Система качества должна выстраиваться из положения, что набор методов контроля должен покрывать все существенные аспекты характеристик продукта и обеспечивать измерения качества с заранее ЗАДАННЫМ доверительным интервалом.

Если допускается варьирование качества и информации о качестве в очень широких пределах, то я рекомендую отказаться от тестирования как метода тотальной проверки ввиду его высокой стоимости и использовать другие методы. Например, метод выборочной проверки.

Н-да, кажется я пытаюсь разрушить основы мироздания. Сейчас меня закидают гнилыми помидорами.

[Green]

SALar,

В моем понимании, все что ты перечислил, является тестированием.

- ревью кода - статическое тестирование;
- приемо-сдаточные испытания - тестирование заказчиком (или его представителем) перед приемкой в опытную эксплуатацию;
- опытно-промышленная эксплуатация - тестирование программы в реальных условиях с реальными данными;
- акт приемо-передачи - вообще документ, подписываемый по результатам приемо-сдаточных испытаний.

Я по прежнему утверждаю, что невозможно оценить вкус блюда не попробовав его.

[KaNoN]

Нет, я выразился достаточно определенно. Тестирование не единственный способ контроля качества ПО.
ревью кода - другой метод, позполяет контролировать один из аспектов качества
Акт приемо передачи (не документ, но действие) - третий
Приемо сдаточные испытания, иногда называемые премочным тестированием - четвертый
Опытно промышленная эксплуатация, так популярная в XP - пятый, и это уж точно не тестирование

Из вышеперечисленных методов контроля качества только ревью кода не кореллирует с тестированием и действительно является несколько другим процессом. А остальные вроде как укладываются (Акт приема-передачи как действие - этого я недопонял).

Может вы укажете, что вы подразумеваете под тестированием, а то данный похоже мы под тестированием понимаем разные вещи? Отсюда и выводы разные

[Darkus]

Нет, я выразился достаточно определенно. Тестирование не единственный способ контроля качества ПО.
ревью кода - другой метод, позполяет контролировать один из аспектов качества
Акт приемо передачи (не документ, но действие) - третий
Приемо сдаточные испытания, иногда называемые премочным тестированием - четвертый
Опытно промышленная эксплуатация, так популярная в XP - пятый, и это уж точно не тестирование

Из вышеперечисленных методов контроля качества только ревью кода не кореллирует с тестированием и действительно является несколько другим процессом. А остальные вроде как укладываются (Акт приема-передачи как действие - этого я недопонял).

Может вы укажете, что вы подразумеваете под тестированием, а то данный похоже мы под тестированием понимаем разные вещи? Отсюда и выводы разные

Ревью кода - это статическое тестирование.

см. http://ru.wikipedia....ого_обеспечения

Статическое и динамическое тестирование

Описанные выше техники — тестирование белого ящика и тестирование чёрного ящика — предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет тестировщик. В обоих случаях это динамическое тестирование.

При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях, анализируется не исходный, а промежуточный код (такой как байт-код или код на MSIL).

[SALar]

Я по прежнему утверждаю, что невозможно оценить вкус блюда не попробовав его.

Когда я прихожу в ресторан, передо мной стоит проблема выбора блюда. Надо сказать, что я не пробую их все.
Произвести оценку блюда можно:
* просмотрев список ингридиендов
* понюхав
* посмотрев

[Darkus]

Я по прежнему утверждаю, что невозможно оценить вкус блюда не попробовав его.

Когда я прихожу в ресторан, передо мной стоит проблема выбора блюда. Надо сказать, что я не пробую их все.
Произвести оценку блюда можно:
* просмотрев список ингридиендов
* понюхав
* посмотрев

То есть вы хотите сказать, что ни разу не попробовав блюда, вы сделаете вышеперечисленные действия и почувствуете вкус незнакомого блюда? И этот вкус будет именно тот, как если бы вы попробовали это блюдо?
Кстати, "просмотр списка ингридиендов" - вам тоже ничего не даст, если все они вам неизвестны по Вкусу

[Green]

Я по прежнему утверждаю, что невозможно оценить вкус блюда не попробовав его.

Когда я прихожу в ресторан, передо мной стоит проблема выбора блюда. Надо сказать, что я не пробую их все.
Произвести оценку блюда можно:
* просмотрев список ингридиендов
* понюхав
* посмотрев

Если переложить выше написанное на "тестировочную" терминологию, то - это статическое тестирование.


Я читал о том, что некоторые очень продвинутые музыканты слышат музыку в голове читая нотные листы. Причем многие слышат мелодию, но наиболее выдающиеся могут слышать всю композицию целиком, как если бы ее исполнял оркестр.

Думаю, что есть и такие кулинары, которые могут представить себе вкус сложного блюда всего лишь понюхав его.

Есть аналогичные примеры и в нашей области. Один из топ менеджеров компании Делл ЕМЕА рассказывал мне, что у них в тестировании работала девушка, которая читала код как книгу (именно читала!) и находила практически все дефекты. Только в одном случае из 100 проверенный ее код содержал ошибку, выявленную на последующих стадиях тестирования.

Мы не говорим о том, что нужно "пробовать все блюда в ресторане". Есть одно из целого списка возможных, которое было заказано конкретным клиентом.


Вот его-то придется попробовать, т.е. протестировать (оценить цвет, запах, вкус) и вынести свой вердикт - понравилось или нет.

Далее идет опытная эксплуатация - переваривание в желудке. К сожалению, не вся продукция общепита проходит этот этап успешно. Некоторые решения приходится "возвращать".

[Oldman]

Ревью кода - это статическое тестирование.

см. http://ru.wikipedia....ого_обеспечения

Статическое и динамическое тестирование

Описанные выше техники — тестирование белого ящика и тестирование чёрного ящика — предполагают, что код исполняется, и разница состоит лишь в той информации, которой владеет тестировщик. В обоих случаях это динамическое тестирование.

При статическом тестировании программный код не выполняется — анализ программы происходит на основе исходного кода, который вычитывается вручную, либо анализируется специальными инструментами. В некоторых случаях, анализируется не исходный, а промежуточный код (такой как байт-код или код на MSIL).

Ссылки на википедию это не совсем то, возьмем, например английскую версию http://en.wikipedia....oftware_testing

Software testing is just one kind of verification, which also uses techniques such as reviews, inspections, and walkthroughs

а перейдя на страницу http://en.wikipedia...._and_Validation, увидим

Verification and Validation (V&V) is the process of checking that a software system meets specifications and that it fulfils its intended purpose. It is normally part of the software testing process of a project.

То есть получается что тестирование ПО - один из типов верификации, а сама верификация + валидация - часть тестирования ПО.

А единой точки зрения все равно у всех не получится.

Зато интересно читать разные точки зрения и пытаться понять что ты сам по этому поводу думаешь.

to Salar

понюхав - это уже тестирование

[SALar]

Мы уперлись в нечеткое определение понятийной области.
Классическая проблема. Будем думать.

Про попробовать и понюхать - имелось ввиду другое различие, но не буду на этом останавливаться. Неудачный пример получился.

[Green]

"А что-то у нас граф Суворов ни чего не" высказывает?

[KaNoN]

"А что-то у нас граф Суворов ни чего не" высказывает?

Дык, после первой не высказывают

Так может все-таки вначале сформируете определения тестирования, прежде чем рассуждать о том, что есть его целями и задачами, а что нет?
А то ведь так из пустого в порожнее переливать можно до бесконечности

[Case]

"А что-то у нас граф Суворов ни чего не" высказывает?

Серёга, извини, ты про меня? :) Я высказался, спорить далее не видя нормальной встречной аргументации не вижу смысла. Тестирование не есть поиск ошибок, ни в целях, ни в средствах, нив задачах ни в приоритетах активностей. Я показал почему и предложил тебе идя от задачи "поиск ошибки" решить банальную задачку.

[Boltick]

Скажу сразу, что тема интересная, собеседники уважаемые и высококвалифицированные профессионалы, от этого даже пальцы трясутся нажимая на кнопки.

Прочитал фразу Сергея:

Как ни крути, а тестировщик тестирует программу (сравнивает спецификацию с реализацией) и выявляет отклонения (дефекты). И в этом (в выявлении дефектов) заключается его ГЛАВНАЯ ЗАДАЧА (другими словами, то, что он делает ежедневно).

Все вроде красиво и правильно, но что-то меня остановило, чтобы согласиться на 100% с такой формулировкой. Лично я дополнил бы вот до чего:

тестировщик тестирует программу (сравнивает спецификацию с реализацией) и выявляет отклонения (дефекты) либо регистрирует, что реализация соответствует спецификации.

Т.е. мы получаем, что результатом тестирования является либо "зеленый", либо "красный" флажок. А из этого следует, что целью тестирования
является не поиск дефектов, а проверка, скажем соответствия поставленным требованиям объекта тестирования.
В результате которой на свет могут появиться дефекты. :)

ИМХО