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

[Clauster]

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

Там то же самое жонглирование. Я не понимат почему если я работал 5 лет тяпкой она мне должна осточертеть? Почему я не могу от нее тащиться? Почему я как специалист по тяпкам не могу искать работу по причинам отличным от того что мне тяпка надоела?

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

Вам про Фому а вы про Ерёму. Мы с Алексеем говорим про конкретную ситуацию.

[OVA]

Ну так ОК. Хотя не интересно.

[CVD1]

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

[theSimplex]

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

[barancev]

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

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

Даже оставив в стороне детальное содержание решений, можно видеть, что решения получились существенно различными. Грубо говоря, я построил решение "вглубь", а Павел "вширь". Вопреки мнению Натальи, которое содержалось в удалённом комментарии, это вовсе не является прямым следствием неких личностных качеств того, кто решал задачку. Разумеется, я вполне мог бы написать решение близкое к тому, которое представил Павел, и наоборот, я уверен, что он вполне мог бы сделать примерно то же самое, что я.

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

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

Но это ещё не всё -- если посмотреть на то, как оценивались результаты выполнения задания, можно заметить, что оценщики тоже весьма сильно разошлись во мнениях :)

Мне кажется, причина этого в том, что у оценщиков где-то внутри тоже есть своё "правильное", эталонное решение, пусть даже явно не сформулированное. И они проверяют на соответствие этому эталонному решению -- не похоже, значит, неправильное.

А отсюда вторая мораль -- "умный" тестировщик через какое-то время сообразит, что от него ожидается, и не будет даже пытаться превзойти поставленную планку, он будет стараться делать так, чтобы понравиться менеджеру. В результате может дойти до того, что тест-менеджер будет иметь команду "клонов", которые все думают как он и делают как он.

Аналогично и при приёме на работу, особенно если отбор поручено сделать рекрутёру, не очень сведущему в тестировании. Он отберёт не тех, кто лучше, а тех, кто угадал "правильный" ответ. А истина -- она подобна... см. выше :)

[Shm]

Почитал я про ваши классы эквивалентности...
Я думал класс эквивалентности - Это набор значений входных параметров на которых целевая функция имеет одинаковое значение.
Хотя я встречался и с другими интуитивными понятиями класса эквивалентности: под классом эквивалентности подразумевают набор входных значений которое даёт одно и тоже покрытие кода.
Иногда под классом эквивалентности подразумевают набор входных значений которое даёт специфическое покрытие требований (например MCDC).

Так или иначе для выделения класса эквивалентности необходимо определить
Входные параметры
целевую функцию и желательно требование, без формулировки этих понятий выделение класса эквивалентности не возможно

кстати какие классы эквивалентности входных параметров для простейшей функции с требованиями ниже

IN: a,b:int32
OUT: ret:int32
 if (a>b)
	{ret = a*b/1024}
	else
	{ret = b}

Вы выделите ? И какое здесь определение класса эквивалентности вы дадите?

Для ясности привожу графики функций
a=b, a*b=(2^31-1)*2^(-10), a*b=-(2^31)*2^(-10)
 Eq_Zone.jpg   59,89К   34 Количество загрузок:
 eq_zonez1.jpg   52,43К   33 Количество загрузок:
(где наступает выбор ветвлений и где наступает переполнение переменной ret (int32) )
Всё это я к чему? Я считаю что пока не выделена целевая функция(Out переменная, один параметр) никакого разговора с математической точки зрения об классах эквивалентности быть не может , всё это наукообразие и попытка придать тестированию псевдо-научный вид. А как оно(тестирование) было шаманством в большинстве случаев, так оно шаманством и останется(исключение составляет формальное юнит тестирование , используемое в авиационной промышленности).И я думаю, первое , что читает настоящий шаман - это исходный код.

