Тренинг «От тестирования к качеству», 14 марта, Москва (УЦ «Лаборатор
#21
Отправлено 10 марта 2009 - 10:56
#22
Отправлено 10 марта 2009 - 11:14
Так мы дойдем до того, что контроль за ходом исполнения проекта это тоже тестирование ;-).Пытаюсь понять Вашу точку зрения.К чему вы эти вопросы задаете? Не знаете ответы или хотите меня в угол загнать?
Ревью кода - тоже тестирование, идентифицирующее необходимость в изменениях.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#23
Отправлено 10 марта 2009 - 11:21
http://software-test...m...ost&p=65484Что-то растиражировалось "Лабораторий качества" :)
http://www.qalab.ru/
http://www.quality-lab.ru
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#24
Отправлено 10 марта 2009 - 15:05
Software Testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software itemТогда уж дайте ваше определение тестирования, а то так можно любую деятельность тестированием обозвать, взять например TDD или BDD.
Standard Glossary of Software Engineering Terminology (ANSI) IEEE Std 829
С точки зрения IEEE, ревью кода это white-box тестирование. Хотя мне приведённая формулировка и не нравится.
В любом случае, тестирование - это процесс выявления. А вот выявлять он, в зависимости от постановки процесса, может разные проблемы, на разных уровнях продукта и на разных этапах разработки.
#25
Отправлено 10 марта 2009 - 17:38
Понятно.Software Testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software itemТогда уж дайте ваше определение тестирования, а то так можно любую деятельность тестированием обозвать, взять например TDD или BDD.
Standard Glossary of Software Engineering Terminology (ANSI) IEEE Std 829
С точки зрения IEEE, ревью кода это white-box тестирование. Хотя мне приведённая формулировка и не нравится.
В любом случае, тестирование - это процесс выявления. А вот выявлять он, в зависимости от постановки процесса, может разные проблемы, на разных уровнях продукта и на разных этапах разработки.
А если я нашел баг, но он не противоречит required conditions? А если у вас список required conditions не полный, вы только имеющиеся проверите и будете считать что тестирование закончено? Будете ли вы тестировать то, что не описано в required conditions? И т.д. (вопросы риторические, отвечать не надо)
По моему мнению, это плохое определение тестирования. То есть это определение не тестирования. Чтобы не повторяться. Вы правы, тестирование это выявление, но только не проблем, а информации о качестве системы.
Я не силен ни в стандартах IEEE ни в тестировании белого ящика, но мне всегда казалось, что белый ящик это когда смотрят на код и по нему составляют кейсы (какие данные подсунуть, какие пути проверить и т.д.), а code review это экспертная проверка кода с целью исправить ошибки программирования (утечки памяти, переполнение буфера и т.д.). Хочу заметить, что вы весьма ловко притянули эти понятия друг к другу. Вот только разница в том, что white-box качество не повышает, а code review повышает (потому что это тут же исправляется). В результате white-box мы получим набор кейсов и список ошибок (если повезет найти) а в результате code review - код более высокого качества (возможно конечно, и низкого).
#26
Отправлено 10 марта 2009 - 22:18
По-моему, не стоит так уж упираться в буквальное определение того, какое тестирование влияет на качество, а какое - нет. На качество, в конечном итоге, влияют конкретные действия, манипулирующие кодом, архитектурой, бизнес-идеей и прочим ливером.белый ящик это когда смотрят на код и по нему составляют кейсы (какие данные подсунуть, какие пути проверить и т.д.), а code review это экспертная проверка кода с целью исправить ошибки программирования (утечки памяти, переполнение буфера и т.д.). Хочу заметить, что вы весьма ловко притянули эти понятия друг к другу. Вот только разница в том, что white-box качество не повышает, а code review повышает (потому что это тут же исправляется). В результате white-box мы получим набор кейсов и список ошибок (если повезет найти) а в результате code review - код более высокого качества (возможно конечно, и низкого).
"смотрим на код и пишем тесты" - это "серый ящик". Белый - это любой статическое тестирование, без запуска. Да, можно сделать ревью кода, это будет офигительный белый ящик, но по результатам его с кодом можно что-то сделать, а можно и не делать. ЭТо же review, а не rewrite/refactor.
Давайте уже придем к следующему соглашению. Ни один из видов _тестирования_ не повышает качество напрямую. Повышается оно, когда разработчик берет напильник и лезет в код. Неважно, откуда он при этом берет информацию - по результатам тестирования, или на основе своей культуры разработки, или он дебагером прошелся, или его заперли в офисе и не выпустят, пока система не будет работать. С другой стороны, можно сделать и юнит-тесты так, чтобы они были "зелеными" на совершенно нерабочем продукте (и это нормальная практика для некоторых команд).
Опять же, по-моему, по (какому-либо) влиянию тестирования на качество нужно разделять две очень простые ситуации: тестирование как ритуал, и тестирование, как одна из активностей в ходе решения общей задачи - разработки продукта. В первом случае можно составить горы проектной документации, верифицировать-валидировать-писать тест-планы по IEEE - и в результате получить 0 (ноль); во втором случае тестирования как _выделенной_ активности может и не быть, но задача будет решена.
Извините, всех комментов не читал, может, повторяюсь уже.
#27
Отправлено 11 марта 2009 - 07:21
Хотелось бы, и тренинг как раз об этом :) Но на практике - далеко не всегда результаты тестирования имеют хоть какое-либо отношение к качеству. Более того, я очень редко вижу людей, которые могут ответить на вопрос о качестве системы, над которой они работают.Вы правы, тестирование это выявление, но только не проблем, а информации о качестве системы.
rlabs, супер, спасибо!
#28
Отправлено 11 марта 2009 - 09:57
#29
Отправлено 11 марта 2009 - 11:05
на работе поговоримПо-моему, не стоит так уж упираться в буквальное определение того, какое тестирование влияет на качество, а какое - нет. На качество, в конечном итоге, влияют конкретные действия, манипулирующие кодом, архитектурой, бизнес-идеей и прочим ливером.
"смотрим на код и пишем тесты" - это "серый ящик". Белый - это любой статическое тестирование, без запуска. Да, можно сделать ревью кода, это будет офигительный белый ящик, но по результатам его с кодом можно что-то сделать, а можно и не делать. ЭТо же review, а не rewrite/refactor.
Давайте уже придем к следующему соглашению. Ни один из видов _тестирования_ не повышает качество напрямую. Повышается оно, когда разработчик берет напильник и лезет в код. Неважно, откуда он при этом берет информацию - по результатам тестирования, или на основе своей культуры разработки, или он дебагером прошелся, или его заперли в офисе и не выпустят, пока система не будет работать. С другой стороны, можно сделать и юнит-тесты так, чтобы они были "зелеными" на совершенно нерабочем продукте (и это нормальная практика для некоторых команд).
Опять же, по-моему, по (какому-либо) влиянию тестирования на качество нужно разделять две очень простые ситуации: тестирование как ритуал, и тестирование, как одна из активностей в ходе решения общей задачи - разработки продукта. В первом случае можно составить горы проектной документации, верифицировать-валидировать-писать тест-планы по IEEE - и в результате получить 0 (ноль); во втором случае тестирования как _выделенной_ активности может и не быть, но задача будет решена.
Извините, всех комментов не читал, может, повторяюсь уже.
#31
Отправлено 15 марта 2009 - 10:22
К сожалению, мы не оценили свои возможности и не смогли провести тренинг для всех записавшихся, поэтому 21-го, в ближайшую субботу, проводим тренинг повторно (свободных мест уже немного!).
Надеюсь, участники тренинга, прошедшего 14 марта, поделятся здесь своими отзывами :)
#32
Отправлено 16 марта 2009 - 13:14
...
Надеюсь, участники тренинга, прошедшего 14 марта, поделятся здесь своими отзывами :)
Я тоже на это надеюсь
#34
Отправлено 17 марта 2009 - 18:03
Список участников
Q-Lab
naten
galchonok
semen
Понятно, что список на livens ничего не говорит, т.к. заявки явно оформлялись через сайт.
комментарий от semen:
организация мероприятия на троечку, виден недостаток опыта.
наполнение тренинга на отлично - сразу хочется использовать изученное на работе!
Организация не очень - это нормально. Вы же за знаниями идете. Осталось узнать, кто такой semen.
В любом случае с почином.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#35
Отправлено 22 марта 2009 - 08:27
И снова ждём отзывов!
#36
Отправлено 24 марта 2009 - 16:16
Вчера тренинг прошёл ещё раз, в микро-формате :)
И снова ждём отзывов!
Мне довелось принять участие в последнем тренинге, о котором написала Наталья.
Впечатления у меня - самые лучшие. Это было одно из наиболее полезных для меня мероприятий, в которых я принял участие в последнее время.
Особый интерес для меня имеет выбор направления дальнейшего развития в тестировании.
Видятся 3 таких возможных направления: в область администрирования, в область программирования и в область аналитики.
О развитии в направлении администрирования хорошо говорилось на известном семинаре Вячеслава Панкратова и Александря Орлова. Но, к сожалению, это направление - не совсем мое.
Как мне представляется, на данном тренинге «От тестирования к качеству» больше и очень плодотворно говорили о направлении аналитики. Были даны методические и практические рекомендации, полезные для более глубокого освоения тестируемых нами программ. В частности, речь шла о рисках качества, которые понимаются разработчиками курса, как потенциальные ошибки, которые могут возникать в ПО.
Возникло желание выявить и формализировать эти риски, что несомненно повысит качество нашей работы.
Еще мне очень понравилась предложенная разработчиками тренинга методика выявления направлений тестирования, наиболее значимых для повышения качества ПО в целом. Было показано, как можно исследовать требования наших заказчиков и клиентов, а также как определять наиболее значимые для них функциональности разрабатываемых нами продуктов.
Все это, однако, требует значительных усилий, которые, я очень надеюсь, воздадутся сторицей и будут весьма полезны нам в будущем.
#37
Отправлено 30 марта 2009 - 09:24
Надеемся дополнить их в этот выходной ещё больше, т.к. 04.04 ещё раз проводим этот тренинг.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных