Тестирование – размышление о стереотипах.

20.03.11

Разработка - Математика и алгоритмы

Целью данной статьи является не рассказ о тестировании как таковом – это слишком обширная тема, а скорее развеивание некоторых стереотипов.

 

Что же такое тестирование? Тестирование – это процесс поиска ошибок с целью ответить на вопрос о качестве исследуемого программного обеспечения (в дальнейшем ПО).  

И первый стереотип, который существует – это инженером по тестированию может быть  человек с низкой квалификацией.  Поэтому, во многих фирмах на должности инженера по тестированию работают люди, которые не имеют никакой квалификации или вообще данная роль отводится пользователям ПО.  Это приводит к тому, что приемочное тестирование проводится не в полном объеме и (если фирма дорожит своей репутацией) фирме приходится тратить деньги на дальнейшую поддержку ПО (исправление ошибок выявленных в процессе эксплуатации). При этом часто страдает репутация в момент внедрения (установки) ПО, так как появляются ошибки, которых в процессе разработки не было – это ошибки неинициализированных данных.

Второй стереотип – это инженер по тестированию должен выявить как можно больше ошибок. Это бессмысленно, так как задача инженера по тестированию – это повышение качества ПО, а неисправленные ошибки качества не повышают. Поэтому, инженер по тестированию (в идеале) должен выявить ровно столько, сколько программисты в состоянии исправить.

Третьий стереотипв протестированном ПО отсутствуют ошибки.  Давайте рассмотрим простой пример. Пусть дана функция Ф(х) = у которая умножает х на два. Х – это целые числа от 1 до 99. Давайте определим тесты:

Х = 1 у = 2

Х = 99 у = 182

Х = 0 у = ошибка

Х = -1 у = ошибка

Х = 100 у = ошибка

Х = слово у = ошибка

Х = « у = ошибка

Х = 1.1 у = ошибка

Итак, мы получили восемь вариантов тестов. Теперь увеличим количество входящих параметров в два раза то есть будет Ф(х,х1) = у которая будет перемножать х и х1. Сколько будет вариантов тестов? А теперь вспомним программный код, сколько функций имеют больше чем один параметр? И если мы зададимся целью провести все тесты, то потратим на них неоправданно большое количество времени.

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

Итак, почему же поиск по hh.ru выдает только пять результатов, да и те не связаны с тестированием? Видимо заказчики еще не готовы платить за качество ПО.

 

См. также

Метод Дугласа-Пойкера для эффективного хранения метрик

Математика и алгоритмы Платформа 1C v8.2 Конфигурации 1cv8 Россия Абонемент ($m)

На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.

1 стартмани

30.01.2024    1714    stopa85    12    

33

Алгоритм симплекс-метода для решения задачи раскроя

Математика и алгоритмы Бесплатно (free)

Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.

19.10.2023    4316    user1959478    50    

34

Регулярные выражения на 1С

Математика и алгоритмы Инструментарий разработчика Платформа 1С v8.3 Мобильная платформа Россия Абонемент ($m)

Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.

1 стартмани

09.06.2023    7343    4    SpaceOfMyHead    17    

56

Модель распределения суммы по базе

Математика и алгоритмы Платформа 1С v8.3 Россия Абонемент ($m)

Обычно под распределением понимают определение сумм пропорционально коэффициентам. Предлагаю включить сюда также распределение по порядку (FIFO, LIFO) и повысить уровень размерности до 2-х. 1-ое означает, что распределение может быть не только пропорциональным, но и по порядку, а 2-ое - это вариант реализации матричного распределения: по строкам и столбцам. Возможно вас заинтересует также необычное решение этой задачи через создание DSL на базе реализации текучего интерфейса

1 стартмани

21.03.2022    7817    7    kalyaka    11    

44

Изменения формата файлов конфигурации (CF) в 8.3.16

Математика и алгоритмы Платформа 1С v8.3 Бесплатно (free)

Дополнение по формату файлов конфигурации (*.cf) в версии 8.3.16.

16.12.2021    4414    fishca    13    

36

Интересная задача на Yandex cup 2021

Математика и алгоритмы Бесплатно (free)

Мое решение задачи на Yandex cup 2021 (frontend). Лабиринт. JavaScript.

12.10.2021    8793    John_d    73    

46

Механизм анализа данных. Кластеризация.

Математика и алгоритмы Анализ учета Платформа 1С v8.3 Анализ и прогнозирование Бесплатно (free)

Подробный разбор, с примером использования, встроенного механизма кластеризации 1С.

31.08.2021    7713    dusha0020    8    

