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

[airguru]

Вы думаете, один сможет? Типа: "в этой области я нашел 2 бага, в той 6 а в той 10. Ни одну область не протестировал до конца." А статус-то каков?

Не так. )
"В этой области я протестировал вот столько ХХ юзкейсов, в той- YY. В каждой из них всего- примерно XXXX и YYYY (В тестплане мы, конечно, укажем сколько, но оставим запас на всякий случай)). " Таким образом примерный статус проекта можно оценить. И прикинуть время до окончания.

[airguru]

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

• "Это моя игрушка": тестировщик привыкает к продукту, холит и лелеет его, отлично знает все тонкости, привычки и слабые места, после каждого раза, когда отданный "поиграть" разработчикам продукт возвращается от них - тщательно и ревностно проверяет, не сломали ли что-нибудь эти чужие дяди. Перевод на другой проект расценивает как личную трагедию.
• "Это моя новая игрушка": сломя голову набрасывается на новый продукт, быстро осваивается в нем, находит серьезные проблемы, требует их немедленно исправить, пытается пилить бензопилой стальные балки; с уменьшением числа открытий успокаивается и теряет интерес. Глаз замыливается, внимание снижается, эффективность падает. "Заточение" на одном проекте считает личной драмой.

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

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

[Clauster]

Вы думаете, один сможет? Типа: "в этой области я нашел 2 бага, в той 6 а в той 10. Ни одну область не протестировал до конца." А статус-то каков?

Не так. )
"В этой области я протестировал вот столько ХХ юзкейсов, в той- YY. В каждой из них всего- примерно XXXX и YYYY (В тестплане мы, конечно, укажем сколько, но оставим запас на всякий случай)). " Таким образом примерный статус проекта можно оценить. И прикинуть время до окончания.

Да разве это статус проекта? Это отчет о проделанной работе и план на будущее.

[airguru]

Вы думаете, один сможет? Типа: "в этой области я нашел 2 бага, в той 6 а в той 10. Ни одну область не протестировал до конца." А статус-то каков?

Не так. )
"В этой области я протестировал вот столько ХХ юзкейсов, в той- YY. В каждой из них всего- примерно XXXX и YYYY (В тестплане мы, конечно, укажем сколько, но оставим запас на всякий случай)). " Таким образом примерный статус проекта можно оценить. И прикинуть время до окончания.

Да разве это статус проекта? Это отчет о проделанной работе и план на будущее.

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

[Clauster]

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

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

[LeshaL]

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

На это есть руководители, и есть всякие средства, например дефект-трэкеры или какие-то критерии(метрики), на основе которых и должны (по идее) делаться выводы по поводу статуса проекта. Не важно кто осуществляет контроль качества.

Скажите, а зачем тогда тестировщики?

Судя по вашим коментариям здесь и в других ветках, вы человек не новый в тестировании и странно услышать такой вот вопрос.
Но всеж отвечу так: ни дефекты в трэкере, ни основания для метрик\критериев не возникают из ниоткуда. Кто-то их должен предоставить, а собственно это одна из задач тестирования - предоставить необходимую информацию для оценки качества проекта в тот или иной момент времени. Какими методами это получено - вопрос вторичный и depends on. Если надо то можно и после 2-3 найденых дефектов перепрыгивать с одной задачи на другую. Я же, пытаюсь мыслить несколько более глобально, чем изначальный пост, не в рамках одно инженера, пары найденых багов и недели работы на одном и том же. Пытаюсь развить идею далее, перенося ее на команду, задачи\подсистемы и циклы тестирования.

[Clauster]

Скажите, а зачем тогда тестировщики?

Судя по вашим коментариям здесь и в других ветках, вы человек не новый в тестировании и странно услышать такой вот вопрос.
Но всеж отвечу так: ни дефекты в трэкере, ни основания для метрик\критериев не возникают из ниоткуда. Кто-то их должен предоставить, а собственно это одна из задач тестирования - предоставить необходимую информацию для оценки качества проекта в тот или иной момент времени. Какими методами это получено - вопрос вторичный и depends on. Если надо то можно и после 2-3 найденых дефектов перепрыгивать с одной задачи на другую. Я же, пытаюсь мыслить несколько более глобально, чем изначальный пост, не в рамках одно инженера, пары найденых багов и недели работы на одном и том же. Пытаюсь развить идею далее, перенося ее на команду, задачи\подсистемы и циклы тестирования.