Просто, реальное тестирование гораздо сложнее чем картинка с самосвалами. В этой картинке что-нибудь сказано про переполнения, входные данные ладно целевая функция пусть будет проехал не проехал. Да и замечательно когда входные данные можно упорядочить вот например по размеру, как в примере с грузовиками , но в реальной жизни - проход прямоугольный а профиль грузовиков произвольной формы треугольные, пятиугольные и прочие и некоторые с высотой 4.5 м могут проехать а некоторые нет, их нельзя упорядочить по высоте. Так что понятие границы зоны эквивалентности принципиально возможно только на упорядоченных множествах, т.е. мы должны знать как эти множества упорядоченны в коде.

[enki86]

Открываем то, что есть -- пароль на оба файла 1828

Год рождения Алексея Баранцева?
Старейший вампир тестировщик

Извините за флейм - не удержался

[ch_ip]

Открываем то, что есть -- пароль на оба файла 1828

Год рождения Алексея Баранцева?
Старейший вампир тестировщик

Извините за флейм - не удержался

Это год рождения Льва Толстого, а также 2-9 цифры в дробной части экспоненты

[Natalya Rukol]

Перечитав тему, копнула вглубь, сорри что не совсем по теме.

Когда человек занимается одним и тем же на протяжении некоторого периода времени, оно ему надоедает. (Если лично вам не надоело делать одно и тоже, значит еще время не пришло).

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

На практике вообще почти никто не получает настоящего удовлетворения, потому что все вокруг учат, а что же такое "настоящее хорошо":

- Это когда ты растёшь и развиваешься!
- А если нет - тебе должно надоесть!
- А если не надоело - ты фрик!

и т.д.

В результате, происходят непрерывные подмены. "Деньги", "правильно" и "развиваешься" вместо "МНЕ ЭТО ПРОСТО НРАВИТСЯ!".

Моё ИМХО - не надо обобщать. Что всем всё надоедает, что есть какие-то "интересные" или "сложные" или ещё какие-то задачи. Каждому своё, и настоящее искусство - прислушиваться в этих вопросах к себе, а не к окружающим.

[stmark]

2 Shm: А Вам известно про разделение на black box, grey box, white box тестирование? И не нужно путать классы эквивалентности в тестировании и одноименные в алгебре.
P.S. А вообще да, я то же за то, что бы ставить тестирование на более надёжную основу - математику.
UPD. Точнее так, он в общем-то поставлена, но мало кто наработками пользуется.

Сообщение отредактировал stmark: 05 апреля 2011 - 11:47

[Shm]

2 Shm: А Вам известно про разделение на black box, grey box, white box тестирование? И не нужно путать классы эквивалентности в тестировании и одноименные в алгебре.

1)Ну нам известно, конечно , про black box И white box тестирование ну это грубо когда source code не доступен либо доступен на чтение тестировщику. grey box testing это наверно придумал очередной человек , который любит придумывать термины, когда ни черта не сделано. Т.е. мы подглядывем исходники но одним глазком. Мой пас по поводу , того что настоящий шаман всегда глядит в исходный код, лишь говорит о том, что если это не кнопконажимательство , то тестировщику приходится лезть в код и знать код как свои 5 пальцев. Вот я более 10 лет занимался тестированием бортового софта для боингов и айрбасов, они очень хотят чтобы у них было black box testing^* чтобы тестировщики не подклядывали в исх. код. при тестировании а просто читали требования писали тесты , подрубали боевой obj файл(собранный на стороне заказчика) в котором лежит sut подыгрывали test env'ом ... Так нет неплучаетцца - приходится высылать исходники. Да и качество бортового ПО достигается в основном не доказательством что ПО делает один в один что написанно в low level requirement а тем что тестируемая функция проанализирована, прочитана 3-мя разными людьми - разаработчиком(который запрограммировал и написал требования на функцию , да цикл Требование-> Source Code не работает и в авиации), кодревьером , тестером(во многих случаях ещё и тест ревьюером). Да и есть проблема чтобы точно описать точно что делает код надо придумать язык описания сходный с языком программирования иначе требование будет неточным. Но для написания требований не используются компиляторы (для удаления противоречий не используемых переменных и прочей лабуды). и в результате требования на код обычно отстают за кодом да и имеют посредственное качество по сравнению с работающим кодом )
(^*) - Причём техника black box testing в российских компаниях часто связана с тем что тестировщики не умеют читать исходный код и программировать, или с принципиальным желанием сделать тестирование техникой доступной специалистам с квалификацией ниже кодировщика. В технологиях производства бортового софта , желание протестировать всё на black box связанно больше с желанием максимально в определённом смысле изолировать процесс тестирования от процесса кодирования и сделать требования - достаточными для разработки кода а также с нежеланием делится кодом, технологиями с процессом тестирования, который они оутсорсят.