70
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Stepa86 1520 22.03.11 08:04 Сейчас в теме
Чот не понял по второму стереотипу... Если инженер будет находить не все ошибки (а только сколько может исправить команда), а особенно если он будет пропускать критические, то качество ПО от этого не сильно повысится. Чем больше найдет инженер ошибок, тем больше информации о них будет у команды и тем полнее они смогут оценить масштаб трагедии (нахождение жучиных гнезд, приоритеризация инцидентов, установка заплаток или переписывание подсистемы с нуля итп). Однако ж, если инженер не находит ошибки, то это не всегда означает, что качество приемлемо и в этом случае все сильно зависит от квалификации инженера. Наверно я бы сформулировал так: инженер должен находить такие ошибки, которые помогли бы повысить качество максимально быстро, и находить он должен так, чтобы это помогало команде, а не наоборот.
ЗЫ все ИМХО 8-)
2. artbear 1447 22.03.11 08:19 Сейчас в теме
Тестировщик в любом случае должен находить ошибки, это его работа.
Но не нужно пытаться протестировать весь код, нужно выделять какие-то важные участки и стараться их проверять сильнее.
ИМХО в идеале тестировщик не должен иметь доступ к исходному коду, а работать только с черным ящиком.
3. Stepa86 1520 22.03.11 08:31 Сейчас в теме
(2) Такие вещи, как аудит кода, инспекция проекта, двойное чтение кода (при парном программировании например) итп больше подходит под классификацию тестирования стратегией белого ящика, а по количеству найденных ошибок на тысячу строк кода (или сколько там стандарт) иногда и превосходит черный ящик. Да и ошибки ловятся совершенно разные. Где то видел табличку со статистикой по проценту найденных ошибок разными подходами, вроде у Макконнелла

Да и вообще при экстремальном программировании ( и/или при TDD ) инженер по качеству может не ловить ошибки в принципе, но качество будет на уровне
4. vkr 22.03.11 10:15 Сейчас в теме
(0) Тоже по второму стереотипу...
А что значит - "инженер по тестированию (в идеале) должен выявить ровно столько, сколько программисты в состоянии исправить" ?
То есть, он нашел ошибку - а программисты НЕ В СОСТОЯНИИ ее исправить ??? Тупые, типа... :)
Или Вы имеете в виду, что руководство проекта распорядилось на данном участке коррекцию ошибок временно притормозить
и все силы перебросить на более важные участки проекта? Тогда понятно...
5. awk 741 22.03.11 11:10 Сейчас в теме
Я знал, что стереотип №2 крепок.

Задача инженера по тестированию, не поиск ошибок, а повышение качества ПО. Он не должен доказать, что все программисты в отделе недоучки, он должен дать им отчет об ошибках. Если давать отчет программистам, в котором ошибок больше чем они могут (успеют) исправить, то большинство из ошибок, просто "ляжет под сукно". Это нормально. Просто так устроен человек, если его нагрузить так, что он не будет справляться, то он рано или поздно потеряет интерес к работе. К тому же на поиск тратится время. Время - деньги. Следовательно поиск ошибок которые не исправят - это зря потраченные деньги.
7. Stepa86 1520 22.03.11 11:32 Сейчас в теме
(5) никто не спорит, что #2 стереотип, но вот утверждение "инженер по тестированию (в идеале) должен выявить ровно столько, сколько программисты в состоянии исправить" вот вообще не нравится. Из него следует, что если завтра у нас дедлайн, а свободных программистов только на исправление одной маленькой ошибки, то инженер должен найти только одну маленькую ошибку и сказать, что он больше ничего не нашел (потому что больше никто ничего не успеет сделать). Результатом будет попытка сдачи сырого продукта. Или есть некоторая подсистема с 1000 ошибками, допустим они все имеют одинаковую трудоемкость по исправлению и программисты осилят тока 100. Что лучше, найти первые 100 и забить или найти первые 500 и решить 100 наиболее важных?

Инженер должен оценивать качество продукта независимо от того, когда там срок и кто сколько успеет сделать. Для всех найденных ошибок нужно оценивать вероятность появления, последствия, критичность, приоритет, целевую группу пользователей и другие показатели в зависимости от методологии и на основе всего это решать что и как делать, а любой багтрекер позволит управлять ошибками и не давать чему то важному забыться.
6. Rusmus 45 22.03.11 11:19 Сейчас в теме
(0) Меня тоже возмутил комментарий ко второму стереотипу.
Стереотип спорен, согласен. Но ненайденная ошибка - еще не значит отсутствующая. Будет хуже, если на ошибку потом наткнется пользователь. Здравый вариант - в посте (1).
А ошибки, кроме того, что они просто есть, еще можно упорядочить по критичности, важности и вероятности проявления. Абсолютно все найденные ошибки нет смысла исправлять - по крайней мере немедленно.
(2) Для черного ящика приходится перебирать всевозможные состояния программы. А это - см. стереотип 3. Фактически, имея исходные код, можно найти узкие места "на глазок", без утомительного воссоздания ситуаций.
10. awk 741 22.03.11 11:59 Сейчас в теме
(6) Не забываем, что тестирование итерационный процесс. Разработка - Тестирование - Баг фикс - Тестирование - Баг фикс - Тестирование - Разработка - и т.д. Что не выявлено в шаге цикла 1 будет выявлено в шаге 2, 3, и т.д.

