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

[Snap]

Вопрос такой - сколько у вас в отделе тестировщиков занимается ручным тестированием и сколько автоматизацией тестирования, если таковая присутствует? В первую очередь интересует WEB.
Понятно, что все это побольшей степени условно и зависит от множества факторов, но все таки мне было бы интересно узнать примеры.
Сам я знаю ситуацию в некоторых компаниях и вижу, что над одним проектом(под проектом я понимаю веб-сайт) работает несколько манульщиков и несколько автоматизаторов.
В нашей компании ситуация немного другая.
1) Около 10 собственных (не аутсорс) проектов, половина из которых полновесные миллионники с десятками тысяч страниц.
2) QA Lead (в ручном или авто-тестировании участия не принимает, в принципе и не должен
3) 4 тестировщика, тестирующих в ручную (у каждого по 2-3 проекта)
4) 1 автоматизатор (ака я).
Понятно, такое встретишь не часто, но сразу можно сказать, что и манульщиков, и автоматизаторов явно маловато для обеспечения должного качества. Плюс их соотношение, явно не в пользу автоматизации. На автоматизацию ставку не делают, хотя заавтоматизировали основной функционал, который меняется довольно часто, на всех проектах (их кол-ва растет). Это позволяет экономить каждому тестеру по несколько часов в день, как минимум. Плюс задачи по автоматизации другого характера. И всем этим занимается один человек. При этом я хочу перейти к правильному написанию тестов (с использованием Page Object) и инфраструктуре, начальство хочет еще больше: DSL - чтобы мануальщики, могли писать автотесты, DDT и прочее. Вот такие пироги
А какая ситуация у вас в отделе?

[horhe]

У нас чистых мануальщиков четверо, три человека и мануалят, и автоматизируют, и нагрузочным занимаются, Test Lead иногда (если позволяет время, а это бывает редко) тоже тестирует-автоматизирует-нагружает. Чистых автоматизаторов нет. так что можно сказать, что 4:1 )

[Wolonter]

А какая ситуация у вас в отделе?

У нас примерно 11 к 4. Хотя я считаю такое деление порочным.

[neman]

А какая ситуация у вас в отделе?

У нас примерно 11 к 4. Хотя я считаю такое деление порочным.

Почему?

PS: У нас деления как такового нет. Кто-то больше занимается автоматизацией, кто-то меньше.

[ch_ip]

В нашей компании ситуация немного другая.
1) Около 10 собственных (не аутсорс) проектов, половина из которых полновесные миллионники с десятками тысяч страниц.
2) QA Lead (в ручном или авто-тестировании участия не принимает, в принципе и не должен />
3) 4 тестировщика, тестирующих в ручную (у каждого по 2-3 проекта)
4) 1 автоматизатор (ака я).
Понятно, такое встретишь не часто, но сразу можно сказать, что и манульщиков, и автоматизаторов явно маловато для обеспечения должного качества.

1) Из чего сделан вывод о недостаточности ресурсов?
2) Что такое должное качество и чем не устраивает текущее качество?

Плюс их соотношение, явно не в пользу автоматизации. На автоматизацию ставку не делают, хотя заавтоматизировали основной функционал, который меняется довольно часто, на всех проектах (их кол-ва растет).

3) основной функционал заавтоматизирован через GUI-тесты? Сколько стоит их поддержка в условиях часто меняющейся функциональности?
4) почему не делают ставку на автоматизацию?

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

5) что такое задачи по автоматизации другого характера?

При этом я хочу перейти к правильному написанию тестов (с использованием Page Object) и инфраструктуре, начальство хочет еще больше: DSL - чтобы мануальщики, могли писать автотесты, DDT и прочее. Вот такие пироги />

6) а как сейчас написаны тесты, если хочется перевести их на page object?
7) DSL обычно является плохой идеей. Как правило, время и деньги можно потратить с бОльшей пользой.

