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

[Stasde]

1. В проекте, в котором заняты, скажем, 7 разработчиков, и где нет спецификаций, - работает тестировщик, студент; работает и учится, т.е. работает не full-time. Проект долгосрочный, скажем, уже прошло полгода и еще конца края не предвидется.

1.1. Достаточно ли такой занятости для серьезного проекта?
1.2. Каковы плюсы и минусы такого подхода?

2. И еще подход - когда тестировщика переводят с проекта на проект - 2 недели там, месяц в другом проекте, потом опять на старый проект на 1 месяц.

2.1. Каковы плюсы и минусы такого подхода?

3. И еще: тест кейсы пишутся в начале проекта. Это правильная практика. Кто как использует документ с тест кейсами _потом_ (если это именно документ скажем в Word)?

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

Если так происходит, то в чем плюсы и минусы составления тест кейсов именно в таком документе Word или Excel, который не дает сам по себе возможности управления тестами и т.д., что позволяет, например, Mercury TestDirector.

[Clauster]

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

[Romich]

Я работаю на проэкте с 8 программистами. Ничего хорошего от того, что я сам пока еще не было. Программеры кодят каждый под свой лад и только я один могу сказать как надо согласно общим стилям, которые эволюционируют со временем. Поскольку программерам платят больше, то оказалось самым эффективным взять новых тестеров.
Сейчас у нас работа построена следующим образом. Программерам на каждую компоненту (их в приложении несколько сотен) приходит спецификация. Они делают внешний вид и все явное, что заметят. Далее в ход иду я. Я тестирую компоненту, нахожу все баги и несоответствия спеке (30-40 багов). Далее программисты точно знают, что им нужно делать и работают на много быстрее, поскольку все исследования (а это 50% всего времени) по проблемным вопросам делаю я (скрытая функциональность и пр.). При таком подходе надо хотя бы 1 тестер на 3 программера.

[Kaluga]

1. В проекте, в котором заняты, скажем, 7 разработчиков, и где нет спецификаций, - работает тестировщик, студент; работает и учится, т.е. работает не full-time. Проект долгосрочный, скажем, уже прошло полгода и еще конца края не предвидется.

Последнюю фразу можно было не говорить. После "7 разработчиков и одного тестера-студента" это очевидно.

1.1. Достаточно ли такой занятости для серьезного проекта?

Нет

1.2. Каковы плюсы и минусы такого подхода?

Сплошные минусы. Плюсы отсутствуют.

2. И еще подход - когда тестировщика переводят с проекта на проект - 2 недели там, месяц в другом проекте, потом опять на старый проект на 1 месяц.

Плохой подход. Много времени тратится на "перезагрузку" тестера.

2.1. Каковы плюсы и минусы такого подхода?

Минус я описал. А какие Вы плюсы нашли?

3. И еще: тест кейсы пишутся в начале проекта. Это правильная практика.

Вы то вопросы задаете, то выдаете аксиомы (с Вашей точки зрения)...

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

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

Если так происходит, то в чем плюсы и минусы составления тест кейсов именно в таком документе Word или Excel, который не дает сам по себе возможности управления тестами и т.д., что позволяет, например,  Mercury TestDirector.

Плюс Ворда и Экселя в том, что они проще, чем ТестДиректор. Не надо персонал обучать. И дешевле. :) Но это сомнительный плюс в наших реалиях.

[Netrat]

1. В проекте, в котором заняты, скажем, 7 разработчиков, и где нет спецификаций, - работает тестировщик, студент; работает и учится, т.е. работает не full-time. Проект долгосрочный, скажем, уже прошло полгода и еще конца края не предвидется.

1.1. Достаточно ли такой занятости для серьезного проекта?

Проект без спецификаций НЕ МОЖЕТ быть серьёзным. О чём вы говорите? ;-|

1.2. Каковы плюсы и минусы такого подхода?

Плюсы - дешевизна: студент без опыта на part-time согласится работать за копейки.

Минусы - качество на нуле.

2. И еще подход - когда тестировщика переводят с проекта на проект - 2 недели там, месяц в другом проекте, потом опять на старый проект на 1 месяц.

2.1. Каковы плюсы и минусы такого подхода?

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

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

3. И еще: тест кейсы пишутся в начале проекта. Это правильная практика. Кто как использует документ с тест кейсами _потом_ (если это именно документ скажем в Word)?

Тест-кейсы в составе сценариев тестирования должны использоваться при КАЖДОЙ полной итерации тестирования.

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

Бывает.

Если так происходит, то в чем плюсы и минусы составления тест кейсов именно в таком документе Word или Excel, который не дает сам по себе возможности управления тестами и т.д., что позволяет, например,  Mercury TestDirector.

А не надо закручивать шурупы (к тому же, крестовые) пилочкой для ногтей. :-) Ставьте TestDirector и будет вам счастье.

Плюсы - не надо покупапть и внедрять TestDirector, осваивать работу с ним.

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