Комментарии: Основные положения тестирования

Автор: Алексей Лупан

Алексей Лупан — Fri, 07 Jun 2013 13:19:42 +0000

В ответ на old. Савина да Канера.

Автор: old

old — Fri, 07 Jun 2013 12:41:38 +0000

что посоветуете читать после этой статьи?

Автор: Основные положения тестирования « IT-безопасность

Основные положения тестирования « IT-безопасность — Fri, 14 Jan 2011 13:29:34 +0000

[…] расшифровка текста со всеми картинками. Рассказывается о тестировании […]

Автор: dwarwood

dwarwood — Wed, 22 Dec 2010 10:09:27 +0000

спасибо за статью
//но жаль что раньше не кинули на хабр 🙂

Автор: IT blog » Архив » Самообучение в Тестировании ПО

IT blog » Архив » Самообучение в Тестировании ПО — Fri, 03 Dec 2010 17:18:27 +0000

[…] запись семинара Тестирование программного обеспечения: основные понятия». В читаемый вид семинар был обработан здесь. […]

Автор: w1zl3

w1zl3 — Mon, 22 Mar 2010 16:11:38 +0000

Как по мне, то нельзя принимать эти положения как стандарт.
Соглашусь с Albert Gareev, и хочется добавить..
«Что такое тест
Это специальная, искусственно созданная ситуация, выбранная определенным образом,
и описание того, какие наблюдения за работой программы нужно сделать
для проверки ее соответствия некоторому требованию.
»
Я это называю тест-кейс, и кажется не я один такой. А тест (или test procedure) это последовательность действий без входных данных и без ожидаемых результатов. Т.е. в совокупности данные, тест и ожидаемые результаты дают тест-кейсы. Да и по IEEE 829 мне казалось так дела обстоят.
«Вот эти 6 аспектов качества верхнего уровня:
функциональность,
надежность,
практичность,
эффективность,
сопровождаемость
переносимость.
»
Я привык разделять тестирование на функциональное и _не_ функциональное и от этого дальше по видам плясать. Стандартами конечно не подкреплю, но я всегда думал, что википедия на моей стороне 🙂
«Другие классификации видов тестирования
Чаще всего используется разбиение на три уровня, это
модульное тестирование,
интеграционное тестирование,
системное тестирование.»
Тут мне кажется с неправильного ракурса рассматриваются этапы тестирования. Если смотреть на эти этапы со стороны готовой интегрированной системы — в принципе можно как то согласится, но не нужно забывать, что эти этапы появляются последовательно обычно. +Интеграционный уровень почти не описан, а систмено-интергационного вообще нет.
На примере будет понятней наверно, что я имею ввиду. Возьмем калькулятор (я отдаю себе отчет, что в тестировании калькулятора интеграционный этап смысла не имеет, он просто взят как пример :)), и допустим, что сначала мы написали код для функций умножения, сложения, деления и т.п.
Тут мы начинаем модульное тестирование — всеразличное статическое (код ревью, тулзы…) и динамическое (юнит тесты, тулзы…).
Тут мы пишем обертку для каждой функции (умножение, деление, сложение и т.п.) — для каждой функции бинарь, который параметрами командной строки принимает числа. Так мы можем проверить функциональность каждой функции отдельно (в больших проектах обычно есть промежуточный этап, а то и не один, при интеграции разрабатываемого продукта в систему, хотя вполне бывает и «Big Bang»)
Тут мы начинаем интеграционный этап тестирования — каждая функция отделана друг от друга, но ее можно уже тестировать блэк-боксом.
Ну и потом мы рисуем калькулятору ГУИ и собираем все функции воедино.
Тут мы начинаем системное тестирование — т.к. функциональность каждой отдельной операции мы уже проверяем на интеграционном уровне, то здесь нам остается проверить взаимодействие операций и корректность взаимодействия с ними через ГУИ.
Хочется всё устаканить конечно, очень правильная и классная идея, но этот вариант еще не доработан.

Автор: Albert Gareev

Albert Gareev — Tue, 16 Mar 2010 15:08:40 +0000

Статья понравилась.
Определение тестирования, на мой взгляд, слишком «изнутри» бизнес-процесса, причем и они бывают на самом деле разных типов. Формулировка сама по себе хорошая, но узковата.
«Главная деятельность тестировщиков — заключается в том, что они предоставляют участникам проекта по разработке программного обеспечения отрицательную обратную связь о качестве программного продукта.»
Далее — комментарии. Обратная связь 🙂
Во-первых, я бы сказал, что «предоставление информации» — это не главная деятельность. Главная деятельность — это ДОБЫЧА той самой информации.
Во-вторых, эффективно тестировать можно и не предоставляя никому ничего. Просто так, для души. Или в целях самообучения, например.
В-третьих, можно тестировать, но о качестве не судить. Просто объективно предоставить все найденные ошибки, недостатки, и особенности.
В-четвертых, «проекта по разработке программного обеспечения» может и не быть. Например, вместо него может быть проект по внедрению купленного программного обеспечения. Здесь требуется не только тестирование в целях поиска проблем, но и поиск путей эти проблемы как-то закрыть (извне), обойти, или хотя бы поставить конечного пользователя в известность.
Ну и в заключение, я бы сказал, ныне тестирование не особенно связано только с понятием «программный продукт». Отдельно взятая программа может работать без каких-либо проблем, а в комплексе с еще одной «валить» всю систему. Вся инфраструктура, каким-либо компонентом которой является программный продукт, нуждается в тестировании.

Автор: Wolonter

Wolonter — Fri, 12 Mar 2010 16:17:00 +0000

О том чуваке с вопросами.
Сегодня у него был первый день тестером. Первый тестер в отделе, понеслась.

Автор: Юрко

Юрко — Wed, 10 Mar 2010 15:08:46 +0000

В ответ на Alexei Barantsev. +1. тестирование, ИМХО, задача творческая и для гибкого пытливого ума. и рости на этом поприще тоже есть куда. хоть вдоль, хоть поперек, хоть, вообще, по диагонали и вверх.

Автор: Юрко

Юрко — Wed, 10 Mar 2010 15:04:13 +0000

В ответ на Alexei Barantsev. Про ООС это скорее всего индивидуаальные особенности именно меня. я пришел в тестирование и автоматики, а это знаете ли откладывает... :-)