Ничего странного. Социологическое исследование. Ищем единомышленников.

[LeshaL]

У меня был случай. Пришлось тестировать 4-е активных (по ним велась разработка) проекта одновременно. Это был просто кошмар. После месяца такой работы я был выжат как лимон. При этом не было большой уверенности в качестве тестирования. Практически везде удавалось проводить только smoke tests.

С другой стороны, плохо когда специалист занимается одним проектом в течение нескольких лет. Видел я и таких. И у самого была парочка таких проектов. Работа превращается в рутину и не доставляет удовольствия.

Черт кроется в деталях.

Сергей,
полностью согласен, работать одновременно над несколькими активными (еще хуже, если никак не связанными) проектами - это ужас. Работать же над несколькими разными частями одного проекта попеременно - это вполне естественно и не только для инженеров по тестированию. Просто на долю тестеров достается больше подсистем, т.к. обычно отношение девелопер/тестер в компаниях обычно не меньше 3/1. А отношение количества функциональности на одного инженера по тестированию м.б. еще больше, с учетом тех подсистем, которые (условно) не модифицировались в предстоящем релизе.

[LeshaL]

Ничего странного. Социологическое исследование. Ищем единомышленников.

Позвольте поинтересоваться, как успехи?

[Clauster]

Ничего странного. Социологическое исследование. Ищем единомышленников.

Позвольте поинтересоваться, как успехи?

Они есть, что не может не радовать.

[airguru]

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

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

[Clauster]

а как статус- это можно отдавать заказчику или нельзя. ))

Тестировщику в принципе нельзя давать принимать такие решения. Не ИМХО.

[airguru]

Тестировщику в принципе нельзя давать принимать такие решения. Не ИМХО.

угу
у тестировщика свой статус проекта, у его руководителя- свой, на основе статуса тестировщика.

[Case]

а как статус- это можно отдавать заказчику или нельзя. ))

Тестировщику в принципе нельзя давать принимать такие решения. Не ИМХО.

А кому можно? Именно в разрезе "готово - не готово".

[Galina]

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

Как-то вот так!

[Clauster]

а как статус- это можно отдавать заказчику или нельзя. ))

Тестировщику в принципе нельзя давать принимать такие решения. Не ИМХО.

А кому можно? Именно в разрезе "готово - не готово".

Ну везде по-разному, от ПМ-а до топ-менеджмента и самого заказчика я думаю. Для тестировщика такая роль непосильна, иначе на него потом всех собак будут спускать.

[Case]

А они откуда берут информацию для принятия решения?

[Boltick]

Мне кажется все намного проще или может сложнее - it depends :)

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

Допустим пример:
Есть некоторые критерии:
1. кол-во критический багов - 0
2. кол-ва мажоров - < 10
... и т.д. критериев может быть много, но для примера хватит тех, что я привел.

И есть ситуация, где на проекте 3 открытых критических бага и 20 мажоров.

Что можно сказать по статусу проекта - Готов он или нет?

Сразу видно, что критерии не выполняются, т.е. проект не готов.


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

[Clauster]

А они откуда берут информацию для принятия решения?

Я понимаю к чему вы клоните. Бывает, что тестировщиков даже не спрашивают :) С другой стороны, я слышал от одного тестировщика, как он мечтает накладывать вето. Да, это возможно, чтобы тестировщик выдавал статус готово\не готово. Но это должен быть тестировщик с определённым уровнем ответственности и компетентности, например, ведущий инженер. С простого тестировщика требовать такой статус просто не выгодно.

[Case]

Если не спрашивают статус - то накой он нужен? :) Баги заводить, чтобы "девелоперы без работы не сидели"?

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

PS
К разговору про развите отдела тестирования - такой статус является показателем зрелости.