2)О! и Вы к тому же что класс эквивалентности как математическое понятие , часто очень косвенно относится к тому классу эквивалентности которое имеют ввиду навороченные русские тестировщики :-) Хотя в формальном тестировании - непосредственное. Формальное в смысле где процессы формализованы и дано точное определение класса эквивалентности.
Т.е. если тебя спрашивают про классы эквивалентности на собесе имеется ввиду непонятная пижня- набор входных параметров на котором тестируемая функция ведёт себя сходным образом . А что такое "сходным образом" , каждый понимает в меру своей испорченности. Для испорченного тестировщика, тестирующего sin(x) весь диапазон входной переменной представленный цифрой с плавающей запятой является одной зоной эквивалентности. Для второго все точки входного диапазона являются точками принадлежащим разным зонам эквивалентности... А истинна где ? (по-середине)

Сам по себе объект тестирования не повод для тестов

Например тот же double sin(double x) выделите зоны эквивалентности x не зная реализации и цели тестирования. Это, конечно, не картинка с самосвалами...Просто напишите необходимые и достаточные тесты чтобы протестировать эту функцию с неизвестной целью.

[Clauster]

(^*) - Причём техника black box testing в российских компаниях часто связана с тем что тестировщики не умеют читать исходный код и программировать, или с принципиальным желанием сделать тестирование техникой доступной специалистам с квалификацией ниже кодировщика.

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

[Фрося]

Shm!
1. !
Я а российской компании, по КТ а не по DO.
2. Тут фишка в чем.
Специфика.
Встроенное ПО критичное по безопасности -- это не игра виртуальная.
А грузовик - это совсем-совсем упрощенный пример.

3. Про "Так нет неплучаетцца - приходится высылать исходники. Да и качество бортового ПО достигается в основном не доказательством что ПО делает один в один что написанно в low level requirement а тем что тестируемая функция проанализирована, прочитана 3-мя разными людьми - разаработчиком(который запрограммировал и написал требования на функцию , да цикл Требование-> Source Code не работает и в авиации), кодревьером , тестером(во многих случаях ещё и тест ревьюером). "

Ага.
Так что в КТ, что в DO - расписано -- что должно быть проверено. Требования, исходный код и прочее. Не непротиворечивость, на соответствии тому и сему.... (сами ж знаете, ес-но).

Ес-но -- black box testing только мааааааленькая часть..

4.
"Например тот же double sin(double x) выделите зоны эквивалентности x не зная реализации и цели тестирования. Это, конечно, не картинка с самосвалами...Просто напишите необходимые и достаточные тесты чтобы протестировать эту функцию с неизвестной целью."

А... ну так это опять специфика наша..
Тут вон - целая тема есть - что высшее образование непонятно зачем тестировщикам.

[Shm]