(7)
1. Идеал - не достижим.
2. Да найти он может и не одну (и найдет), только выискивать все в вашем примере смысла нет - завтра сдавать. Либо срывать сроки (если нашли критичные ошибки), либо писать отчет и откладывать решение на после сдачи (service pack).
3. Команда не должна работать ради идеального продукта, она должна выпускать конкурентоспособные продукты. Затраты надо соотносить с доходами.
4. Забываются еще как. К тому же ошибка - это релизозависимый показатель. Даже если ты о ней не забудешь, то через полгода она может потерять актуальность.

(8) Эх, как я вас понимаю. Однако я уже полгода наблюдаю картину когда заказчик готов платить и прогерам и тестерам, а на рынке их нет. Только нашли - им на старом месте повысили зарплату человек сорвался.
11. Stepa86 1520 22.03.11 12:13 Сейчас в теме
(10) 1. Я про идеал вроде не писал
2. Если завтра сдавать, то лучше все же знать какие есть критические ошибки, и если они сильно критические, то или гнать работать всех в ночь или все же переносить сдачу, иначе будет неудобно перед заказчиком как то... да и зная ошибки можно успеть поставить заплатки, найти способы обхода или сразу и честно сказать заказчику по планам предоставления багфиксов
3. Причем тут идеальный продукт? Если мы пропускаем критические ошибки из-за остановки в поиске, то мы даже приемлемого качества не достигнем
4. Если ошибка пролежала полгода, значит не так уж она важна и критична, но это не значит, что не нужно искать новые ошибки, так как багтрекер еще не пуст.

про итерационный процесс: "Начать искать ошибки после написания кода это как начать делать бекапы после поломки винта. В принципе полезно, но несколько поздновато."
12. awk 741 22.03.11 12:33 Сейчас в теме
(11)
1. А это?
Инженер должен оценивать качество продукта независимо от того, когда там срок и кто сколько успеет сделать.

2. Если завтра сдавать, а конь не валялся - то завтра ничего не примут. Можно смело срывать сроки. Гнать людей в ночь смысла нет.
3. Искать и выявлять можно бесконечно. Есть порог ошибок, за которым тестирование теряет смысл. (называется релиз провален)
4. Пустой багтрекер - это нонсенс.
16. Stepa86 1520 22.03.11 13:15 Сейчас в теме
(12) 1. Про идеал тут речи не идет, просто говорю, что качество должно быть на высоте всегда, а не когда закончили херачить код, тогда и начали оценивать
2. Если всплыла одна и только одна критическая ошибка, то смысл гнать в ночь может и есть, все зависит от контекста, это всего лишь утрированный пример описывающий ваш тезис
3. Так же как и дорабатывать функционал, собирать требования, повышать юзабилити и вообще все, что связано с разработкой. Но для достижения максимальной эффективности мы должны решать в первую очередь более приоритетные задачи, а не первые попавшиеся, которые появляются если смотреть на занятость разработчиков. Когда нужно останавливаться можно почитать тут, да и вообще это полезный ресурс
4. Если мы найдем ровно столько ошибок сколько могут закрыть разработчики, то это легко может быть
13. romansun 193 22.03.11 12:42 Сейчас в теме
(10)
"Однако я уже полгода наблюдаю картину когда заказчик готов платить и прогерам и тестерам, а на рынке их нет"

Воооот, а тут начинается вторую часть марлезонского балета - просто так тестеры с неба не сваливаются, они получаются обычно из программеров (в случае с 1С). А какой программер готов уйти в тестеры? ))

Культура разработки 1С в целом пока не на высоте - ни сертификации толком нет, ни разграничений по обязанностям, ни четкого понимания процессов разработки - всё в одной куче :) Но, думаю, со временем ситуация изменится.
14. awk 741 22.03.11 12:53 Сейчас в теме
(13)
1. Ну думаю процентов 30 программистов ушло бы, при условии сохранения уровня ЗП. Просто, что бы поиметь опыт (я ушел, правда с повышением ЗП :)).
2. Ну тут у 1С есть плюсы. Можно на коленках собрать рабочую систему малого предприятия. Потом нанять профи и допилить до сносного уровня среднего предприятия. А поняв, что хотим от жизни, заказать нормальную автоматизацию предприятия в целом (когда оно доростёт).
8. romansun 193 22.03.11 11:34 Сейчас в теме
(0) "Видимо заказчики еще не готовы платить за качество ПО."

программистов-то не найти, а тут - тестировщики )))

Это ж 1С, нормальных тестировщиков могут позволить себе только солидные франчи, вероятно. Все остальные - и швец, и жнец, и на дуде... игрец.

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

