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

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

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

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

SALar,

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

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

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

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

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

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

см. http://ru.wikipedia.org/wiki/Тестирование_...ого_обеспечения

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

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

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

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

То есть вы хотите сказать, что ни разу не попробовав блюда, вы сделаете вышеперечисленные действия и почувствуете вкус незнакомого блюда? И этот вкус будет именно тот, как если бы вы попробовали это блюдо?
Кстати, "просмотр списка ингридиендов" - вам тоже ничего не даст, если все они вам неизвестны по Вкусу (IMG:style_emoticons/default/acute.gif)

Если переложить выше написанное на "тестировочную" терминологию, то - это статическое тестирование.
(IMG:style_emoticons/default/crazy.gif)

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

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

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

Мы не говорим о том, что нужно "пробовать все блюда в ресторане". Есть одно из целого списка возможных, которое было заказано конкретным клиентом.
(IMG:style_emoticons/default/rtfm.gif)

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

Далее идет опытная эксплуатация - переваривание в желудке. К сожалению, не вся продукция общепита проходит этот этап успешно. Некоторые решения приходится "возвращать".
(IMG:style_emoticons/default/lol.gif)

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

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

а перейдя на страницу http://en.wikipedia.org/wiki/Verification_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

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

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

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

"А что-то у нас граф Суворов ни чего не" высказывает?
(IMG:style_emoticons/default/crazy.gif)

Дык, после первой не высказывают (IMG:style_emoticons/default/crazy.gif)

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

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

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

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


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

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

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

ИМХО