Теперь о том, как у нас.
Фреймворк для автотестов у нас пишут программисты, потому что у них это получается быстрее и лучше, во-первых. Они знают код приложения изнутри и могут добавить недостающие вещи для автоматизации или оптимизировать код, чтобы тесты проходили быстрее.
Сами тесты пишутся тестировщиками, разделения на ручных/автоматизаторов нет. Любой "ручной" тестировщик в состоянии собрать проект, запустить по нему тесты, проанализироть лог, понять причину ошибки, поправить конфигурацию, если причина теста в ней. В редких случаях бывает необходимость консультации с программистами, чтобы определить, найден баш или какие-то косяки в фреймворке (что в общем-то, тоже баг, но на фреймворк).
При этом у нас программисты пишут юнит-тесты на свой код. Тестировщики же часто пишут тесты на доработки, которые необходимо сделать в программе (новые фичи, улучшения в старых) до того, как эти доработки уходят в разработку к программистам. То есть правилом хорошего тона считается, когда к разработчику поппадает задача с уже написанными по ней автотестами, которые в текущий момент падают.

[Wolonter]

Почему?

PS: У нас деления как такового нет. Кто-то больше занимается автоматизацией, кто-то меньше.

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

Считаю правильным ваш вариант, когда кто-то больше, кто-то меньше.

[neman]

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

Считаю правильным ваш вариант, когда кто-то больше, кто-то меньше.

Хорошо там, где нас нет . Если условно мануальщики пишут тесты - это же надо принимать реквесты, следить за стилем, указывать на ошибки. Одно дело 1-2-3 человека, которые занимаются этим постоянно и которым можно быстренько вправить мозги в нужную сторону. А полтора десятка.. Впрочем, у вас Джава, хотя бы есть шанс взять того кто её знает

[Snap]

1) Из чего сделан вывод о недостаточности ресурсов?
2) Что такое должное качество и чем не устраивает текущее качество?
3) основной функционал заавтоматизирован через GUI-тесты? Сколько стоит их поддержка в условиях часто меняющейся функциональности?
4) почему не делают ставку на автоматизацию?
5) что такое задачи по автоматизации другого характера?
6) а как сейчас написаны тесты, если хочется перевести их на page object?
7) DSL обычно является плохой идеей. Как правило, время и деньги можно потратить с бОльшей пользой.

Теперь о том, как у нас.
Фреймворк для автотестов у нас пишут программисты, потому что у них это получается быстрее и лучше, во-первых. Они знают код приложения изнутри и могут добавить недостающие вещи для автоматизации или оптимизировать код, чтобы тесты проходили быстрее.
Сами тесты пишутся тестировщиками, разделения на ручных/автоматизаторов нет. Любой "ручной" тестировщик в состоянии собрать проект, запустить по нему тесты, проанализироть лог, понять причину ошибки, поправить конфигурацию, если причина теста в ней. В редких случаях бывает необходимость консультации с программистами, чтобы определить, найден баш или какие-то косяки в фреймворке (что в общем-то, тоже баг, но на фреймворк).
При этом у нас программисты пишут юнит-тесты на свой код. Тестировщики же часто пишут тесты на доработки, которые необходимо сделать в программе (новые фичи, улучшения в старых) до того, как эти доработки уходят в разработку к программистам. То есть правилом хорошего тона считается, когда к разработчику поппадает задача с уже написанными по ней автотестами, которые в текущий момент падают.

По-моему, эти вопросы немного выходят за рамки темы, но если интересно, я вкратце отвечу:
1) Из здравого смысла :) Ну или методом сравнения.
2) Попробую привести пример в двух словах: наличием ошибок (в частности 1-ого) приоритета в продакшене.
3) Да, это же веб. С поддержкой особых проблем нет, а стоимость минимальна и включена в мою ЗП.
4) Как вариант, потому что не особо в ней разбираются + экономия на качестве.
5) Проверка бэкенда и автоматизация других рутинных задач.
6) Без использования PageObject :)
7) Пожалуй, соглашусь.

Спасибо, за подробный ответ.
У нас первоначально фреймворк также был полностью написан программистом C#. Его поддержка сразу же легла на меня. Фреймворк имеет свои плюсы: генерит простые отчетики, с понятными ошибками даже мануальщикам или же ее легко найти автоматизатору (если она не предвиденная), есть возможность параллельного запуска в разных браузерах и т.п. Для PageObject он не подходит и тесты в нем написаны по большому счету не очень "правильно", хотя их довольно легко поддерживать.
Ручные тестировщики могут лишь записать тест в Selenium IDE и с трудом различат CSS-селектор от XPath. Юнит-тестов у нас нет.
Сейчас, я хочу перейти на PageObject + Java + JUnit(TestNG), но это уже совсем другая история...

[ShortLegged]

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

@ch_ip, расскажи, pls, почему DSL плохая идея?

[Snap]

Похоже больше ни у кого ничего похожего или непохожего нет...?