Как следствие, случаются ошибки; как следствие, заказчик негодуэ - "вы там ваще тестируете??!! регресс-тестирование проводите??!!". Но тут заказчик лукавит, конечно, поскольку понимает - нормальное тестирование сразу взорвёт стоимость разработки в разы... Поэтому клиент готов мириться с некоторыми косяками (не критичными, разумеется )) ), но при этом и с экономичными расценками.

Вот такое установившееся равновесие.
9. cool.vlad4 2 22.03.11 11:38 Сейчас в теме
Почему человек знает как делать правильно и все равно делает неправильно...все это примерно из одной серии...
ЗЫ Раньше очень не любил глупых пользователей, сейчас ценю их больше всех, - только они способны выявить такой баг, который даже после нескольких месяцев работы не проявляется.
djvu; BigMih; awk; +3 Ответить
15. Ish_2 1104 22.03.11 13:09 Сейчас в теме
Стереотип два , конечно, неудачно сформулирован. И опровергается простым примером.
Действительно тестером найдена критически важная ошибка , но программисты её исправить не могут.
Тестер зря потратил время ? Ничего полезного не принес фирме ? Так ?

Выявлять нужно в первую очередь критически важные для функционирования ПО ошибки.
Остальное, возможно, как получится.
Т.е. речь должна идти о рассстановке приоритетов при поиске ошибок.
17. awk 741 22.03.11 13:35 Сейчас в теме
(15)
инженер по тестированию должен выявить как можно больше ошибок
Опровержение стереотипа по вам:
Выявлять нужно в первую очередь критически важные для функционирования ПО ошибки.
Остальное, возможно, как получится.
Т.е. речь должна идти о рассстановке приоритетов при поиске ошибок.


(16)
1.
качество должно быть на высоте всегда
- и чем не идеал?
2.
Если всплыла одна и только одна критическая ошибка,
Это в конце дня перед сдачей? Что-то здесь неправильно. Либо процесс выпуска релиза (тестированию отведено мало времени), либо тестировщик мышей не ловит, либо РП не следит за сроками, но определенно, что-то не так.
3. Останавливаться надо, когда подписаны акты о приемке. Прибыль получена - активное тестирование не имеет смысла. Дальнейшее тестирование ложится на пользователей, а предприятие терпит убытки от найденных ошибок. Смысл кормить тестера, если пользователь это делает бесплатно?
4. Не понял.
18. Stepa86 1520 22.03.11 13:51 Сейчас в теме
(17) 1. Высокое качество продукта и идеал это все же разные вещи... идеал не достижим, не спорю, а вот высокое качество должно быть у продукта по-умолчанию. Качество - это мера соответствия требованиям заказчика, и если мы не соответствуем его требованиям, то что мы тогда вообще тут колбасим?
2. Пример утрированный, иллюстрирующий тезис "инженер по тестированию (в идеале) должен выявить ровно столько, сколько программисты в состоянии исправить" и показывающий, что при стремлении возможностей программиста к 0, количество ошибок у инженера тоже должно стремится к 0, а это не так.
3. Ну если исходить из принципа "я выкрутился, теперь это ваши проблемы" и делать не такую систему, с помощью которой клиент будет получать свой профит, а такую, которую можно сдать, и дальше не наши проблемы... При нормальном проекте, сначала заканчивается альфа-тестирование, а уже потом проект сдают, а не так, что авльфа-тестирование заканчивается тогда, когда мы умудрились обмануть заказчика и убедить, что система работает.
4. Программист может сделать 5 заданий, значит в багтрекере сейчас не более 5 заданий, а значит они могут закончится - получаем пустой багтрекер
19. awk 741 22.03.11 14:22 Сейчас в теме
(17)
1. Что для вас продукт высокого качества? Для меня OpenBSD 2 критичных бага за 11 лет. Вот только функционал, юзабилити ....
2. Идеальный пример, не противоречит идеальному результату. Да так и должно быть. Зачем тратить деньги, на то что не принесет пользы.
3. Я что-то имел против альфаверсий? Более того есть еще стадия преальфа. Только цель организации - это получение прибыли, а не создание продукта ради продукта. Есть приемлемый уровень ошибок. Пока мы собираемся продавать продукт - мы ищем и исправляем. Как только прекращены продажи - мы исправляем по требованию и то в течении N времени (надо новые версии продавать - ничего личного).
4. См. п. 2. Идеальный вариант. Релиз выпущен без багов - не бывает такого, зато стремление к этому дает хорошую прибыль.
20. Stepa86 1520 22.03.11 14:40 Сейчас в теме
(19) 1. Определение качества. Если продукт делает то, что мне надо не вызывая отвращения, то для меня такой продукт качественный.
2. не понял
3. вы постоянно уходите в сторону от обсуждения единственного камня преткновения. разговор не про маркетинг, не про организацию различных методик тестирования, не про способы впаривания продукта итд, а про то, что не надо ограничивать количество ошибок возможностями разработчиков просто лучше потратив побольше ресурсов получить более приоритетный список ошибок, который позволит быстрее вывести качество продукта на нужную планку, чем подкидывать по одной ошибке когда проги проставивать начнут. Заметьте, что я не единственный об этом говорю.
4. Если бы работал ваш тезис, то это было бы сплошь и рядом, но это не так...

