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

[airguru]

Вероятно описанное ниже для некоторых вовсе не является откровением :) , но я в литературе этого не встречал. пока что... может мало читал?..
И ставлю вопрос для поиска возможных минусов описанного подхода и возможностей, идей к его совершенствованию.

А суть метода вот в чем (Рассмотрим ручное функциональное тестирование): В случае, когда есть несколько областей для тестирования (если их нет- то можно их выделить искусственно. Но они должны быть достаточно дистанциированы друг от друга (на вопрос почему- ответ ниже))- проводим тестирование сначала в одной обасти, потом в другой и т.д. по кругу. (так и назовем "круговое" :))
И в каждой области тестируем до нахождения одного-двух багов или ограничиваем по времени, чтобы не зацикливать мозг, внимание, память на одной конкретной области.
2ю неделю пробую- результатом доволен. При таком подходе реально не привыкаешь к софту (или его области)- каждый раз смотришь на него с недоверием. + пока тестишь в одной- обдумаваешь ситуации в другой области и когда возвращаешься к ней- 90% либо повторишь дефект, который не смог повторить до этого, либо новых найдешь.

Такая вот мысль...

[airguru]

так что, коллеги,- ни у кого нет вообще никаких мыслей по сабжу?

[alex7kir]

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

[Mongol]

Кое-где практикуется подход, когда каждые две-три недели (где как, может меньше, может больше) тестеры меняются областями - суть та же, но возведенная в политику фирмы :)

[nsimonov]

В случае, когда есть несколько областей для тестирования (если их нет- то можно их выделить искусственно.

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

[airguru]

В случае, когда есть несколько областей для тестирования (если их нет- то можно их выделить искусственно.

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

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

[Bars Master]

Если модули будут слишком обширны по функциональности, и глубоки по объему то с точки зрения управления группой, можем получить ряд специалистов которые разбираются "везде по чуть-чуть"

[Clauster]

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

[LeshaL]

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

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

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

Плюсы работодателю:
1. Становится меньше (или вообще исчезают) "незаменимые люди".
2. Одна голова хорошо, а две лучше.
3. Если тестовую документацию пишет один человек(тест кейзы, чек-листы итд), а тестирует по ним другой, то находятся проблемы не только в ПО, но и в тестах.
4. Появляется более сбалансированная команда, где обучение происходит peer-to-peer, просто в процессе работы. Надо меньше треннигов, семинаров и тд.
5. Есть возможность получить "более хорошего" тестера для той или иной подсистемы не нанимая нового сотрудника.
6. Переключение в новую область зачастую влечет повышение мотивации сотрудника без каких либо материальных затрат (читай не надо зп поднимать, чтобы стимульнуть).
7. Опять же, есть возможность принимать на работу не профессионала, а новичка, и в дальнейшем выращивать его до опытного сотрудника будет проще.

Плюсы работникам:
1. Переключение в новую область дает новые знания.
2. ....как бы это сформулировать... тестирование новой (под)системы или технологии может дать толчок для применения этих знаний о технологии, полученных при тестировании, для тестирования(и не только) другой подсистемы. Со мной например, не раз такое происходило. Например, тестировал парсер C# кода не зная язык, а имея только существующие тест-кейзы. а) пришлось немного поизучать C#, чтобы доработать тесты; б) в последствии (через 1.5 года не имеющих отношения к C#) перешел в команду автоматизации и писал автоматические тесты на C# для C# приложения - плагина к визуал-студии.
3. Возможность показать, что ты лучше, чем твой коллега ;)
4. Понимание того, что то что ты делал раньше, нравится тебе меньше, чем то, чем ты занимаешься сейчас. Конечно, профессионал не должен так думать - работа есть работа - но все мы люди и работа работе рознь.
5. Ну и как вариант, понимание работником отношения к нему его руководства. Брал больше всех отгулов? Работал спустя рукава? Получи рутинную скучную работенку. Проявлял активность? Непобоялся добиться решения неприятной проблемы? Получи более интересную и творческую задачу.

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

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

[DrVal]

На самом деле такая модель есть, только называется "спиральная", а не "круговая".

Модель разработки и тестирования ПО значительно зависит от контекста проека.
Сама по себе модель может быть замечательной, но плохо ложиться на конкретный проект.

[Clauster]

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

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

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

[airguru]

Если модули будут слишком обширны по функциональности, и глубоки по объему то с точки зрения управления группой, можем получить ряд специалистов которые разбираются "везде по чуть-чуть"

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

[airguru]

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

Как вариант- коллекционировать информацию о ходе тестирования независимо у руководителя и у тестировщика, который наиболее долго находится при тестировании одной области. С последующим сравнением результатов и передачи информации от тестировщика к другому сменяемому тестировщику и руководителю. Можно еще попробовать некий средний процент прикинуть от информации от каждого тестера в одной области. Ведь смогут же они дать оценку, хоть и не точную...
А вообще зависит от системы оценки "количества проделанной/оставшейся работы" :) принятой в компании. Ведь можно/нужно заранее выработать критерии оценки. Например, количество найденных багов в единицу времени, ведь если несколько человек поработав определенное время над одной и той же областью (не все вместе, а по очереди), не нашли новых багов или количество несравнимо мало с предыдущими, можно говорить о подходе тестирования конкретной области к концу.

[airguru]

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

ЗЫ- в любом случае буду рад почитать комментарии и возражения))

[Clauster]

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

Как вариант- коллекционировать информацию о ходе тестирования независимо у руководителя и у тестировщика, который наиболее долго находится при тестировании одной области. С последующим сравнением результатов и передачи информации от тестировщика к другому сменяемому тестировщику и руководителю. Можно еще попробовать некий средний процент прикинуть от информации от каждого тестера в одной области. Ведь смогут же они дать оценку, хоть и не точную...
А вообще зависит от системы оценки "количества проделанной/оставшейся работы" :) принятой в компании. Ведь можно/нужно заранее выработать критерии оценки. Например, количество найденных багов в единицу времени, ведь если несколько человек поработав определенное время над одной и той же областью (не все вместе, а по очереди), не нашли новых багов или количество несравнимо мало с предыдущими, можно говорить о подходе тестирования конкретной области к концу.

А теперь внимательно перечитываем первое сообщение в ветке. Тестирует один тестер и переключается при нахождении 2-3 ошибок. Вы тут уже перефантазировали, коллеги.

[Yuliana]

Модель разработки и тестирования ПО значительно зависит от контекста проека.
Сама по себе модель может быть замечательной, но плохо ложиться на конкретный проект.

Добавлю еще - от размера команды, уровня ее квалификации и сроков. А вообще я тоже люблю эту модель, особенно за то что при ее применении не страшно, что будет, если кто-то из тестеров умрет:))

[Green]

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

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

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

[airguru]

А теперь внимательно перечитываем первое сообщение в ветке. Тестирует один тестер и переключается при нахождении 2-3 ошибок. Вы тут уже перефантазировали, коллеги.

Так один-то сможет сделать оценку того, что он уже сделал и того, что еще предстоит. Я в том (8го 17:01) посте предположил, что работает команда, соответственно мнений много.

[Clauster]

А теперь внимательно перечитываем первое сообщение в ветке. Тестирует один тестер и переключается при нахождении 2-3 ошибок. Вы тут уже перефантазировали, коллеги.

Так один-то сможет сделать оценку того, что он уже сделал и того, что еще предстоит. Я в том (8го 17:01) посте предположил, что работает команда, соответственно мнений много.

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

[rlabs]

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

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

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