Путь тестировщика

А что Вы называете средним или большим проектом? Можно узнать количественные оценки?

Мои оценки следующие:
Если в проекте осталось 50 нераскрытых ошибок, то он может работать, и тестеры не нужны.
При стандарте 10 ошибок на 1000 строк кода, это проект в 5 тыс. строк.

Ну по поводу нераскрытых ошибок уже есть вопрос...
А если из этих 50 десяток блокеров, то что? Разработчики сами будут за ними гоняться?

Ну есть какие-то методики оценки оставшихся ошибок, например подмешивание ошибок в проект и вычисление процента выловленных подмешанных ошибок, думаю есть и другие способы.
А насчет 500 ошибок на 1000 строк, я бы такой проект выкинул :)
Не нужны там тестировщики.
Я понимаю, что если платить за найденные ошибки, то на таком проекте можно много денег срубить и хорошо нагреться. Но я о таких проектах не мечтаю.
Насчет блокеров вопрос конечно интересный. Но, честно говоря, ничего не могу придумать в оценке величины проекта кроме числа строк кода. Хотя бывают и исключения. Но согласитесь, что чем больше проект, тем нужнее тестеры.

Но согласитесь, что чем больше проект, тем нужнее тестеры.

Не всегда. Скорее чем сложнее проект тем больше надо тестеров, так как и багов там должно бить больше.

Мне видимо попался специфический тестировщик, который считает, что главное - устойчивость программы, поэтому первым делом пытается ее завалить.

Это по первой у всех так :) Кстати, к устойчивости никакого отношения :)

А вот еще вопрос: читают ли программисты литературу по тестированию?

Хорошие - читают.

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

Дело в тестах. Тест он и говорит то ли делает программа что хотел заказчик или нет.

PS
В тестироание идите. Из разработчиков получаются хорошие тестеры.

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

Интересный метод. Научный, но ИМХО бесполезный. Всё равно никто не скажет сколько осталось - а догадываться можно и без подмешивания.

А насчет 500 ошибок на 1000 строк, я бы такой проект выкинул :) Не нужны там тестировщики.

Ны про выкинте разговор то обычно не идёт ;)

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

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

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

Интересный метод. Научный, но ИМХО бесполезный.

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

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

Например, Wikipedia http://en.wikipedia....ientific_method говорит следующее о научном подходе:

"The scientific method or process is fundamental to the scientific investigation and acquisition of new knowledge based upon physical evidence. Science manages new assertions about our world with theories — hypotheses and observations. Predictions from these theories are tested by experiment. If a prediction turns out correct, the theory survives, but if a prediction fails the theory fails."
...
"The scientific method's essential elements are iterations and recursions of the following four steps:
- Characterization
- Hypothesis (a theoretical, hypothetical explanation)
- Prediction (logical deduction from the hypothesis)
- Experiment (test of all of the above)"
...
"The scientific process is iterative. At any stage it is possible that some consideration will lead the scientist to repeat an earlier part of the process. Failure to develop an interesting hypothesis may lead a scientist to re-define the subject they are considering. Failure of a hypothesis to produce interesting and testable predictions may lead to reconsideration of the hypothesis or of the definition of the subject. Failure of the experiment to produce interesting results may lead the scientist to reconsidering the experimental method, the hypothesis or the definition of the subject."

Вообще, почитайте эту статью в википедии, очень интересно и помогает постижению философской сути тестирования :)

Вот почти одновременно с нашим обсуждением (даже чуть раньше, упредив события :)) Элизабет Хендриксон опубликовала замечательную заметку It's a Great Time to be a Tester

Вот почти одновременно с нашим обсуждением (даже чуть раньше, упредив события :)) Элизабет Хендриксон опубликовала замечательную заметку It's a Great Time to be a Tester

Да, хорошая статья, все мне понравилось, особенно "Big Picture", я как раз пытаюсь охватить ситуацию в целом, а не углубляться в подробности.
Если продукт тиражный (очень тиражный), то придется моделировать поведение различных пользователей - китайца, эфиопа, зулуса, которые ведут себя за компьютером совершенно по-разному.