+(3) вот табличка по эффективности различных методик http://screencast.com/t/MchuN9cUA
doom2good; +1 Ответить
21. awk 741 22.03.11 15:00 Сейчас в теме
(20)
1. То есть вы допускаете наличие ошибок некоторого уровня в ПО? Даже примерно описали какой-то уровень.
2. Если возможности исправления ошибок стремятся к нулю, то надо нанимать еще одного программиста (может быть вместо старого).
3. Нужно стремится к балансу, выявленных/исправленных ошибок. Если выявляем больше чем исправляем - нанимаем программиста, если исправляем больше чем выявляем - нанимаем тестировщика (выпускаем бета-версию, для тестирования более широким кругом). Я лишь говорю о том что тестировщик должен повысить качество продукта, а не выявить как можно больше ошибок. Неисправленные ошибки качество не повышают - с этим то вы согласны?
4. Стремление к качественному продукту - приносит прибыль. Качество как цель продукта или некачественный продукт - прибыли не приносит.
22. Stepa86 1520 22.03.11 15:10 Сейчас в теме
(21) 1. ПО без ошибок не существует, это аксиома
2. я бы не был так категоричен, ошибки могли появится при сборе требований, при их изменении, при написании спецификаций, при срабатывании какого либо риска, при неграмотном менеджменте, при недостаточной квалификации итп. Если список ошибок только растет, то надо решать проблему большого количества ошибок, а не сдерживать инженера по качеству
3. да я со всем согласен, кроме фразы "инженер по тестированию (в идеале) должен выявить ровно столько, сколько программисты в состоянии исправить" :D, может вы имели ввиду "скорость появления новых ошибок не должна превышать скорости их отработки, в идеале" ?
4. Скорее сокращает расходы, чем приносит прибыль. Понятно, что неимоверно качественное решение никому ненужной проблемы (аля Неуловимый Джо) нафик никому не вперлось, даже за бесплатно
23. awk 741 22.03.11 15:29 Сейчас в теме
(22)
1. Абсолютно согласен. Закрыли пункт.
2. Кажется мы смотрим на слона с разных сторон. Т.е. говорим об одном и том же. "Поиск ошибок как инструмент тестировщика для повышения качества. Повышение качества - цель. Поиск лишь инструмент, а не цель."
3. Да уберите слово "в идеале" и получите чушь несусветную, потому, что в реальном мире ошибки останутся. Эта фраза лишь маяк на который надо ориентироваться в проекте - идеальный баланс, но не ставить его целью проекта. "Инженер выявил и описал все ошибки, программисты все исправили."
4. Я придерживаюсь пословицы: "Сэкономил - считай заработал", но тут то же согласен полностью.

Перефразирую пункт 2 стати. Целью инженера по тестированию является повышение качества ПО. К сожалению это не стереотип.
24. Арчибальд 2706 22.03.11 17:21 Сейчас в теме
Полдня уже собираюсь как-то прокомментировать... Собственно стереотипы не так интересны, хотя пример из п.3 не лезет ни в какие ворота. Интересно определение. Итак,
Тестирование – это процесс поиска ошибок с целью ответить на вопрос о качестве исследуемого ПО
В определении взгляд сразу цепляется за термин "качество". А ведь никто не знает, что такое это самое качество ПО. И ISO-шные стандарты качества к реальному качеству (данному потребителю в ощущениях) отношения не имеют. ГОСТ, к примеру, связывает "достаточное" качество программы с прохождением заранее (до написания программы) согласованных тестов. Вопрос: и кто готовит эти тесты?..
Правда, такой подход сейчас считается устаревшим. Но появившаяся с тех классификация и структуризация тестирования по-прежнему не позволяет оценить программу достоверно.
А теперь озвучим "крамольную" мысль: у самого ПО вообще никакого качества нет. Оно обретается только при использовании. В словосочетании "программное обеспечение" первое слово неважно. Нет качества программ, есть только качество обеспечения (пользователя нужными ему инструментами).
И вот теперь, с позиций этого "открытия" пройдемся по стереотипам.
1. Квалификация тестировщика - это не техническая квалификация. Его задача не столько в написании тестов, сколько в предвидении "экзотических" ситуаций применения программы пользователями.
2. Ну, уж сколько накопает, столько накопает. Другое дело, что не все ошибки надо исправлять. Ошибки разные бывают.
3. Кажется, уже давно так никто не думает... К тому же, под нашим углом зрения стоит говорить не об ошибках программы, а об ошибках комплекта "ПользовательСПрограммой".
4. Утверждение ложно в сути своей. Хотя бы потому, что из него вытекает отсутствие хороших программ, написанных в одиночку.
25. СергейКа 669 22.03.11 17:30 Сейчас в теме
(24) Тоже не бесспорно.
Критерии "качества" ПО всё же есть.
Я имею ввиду качество именно написания. В некоторый код только глянешь и хватаешься за голову. У нас принято минимум двойное (а для важных разработок тройное тестирование).
Первое тестирование - именно качество написания кода: читабельность, логическая структура, скорость выполнения, использование только необходимых объектов, приличное юзабилити.
Второе тестирование - на предмет соответствия всей логике работы (конкретного бизнеспроцесса, конфигурации в целом).
Третье тестирование - на соответствие результата поставленному ТЗ, удобство работы пользователя.