Кругом наши, буду шифроваться , а то скажут что пишу еритичные вещи)
Честно KT178 не читал читал только только DO-178B и там с последующими правками и критикой этого документа, с одним из авторов знаком лично.
Поначалу -начиная работать, читая про что и как должно быть разработано и проверено мне показалось всё красиво, потом начиная работать , я понял что на самом деле процесс не работает как декларируется, всё больше разочаровывался в технологии, тк за красивыми словами скрываются часто невыполнимые вещи, заведомо противориечивые. И технология содержит большое количество проблем. Потом года два я испытывал отторжение и плевался, почему все работают не так как правильно, сплошные двойные стандарты - мы знаем как должно быть , делаем как реально , а потом показываем что бы сертифицироваться что работали по DO.

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

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

[OVA]

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

Кагбе зря. Банковское, биллинговое и прочее ПО для терминалов это ад и ужас. Стабильностью оно не отличается, да и тут отдельные граждане из банков в свое время сознавались что небольшие потери трейдеров из-за ошибок в ПО бывают и им куда критичнее вовремя новую версию выкатить, чтобы не потерять еще больше на потерях рынка.

[ch_ip]

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

Кагбе зря. Банковское, биллинговое и прочее ПО для терминалов это ад и ужас.

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

[Фрося]

Кругом наши, буду шифроваться , а то скажут что пишу еритичные вещи)
Честно KT178 не читал читал только только DO-178B и там с последующими правками и критикой этого документа, с одним из авторов знаком лично.

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

О!!! Комплексом, именно что комплексом!
Про "скучно".

Ну... КТ-178 еще надо совместить со всеми прочими документами. Вплоть до ЕСКД. Тут уж просто кране раскованная фантазия нужна - чтоб совместить!
И еще.
Вы видели - как самолет с Вашим ПО на взлет идет?
На межведомственных?
Это ж драйв и адреналин какой!
Когда Ваши тысячи строк кода должны получить "одобрямс" по результатам летных?


А бежать по полю к приземлившемуся самолету?
И потом визжать от восторга, когда команда испытателей говорит - ОК!!! Отлетали! Замечаний нет!
И повиснуть на шее штурмана от избытка чувств (ой.... ну это только для дам)?

Ну... на мой взгляд - -скучна может игры тестировать. Или магазин готовой одежды (ну свитерочки/сумочки, ну размерчики..вышивку показать правльно, цвета перечислить правльно, в таблице размеров не наврать...)

[Shm]

Про "скучно".
Ну... КТ-178 еще надо совместить со всеми прочими документами. Вплоть до ЕСКД. Тут уж просто кране раскованная фантазия нужна - чтоб совместить!
И еще.
Вы видели - как самолет с Вашим ПО на взлет идет?

Не я не видел когда у RRJ first flight был, то он проводился в режиме секретности. Из нашего отдела в Комсомольске на Амуре был один инженер , но его тоже телефонных звонков лишили. Отчасти , я подозреваю, это было сделано на случай непредвиденых ситуаций, если бы самолёт упал. Мы пришли на работу когда борт уже взлетел и выдохнули всем отделом когда нам сказали что борт благополучно сел. Радость была. Но, между сертификацией и первым полётом прошло пару лет и я успел сменить работодателя. Нет , этой романтики я не видел. Процесс производства ПО, в принципе, отлажен как на заводе, производство болванок. Только на заводе рабочий режет деталь, а тут ты тестируешь модуль за модулем, винтик в громадной мащине производства софта. Да и нефтяной экономике России не нужно авиационное производство - оно медленно но верно превращается в машину для исскуственного создания рабочих мест и попила бабла полученого от доходов продажи углеводородов, а в Германии и Америке, самое большое что мне светит это быть на вторых ролях.

[Фрося]

Время немножко освободилось.

Есть возможность порыться и осознать про классы эквивалентности.

А есть ли хоть какой-то формализованный подход к выделению классов эквивалентности?

Погуглила-пояндексила (не слишком тщательно, да).
Попадаются в основном описательные примеры.

Тот же CD диск. Банкомат. Скидки.

[navigatort]

А есть ли хоть какой-то формализованный подход к выделению классов эквивалентности?

В теории множеств.)