А вот еще вопрос, в котором хотелось бы разобраться: соотношение QA и тестинга.
Иногда видишь вакансию: "требуется QA", а в тексте пишут про навыки тестирования. Но ведь это не одно и то же?
Где-то вычитал, что QA следит за правильностью процесса, то есть чтобы все делалось по-правилам (программирование, тестирование и пр.), а тестер проверяет то, что получилось, неважно как это было сделано.

Игорь

Про тестировщика-разрушителя - в этом есть доля правды ;-)
Некоторые мои знакомые, которые действительно хорошие тестировщики, имеют необъяснимую особенность заваливать приложения (тот же офис и т.п.) чаще других. Может любят "тестировать" кнопочки, на котоые другим пользователям наплевать?
:-))

По поводу тестирования и QA уже писали на форуме. Приведу высказывание SALar:

Контроль качества и тестирование это разные вещи. Тестировщик имеет дело с продуктом, а контролер качества (QA) с процессом. Так например QA может разрабатывать правила подачи объяснительной в случае опоздания в колбасном цехе мясокомбината. Это не совсем тестирование ПО.

А вот еще вопрос, в котором хотелось бы разобраться: соотношение QA и тестинга.
Иногда видишь вакансию: "требуется QA", а в тексте пишут про навыки тестирования. Но ведь это не одно и то же?
Где-то вычитал, что QA следит за правильностью процесса, то есть чтобы все делалось по-правилам (программирование, тестирование и пр.), а тестер проверяет то, что получилось, неважно как это было сделано.

Игорь

Насколько я понимаю, никто толком не знает, что именно входит в обязанности QA и каждый толкует это по своему :)
Такое это расплывчатое понятие. Почти такое же расплывчатое, как само понятие качества.

Вот поэтому и пишут, что хотят реально видеть, а называют QA.

Насколько я понимаю, никто толком не знает, что именно входит в обязанности QA и каждый толкует это по своему :)
Такое это расплывчатое понятие. Почти такое же расплывчатое, как само понятие качества.

Значит время QA-йщиков еще не наступило, а сейчас время тестеров :)

QA-ки действительно пока определяются весьма по-разному.
Хотя исходя из названия - Quality Assurance - должны заниматься именно гарантией качества - то есть правильный процес налаживать, чтоб как можно меньше было возможностей это качество испоганить ;-)
А тестировщики - это вторая часть системы качества - Quality Control.

Иногда видишь вакансию: "требуется QA", а в тексте пишут про навыки тестирования. Но ведь это не одно и то же?

На Западе тестировщиков, как правило, называют QA Engineers, а не Testers. Даже если никаких собственно QA обязанностей и не предполагается. Думаю отсюда ноги растут с путаницей названий.

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

Если закон распределения ошибок неизвестен, то получается, что научный подход невозможен, то есть надо просто развивать звериное чутье тестировщика и искать ошибки по наитию. Как грибы. А тут все зависит от практики.
Программы пишут люди, а их смоделировать очень трудно, логике они не подчиняются, можно ли считать психологию наукой? Мы ведь тестируем не реальный мир, а некие искусственные конструкции, которые сами же люди и создают.
Недаром тестирование считается творческой профессией. Это ближе к искусству а не к науке.

Игорь

Поздравьте меня, я стал тестировщиком!

Вэлкам!!!

Но, честно говоря, ничего не могу придумать в оценке величины проекта кроме числа строк кода. Хотя бывают и исключения. Но согласитесь, что чем больше проект, тем нужнее тестеры.

Не соглашусь - чем сложнее проект, тем нужнее тестировщики.
У нас есть одна функция, которая состоит из примерно 300 строк, на тестирование этой функции было потрачено более 500 человеко-часов. Тогда как на тестирование всего остального порядка 2000 человеко-часов. Все остальное, это примерно 600-700 тысяч строк кода (давно не пересчитывал, точно сказать не смогу).

Поищите определение functional points, это должно помочь, ну и заодно что нибудь про цикломатическую сложность функций.

Ну и про куа и куце. Куа просто звучит круче, а то знаем мы, что такое тестер - это такая хреновина со стрелкой и двумя проводами ;)

PS: поздрамлямс