В зависимости от разработки второй этап может пропускаться. Но первый и третий выполняются всегда.
26. Арчибальд 2706 22.03.11 17:42 Сейчас в теме
(25) Это у меня полемический перегиб. Конечно же есть и качество программ, и методы управления качеством при разработке...
Но в статье речь о тестировании готовой программы, так что взгляд с "противоположной" стороны оправдан.
СергейКа; +1 Ответить
27. awk 741 22.03.11 17:58 Сейчас в теме
(26) В в статье предложение к разговору. Она и озаглавлена как "размышление", а не догма.
(24)
1. Ну так и программист тогда художник. Не совсем так. Хотя без творческой жилы - теряется изюминка, которая отличает рядового специалиста от мастера, но не боги же горшки обжигают.
2. О. В точку. Копать можно отсюда и до обеда, а можно копать канаву вокруг участка.
3. А как же сливание шишек на отдел тестирования? Или когда после подписания акта приема-передачи за исправление выставляется счет?
4. Оно не ложно. Просто при написании ПО, больше чем для одного человека, в роли тестировщика выступает заказчик. Можно проверить самого себя, но нельзя поставить себе оценку.
28. Арчибальд 2706 22.03.11 17:58 Сейчас в теме
А вообще-то программы следует подвергать, как это делается в других технических отраслях, разрушающему тестированию. Т.е. фиксировать при испытаниях, при какой именно комбинации внешних воздействий программа прекращает функционировать - а такие комбинации всегда есть. Считать это программными ошибками или нет - дело вкуса. Важно же при тестировании программы очертить границы ее применимости. И если эти границы оказываются уже, чем требуется при обыденном использовании - вот тут-то можно говорить о недостаточном качестве.
Первая, основная и наиболее сложная задача тестировщика - определение границ обыденного использования. Создание же пограничных и запредельных тестов - уже попроще.
29. awk 741 22.03.11 18:15 Сейчас в теме
(28) Да мы уже от стереотипов, к методологии тестирования переходим. :D Тема я смотрю интересна.
30. Арчибальд 2706 22.03.11 18:20 Сейчас в теме
(29) Я все пытаюсь сдвинуть обсуждение от тестирования программного к тестированию обеспечения. :D
31. Nadezhda09 23.03.11 09:43 Сейчас в теме
(29)
Здравствуйте!
Да, тема интересная. И именно в контексте методологии тестирования. И мне нравится в формулировке "тестирование обеспечения",т.к. заказчик или его представитель становится активным участником процесса тестирования.
Основная проблема с ошибками заключается не в их количестве или приоритетах, а в отсутствии реального контроля и управления ПОТОКОМ ОШИБОК.
Я сама из породы "и швец, и жнец.." :)
Мой опыт работы говорит о том, что концепция тестирования уже определена и устоялась. Но не как рекомендации ISO, а в ITIL.
Соглашусь, что это не очевидно и спорно.
Но работает эффективно.
Суть простая. ПОТОК ОШИБОК не однороден:
- инциденты - ошибки, без которых продукт не работает или выдает очевидно ошибочный результат.
Сколько бы их ни было и кто бы их ни находил, их необходимо исправлять в любом случае и первоочередно.
- изменения - проверяются на соответствие ТЗ. Признаются ошибками только при явном несоответствии. Исправляются обязательно.
Изменения в программном коде, не прописанные в ТЗ или прописанные ошибочно, некорректно, недостаточно, вносятся по договоренности сторон (заказчик-разработчик), за дополнительную плату и в отдельные сроки.
- проблемы - ошибки, для разрешения которых существует обходное решение без исправления программного кода.
Вносить исправления или не вносить - решается так же - по договоренности сторон.
Разделяй и властвуй.
Разделяя ПОТОК ОШИБОК, мы получаем возможность его контролировать и регулировать. :)
Сами понимаете, управляемый процесс лучше, чем не управляемый :)
Ну вот где-то так..
32. awk 741 23.03.11 11:14 Сейчас в теме
(31) И так приходим выводам:
Необходимые условия тестирования:
1. Документация.
2. Система учета и классификации ошибок.

