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

[Case]

14 марта в Москве УЦ «Лаборатория Качества» проводит тренинг «От тестирования к качеству». Тренинг интересен широкому кругу слушателей: тестировщикам, тест-менеджерам и руководителям проектов.

Темы тренинга:

• Почему тестирование не всегда повышает качество продукта?
• Все ли баги нужно заводить?
• Сколько стоит качество?
• Риски качества, ментальная модель пользователя и другие страшные слова

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

Ведущие тренинга: Наталья Руколь, Дмитрий Обрезков
Время проведения: 14 февраля, суббота, 12.00-17.00.
Стоимость регистрационного взноса: 1000 рублей.
Более подробно о тренинге на сайте УЦ «Лаборатория Качества»

http://feeds.feedburner.com/~r/it4business/~4/549261682

[Pryanik]

<p><strong>14 марта в Москве УЦ <noindex>«Лаборатория Качества»</noindex> проводит тренинг «От тестирования к качеству». Тренинг интересен широкому кругу слушателей: тестировщикам, тест-менеджерам и руководителям проектов.</strong></p>
<p>Темы тренинга:</p>

• Почему тестирование не всегда повышает качество продукта?
• Все ли баги нужно заводить?
• Сколько стоит качество?
• Риски качества, ментальная модель пользователя и другие страшные слова

<p>На этом тренинге мы разберём и обсудим проблематику тестирования, совместно выработаем пути решения ключевых задач, повысив как качество своей работы, так и удовольствие от её выполнения.</p>

<p><strong>Ведущие тренинга:</strong> Наталья Руколь, Дмитрий Обрезков
<strong>Время проведения:</strong> 14 февраля, суббота, 12.00-17.00.
<strong>Стоимость регистрационного взноса:</strong> 1000 рублей.
<strong><noindex>Более подробно о тренинге на сайте УЦ «Лаборатория Качества»</noindex></strong></p>

[Clauster]

[*]Почему тестирование не всегда повышает качество продукта?

Потому что тестирование никогда не повышает качество

[barancev]

Да, на сайте тоже указана дата проведения 14 февраля. Вероятно, дефект :)

[Pryanik]

[*]Почему тестирование не всегда повышает качество продукта?

Потому что тестирование никогда не повышает качество

Вынужден не согласиться. Я вот никогда не слышал, что продукты прошедшии тестирование всегда ниже качеством не прошедших, скорее наоборот. Например кто сядет в самолет если знает, что он никогда не тестировался?:)

[rps5]

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

По теме: Тренинг интересен широкому кругу слушателей.
Хотелось бы всё-таки уточнить, кого авторы тренинга считают своей основной аудиторией (кому тренинг будет больше всего интересен): людям без опыта работы в тестировании, молодым специалистам, профессионалам?

[barancev]

Например кто сядет в самолет если знает, что он никогда не тестировался?:)

Где-то на просторах интернета я читал такую историю, якобы невымышленную.

На конференции по тестированию докладчик спрашивает: "Предположим, вы увидели, что на двери самолёта написано, что программное обеспечение для него разработала ваша фирма. Поднимите руки, кто без страха поднимется на борт?" Поднимается одна рука. Докладчик говорит -- "Вот! Всего один человек достаточно уверен в качестве программ, которые производит его компания". Поднявший руку отвечает -- "Не-е, я просто уверен, что самолёт не сможет подняться в воздух".

[Clauster]

[*]Почему тестирование не всегда повышает качество продукта?

Потому что тестирование никогда не повышает качество

Вынужден не согласиться. Я вот никогда не слышал, что продукты прошедшии тестирование всегда ниже качеством не прошедших, скорее наоборот. Например кто сядет в самолет если знает, что он никогда не тестировался?:)

Дело вот в чем. Если вы протестируете самолет то его качество не повысится, вы просто узнаете каково оно. Т.е. напрямую тестирование не повышает качество, косвенно и в долгосрочной перспективе - да. То есть мы наступаем на грабли, копим опыт и т.д. Чтобы повысить качество протестированного самолета, надо исправить недостатки и собрать новый (это уже не тестирование), который опять надо тестировать, не так ли?

[Quality lab.]

Хотелось бы всё-таки уточнить, кого авторы тренинга считают своей основной аудиторией (кому тренинг будет больше всего интересен): людям без опыта работы в тестировании, молодым специалистам, профессионалам?

rps5, добрый день!
Отвечая на Ваш вопрос: тренинг и впрямь рассчитан на широкую аудиторию, и содержит материалы, которые интересны как начинающим специалистам, так и опытным руководителям.
Но я бы не рекоммендовала этот тренинг для людей, которые совсем не имеют опыта в тестировании - тренинг будет не столь интересен и возможно менее понятен. Других ограничений нет :)

Спасибо за интерес!

[Quality lab.]

Дело вот в чем. Если вы протестируете самолет то его качество не повысится, вы просто узнаете каково оно. Т.е. напрямую тестирование не повышает качество, косвенно и в долгосрочной перспективе - да. То есть мы наступаем на грабли, копим опыт и т.д. Чтобы повысить качество протестированного самолета, надо исправить недостатки и собрать новый (это уже не тестирование), который опять надо тестировать, не так ли?

Тестирование - недостаточное условие для повышения качества программных продуктов. А является ли оно необходимым?

[Clauster]

Дело вот в чем. Если вы протестируете самолет то его качество не повысится, вы просто узнаете каково оно. Т.е. напрямую тестирование не повышает качество, косвенно и в долгосрочной перспективе - да. То есть мы наступаем на грабли, копим опыт и т.д. Чтобы повысить качество протестированного самолета, надо исправить недостатки и собрать новый (это уже не тестирование), который опять надо тестировать, не так ли?

Тестирование - недостаточное условие для повышения качества программных продуктов. А является ли оно необходимым?

нет

[rps5]

Если всё делать без ошибок сразу, то вполне можно обойтись и без тестирования.

[SALar]

Очевидные утверждения, с которыми все обычно согласны	  | Очевидные следствия, которые обычно не доступны пониманию

-----------------------------------------------------------+------------------------------------------------------------------

1. Если что-то сосчитать, больше его от этого не станет.   | Учет сам по себе не может увеличить прибыли. Он позволяет только

2. Но если не сосчитать, то может стать сильно меньше,	 | 1) затруднить воровство;

особенно в России.										 | 2) позволить принять правильные бизнес-решения.

														   | К сожалению последнее работает только

														   | при достаточной оперативности и точности информации

														   | и (что самое главное) при наличии мозгов у принимающего решение.

-----------------------------------------------------------+------------------------------------------------------------------

3. Сосчитать что-то всегда стоит дороже, чем не считать.   | Автоматизация учета никогда не приводит к уменьшению затрат на учет.

														   | 

-----------------------------------------------------------+------------------------------------------------------------------

[Pryanik]

[*]Почему тестирование не всегда повышает качество продукта?

Потому что тестирование никогда не повышает качество

Вынужден не согласиться. Я вот никогда не слышал, что продукты прошедшии тестирование всегда ниже качеством не прошедших, скорее наоборот. Например кто сядет в самолет если знает, что он никогда не тестировался?:)

Дело вот в чем. Если вы протестируете самолет то его качество не повысится, вы просто узнаете каково оно. Т.е. напрямую тестирование не повышает качество, косвенно и в долгосрочной перспективе - да. То есть мы наступаем на грабли, копим опыт и т.д. Чтобы повысить качество протестированного самолета, надо исправить недостатки и собрать новый (это уже не тестирование), который опять надо тестировать, не так ли?

Если рассматривать тестирование "как одноразовый процесс", то согласен результат его = информация, которая сама повлиять на качество кода не может, ни повысить ни уменьшить (это кстати ваше было мнение) :). И я так понял, что вы имели ввиду не один, а несколько витков тестирования.

[Clauster]

[*]Почему тестирование не всегда повышает качество продукта?

Потому что тестирование никогда не повышает качество

Вынужден не согласиться. Я вот никогда не слышал, что продукты прошедшии тестирование всегда ниже качеством не прошедших, скорее наоборот. Например кто сядет в самолет если знает, что он никогда не тестировался?:)

Дело вот в чем. Если вы протестируете самолет то его качество не повысится, вы просто узнаете каково оно. Т.е. напрямую тестирование не повышает качество, косвенно и в долгосрочной перспективе - да. То есть мы наступаем на грабли, копим опыт и т.д. Чтобы повысить качество протестированного самолета, надо исправить недостатки и собрать новый (это уже не тестирование), который опять надо тестировать, не так ли?

Если рассматривать тестирование "как одноразовый процесс", то согласен результат его = информация, которая сама повлиять на качество кода не может, ни повысить ни уменьшить (это кстати ваше было мнение) :). И я так понял, что вы имели ввиду не один, а несколько витков тестирования.

Вы правильно поняли, хоть миллион витков. Само по себе тестирование качество продукта не повышает. Теоретически можно представить ситуацию, когда вы на каждом витке находите баги, но их никто не считает нужным исправлять. Ну или можно вспомнить байку, когда программист фиксит багу и при этом вносит ещё пять. Под долгосрочной перспективой я имел ввиду действительно долгосрочную (много-много лет - придумали юнит-тесты, TDD, BDD etc.).

[Quality lab.]

Тестирование - недостаточное условие для повышения качества программных продуктов. А является ли оно необходимым?

нет

А как выявить необходимость в улучшении?

[Clauster]

Тестирование - недостаточное условие для повышения качества программных продуктов. А является ли оно необходимым?

нет

А как выявить необходимость в улучшении?

Например ревью кода. К чему вы эти вопросы задаете? Не знаете ответы или хотите меня в угол загнать?

[Quality lab.]

К чему вы эти вопросы задаете? Не знаете ответы или хотите меня в угол загнать?

Пытаюсь понять Вашу точку зрения.
Ревью кода - тоже тестирование, идентифицирующее необходимость в изменениях.

[rps5]

Обычно ревью кода выполняет команда разработки или команда тестирования?

[Clauster]

К чему вы эти вопросы задаете? Не знаете ответы или хотите меня в угол загнать?

Пытаюсь понять Вашу точку зрения.
Ревью кода - тоже тестирование, идентифицирующее необходимость в изменениях.

Тогда уж дайте ваше определение тестирования, а то так можно любую деятельность тестированием обозвать, взять например TDD или BDD.