Кто дополнит?
33. Nadezhda09 23.03.11 12:14 Сейчас в теме
(32)
Совершенно согласна!
Отсюда следуют и требования, предъявляемые к знаниям/квалификации тестировщиков и регламенту их работы.
Дополняю:
3. Регламент работы тестировщиков.
Минимум - отлавливать ошибки, которые собственно ошибки, плюс знание ТЗ и ошибки из-за несоответствия ТЗ.
Максимум - плюс класс псевдо-ошибок типа медленно работает, поедает ресурсы, некрасивый код, некрасивые формы/отчеты, неудобство работы и т.п. Если, конечно, получится четко утвердить регламент :)

4. Методы регламентирования.
Все, что удалось регламентировать, сдали на плечи тестировщиков :)
Нет смысла спрашивать с них чего-то сверх регламента - они не отвечают за качество ПО.
34. awk 741 23.03.11 13:47 Сейчас в теме
(33)
класс псевдо-ошибок типа медленно работает, поедает ресурсы, некрасивый код, некрасивые формы/отчеты, неудобство работы

1. Медленно работает - если в документации есть пункт, что работать должно на наборе железа + софта, не более 10 сек, а работает 10.1 - это не псевдоошибка - это баг. Если в документации таких критериев нет, а работает медленно - то это повод протестировать документацию и дополнить как особенность реализации или все-таки включить требования к производительности.
2. Поедает ресурсы см. пункт 1.
3. Если на фирме принята польская нотация, то она должна быть. Отсутствие ее - баг. Если таких критериев нет - то это фича.
4. Некрасивые формы/отчеты, неудобство работы - если проект под заказчика, то скорее UI будет описан жестко. Если тиражируемый продукт, то тут отдельная тема для разговора. В любом случае, после фиксирования в документации - сверяем с документацией.
они не отвечают за качество ПО
Качество ПО - это цель тестирования, поэтому тестировщиков рекомендуется подключать к проекту на самых ранних его стадиях. Хотя делать из них козлов отпущения - то же не стоит. :)
35. Nadezhda09 23.03.11 14:02 Сейчас в теме
(34)
awk пишет:
1.
2.
3.
4.
..- сверяем с документацией.

Хорошо сказано. Поняла - это входит в п.1 Документация :)
awk пишет:
Качество ПО - это цель тестирования

Цель тестирования - проверка на соответствие регламентированным критериям качества.
36. awk 741 23.03.11 14:25 Сейчас в теме
(35)
Цель тестирования - проверка на соответствие регламентированным критериям качества.

Создание этих критериев может происходить (а зачастую и происходит) в процессе тестирования. Поэтому, это скорее инструмент (способ достижения результата), а не результат.

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

Как-то так.
37. Nadezhda09 23.03.11 14:55 Сейчас в теме
awk пишет:
Создание этих критериев может происходить (а зачастую и происходит) в процессе тестирования.

И да, и нет.
"Нет", если процесс тестирования понимать узко, как процесс выявления ошибок и несоответствий - чисто работа тестировщика.
И "да", если понимать широко, как часть процесса управления качеством.
Но в любом случае, подчеркиваю то же самое, необходимость регламента работы тестировщика. Все-таки создание критериев качества - это нечто бОльшее.
Даже если ты "и швец, и жнец", опять же - разделяй и властвуй: вот сейчас я играю роль тестировщика и должен руководствоваться регламентом. А вот сейчас я уже менеджер процесса управления качеством и, анализируя процесс тестирования, выявляю новые или уточняю старые критерии. Очень четкие границы! Они разделяют Обязательное и Желательное. Выполнение желательного можно оспорить. Невыполнение обязательного грозит последствиями :)
38. awk 741 23.03.11 19:01 Сейчас в теме
(37)Узко его можно понимать, только в рамках большого проекта, когда есть: Старший инженер - разрабатывающий тесты и несколько рядовых выполняющих тесты.

1. Крохотный проект (1 программист, 1 заказчик). Программист не может проверять (но не значит что не должен) - тестировщик заказчик.

В этом варианте говорить о полноценном тестировании как-то не с руки. Тут любое лишние телодвижение ведет к растягиванию сроков(увеличению стоимости проекта). Так что и ТЗ скорее всего будет очень условным и приемка "на глазок".

2. Маленький проект (2 программиста, 1 заказчик).

Тут кроме парного программирования что-то придумать сложно. Может аутсорсинг только.

3. Средний проект (n программистов, n/2 тестировщиков, 1-3 заказчика)

Пока нет "Старшего" - каждый тестеровщик сам создает тесты и т.д. Зачатки узкого разговора.

4. Крупный проект (n программистов, n/2 тестировщиков, руководители и т.д.)

Тут короли специалисты узкого профиля. Тут уже можно достаточно узко говорить о роли тестировщика и широко о роли отдела тестирования.
39. Nadezhda09 24.03.11 06:51 Сейчас в теме
(38)
Вы правы - безусловно (!) нужно уметь оценивать реалии.
И не только масштабы кампании, проекта, клиента-заказчика. Но и собственную роль и значимость в проекте - что дозволено Юпитеру, то не дозволено быку. Если я рядовой программист, то могу иметь работающие методики чтобы организовать по уму собственный рабочий день. Но это не означает, что могу организовать или имею право добиваться такой же организации в рамках департамента по ИТ.
Как говорится: если хочешь изменить мир, начни с себя :)
40. ilov_boris 163 28.11.12 21:12 Сейчас в теме
Плюс. Побольше бы таких статей.
41. Модератор раздела 29.11.12 14:06 Сейчас в теме
1. ИМХО отрицание 4-го стереотипа "программист может сочетать в себе роль инженера по тестированию" совершенно неверно.
Программист должен и может выполнять роль тестировщика.
1. Как иначе он проверит работу своего же приложения/системы?
2. Очень популярная и эффективная методика TDD как раз и предлагает программисту выступить в качестве тестера.
>>скорее всего не будет проводить тесты с третьего по восьмой из прошлого примера
как раз в TDD он быстро напишет все эти тесты (хотя пару тестов вполне может и пропустить, это не страшно) и забудет о них до тех пор, пока он не ошибется в реализации метода, для которого и пишутся эти тесты.

2. Отрицание 2-й стереотипа также неверно. Если роль сотрудника - только тестер, то он должен находить максимум ошибок. Если же он совмещает еще и другие роли, тогда нужно искать компромисс между количеством ошибок и другими функциями.
42. awk 741 29.11.12 15:02 Сейчас в теме
(41) artbear,
По четвертому стереотипу:
1. Проверка != Тестирование; Проверка это подмножество Тестирование
2. TDD при всей ее эффективности и популярности имеет ряд отрицательных качеств можно почитать в википедии, а от себя могу добавить:

* Стресс при парном программировании
* Неэффективное использование ресурсов (при их наличии) написание несложного кода высокооплачиваемыми членами команды
* Каждый может внести баг (при коллективном владении кода)

По второму пункту:

1. Роль - только тестировщик
2. Что значит максимум? Если тестировщик находит ошибок больше, чем исправляют, то это показатель кризиса отдела разработки (либо программисты тупы, что столько допускают, либо их мало и исправлять не успевают).

P.S. Тестер - это прибор, а должность называется: "Инженер по тестированию".
43. Модератор раздела 29.11.12 16:47 Сейчас в теме
1. ТДД и отрицательные качества - у любой методики есть минуса, иначе бы не придумывались новые методики.
Про парное - не скажу, в реальности его не юзал.
Про ресурсы не согласен, сам юзаю ТДД, эффективность работы разработчика только возрастает.
про внесение бага - при правильном использовании ТДД баги очень быстро ловятся и фиксятся, проверено.
2. Смысл работы тестировщика - не зависеть от отдела разработчика, а находить ошибки независимо. если ошибки не исправляются, это не проблема тестера/тестировщика.
Если утрировать твою фразу, тестировщик может найти одну ошибку и ничего не делать, пока ошибка не будет исправлена.
PS пятый стереотип ввел про тестера? :(
Будем терминологией бросаться между собой? набери тестер в поисковике или тестер в википедии.
имхо оба термина имеют хождение и право на хождение.
44. awk 741 29.11.12 17:05 Сейчас в теме
(43) artbear,
Будем терминологией бросаться между собой?

Нет. Просто Пожарных пожарниками часто называют, на что те обижаются.

Если утрировать твою фразу, тестировщик может найти одну ошибку и ничего не делать, пока ошибка не будет исправлена.
Может, когда:
1. Если это единственный баг, а ПО не изменяется. (Например программа должна выводить картинку на экран, а выводит на принтер).
2. Если баг критический. (Не стартует программа)
3. Если его отчеты систематически игнорируются (очень эффективный метод воздействия). Он уже выполнил свою функцию, продолжать нет смысла.
4. Если после баг репорта вышел новый релиз.

ТДД:
эффективность работы разработчика только возрастает

Не спорю. Эффективность разработчика возрастает. НО.. Эффективность использования разработчика падает.

про внесение бага - при правильном использовании...


При правильном...
45. Модератор раздела 29.11.12 17:34 Сейчас в теме
(44)
Эффективность разработчика возрастает. НО.. Эффективность использования разработчика

1. Не разделяю эти понятия, говорил об обоих.
2. Про внесение бага - мы же говорим только о правильном применении методики.
46. awk 741 29.11.12 17:50 Сейчас в теме
(45) artbear,
говорим только о правильном применении методики
Ух, ка бы было хорошо, если бы было все, всегда правильно...
Не разделяю эти понятия
Тут играет эффект масштаба. Чем больше масштаб проекта, тем сильнее тяга к специализации. И наоборот. Принцип управления №1 по Файолю.
Оставьте свое сообщение