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

[Deman]

На данный момент нам надо внедрить тестирование сложного WEB приложения.
Около 3000 PHP скриптов. Каждый день это приложение разрабатывается 17-ю программистами. Приложение - внутренняя система администрации для казино.

Пока что рассматривается автоматизация тестирования только для данного проекта.

Каждый из наших клиентов использует эту внутреннюю систему администрации. Клиентов у нас около 90 интернет казино.

Люди работавшие в больших компаниях Поделитесь опытом.

Будет ли целесообразным покурать например 5-10 лицензий QTP+QC только для данного проекта, который никогда не закончится или целесообразно пользоваться услугами оутсортинговой компании?

[Guriy]

Автоматизация, это не панацея от всех бед
Она может Вам помочь, но не решит всех проблем
Нужен постоянный штат тестировщиков (от 3 до 7 на вскидку)
А вот уже паралельно с этим можно запускать автоматизированное тестирование.

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

[Deman]

Группа тестирования у нас есть, всего 17 человек. На данный продукт приложено 10. Но они тестируют его только вручную. Автоматического тестирования этого продукта у нас нет сейчас вообще. Ни одна автоматическая тула у нас тоже ещё не куплена. Выбор мы лично остановили на QC+QTP.

Но стоит ли сразу тратить так много денег ради одного проекта? Будет ли выгоднее заказать аутсортинговую компанию?

[Mila]

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

[Guriy]

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

Но это еще не все
Самое страшное это - все поддерживать в работоспособном состоянии.
А для этого нужны ресурсы, ресурсы и еще раз ресурсы.....

Если у Вас есть 5-ть человек, которые с завтрашнего дня сядут и начнут на фул-тайм кодировать, и при этом они будут знать что кодировать, то покупайте сейчас.
Если таких людей нет, и не проводилось никакаой подготовки, то лучше отдать в аутсорсинг, и потом поддерживать.

ИМХО

[Kaluga]

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

Но это еще не все
Самое страшное это - все поддерживать в работоспособном состоянии.
А для этого нужны ресурсы, ресурсы и еще раз ресурсы.....

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

ИМХО

[Case]

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

(+ и это самое важное) Надо уметь тестировать - в смысле решать задачи тестирования - вручную, и видеть где имеет смысл автоматизировать.

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

[van]

Коллеги, доброе утро!

На этом форуме уже неоднократно обсуждлась необходимость/целесообразность и т.п. внедрения автоматизированного тестирования на проектах.

Так что:
1. Предлагаю поискать по форуму
2. Начать вот с этой книги http://www.ozon.ru/c...ail/id/1322690/

[Kaluga]

2. Начать вот с этой книги http://www.ozon.ru/c...ail/id/1322690/

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

[Green]

2. Начать вот с этой книги http://www.ozon.ru/c...ail/id/1322690/

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

Присоединяюсь. :-)

Deman
Ваш вопрос показывает Ваш не высокий профессиональный уровень. Это не в укор Вам. Ни в коем случае! Просто Вы не знаете как подступиться к решению проблемы и с какого бока к ней подойти.

На самом деле. Вам нет смысла прямо сейчас читать толстые книжки. Попробуйте рассуждать логически. Вася мог лететь в Ленининград? Сорри это не в ту конференцию.

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

Во-вторых, упоминание про 17 разработчиков наводит на мысль, что тестировщиков значительно меньше. Можно предположить, что вы не успеваете тестировать весь желаемый объем. Следовательно, речь может идти об увеличении производительности и применении профессиональных методик и подходов в тестировании ПО. Вот это может быть наиболее полезно в Вашем случае. Консультант - самый быстрый, но не самый дешевый способ достигнуть прогресса в этой области.

В-третьих, автоматизировать можно только регрессионное тестирование, а экономическая сторона вопроса показывает, что это нужно делать далеко не для всех тестов. Почитайте дискуссии, связанные с обсуждение возможности 100% автоматизации тестирования. Выбор тула зависит от кошелька компании. На форуме этому вопросу так же уделялось и уделяется большое внимание.

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

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

[KaNoN]

Во-вторых, упоминание про 17 разработчиков наводит на мысль, что тестировщиков значительно меньше. Можно предположить, что вы не успеваете тестировать весь желаемый объем. Следовательно, речь может идти об увеличении производительности и применении профессиональных методик и подходов в тестировании ПО. Вот это может быть наиболее полезно в Вашем случае. Консультант - самый быстрый, но не самый дешевый способ достигнуть прогресса в этой области.

Речь шла о группе тестирования численностью 17 человек. А консультант действительно лишним не будет.

В-третьих, автоматизировать можно только регрессионное тестирование,

Не согласен. Также автоматизируется Stress ( мы и такое тестирование практикуем ) и Performance тестирование. С последним имеется ряд трудностей, но автоматизация и в этом случае возможна. Я бы сказал, что
автоматизация наиболее целесообразна для регрессионного тестирования и реально экономит затраты при многократном тестировании.

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

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

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

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

[Deman]

Спасибо всем за советы. Только они не конкретные. Хотел бы уточнить некоторые вещи.
1) Продукт разрабатывает 17 программеров. Тестеров у нас тоже 17, но 10 из них тестируют именно этот продукт. Они тестируют только новшества. Регрессионного тестирования нет :(
2) Специфика проекта именно такая, что он никогда не закончится.

И что я вообще хотел узнать-то. Хотел я, чтобы кто-то со мной поделился опытом. Если проект ссовсем уже не молодой и не маленький. И мы все поняли, что надо делать регрессионное тестирование. И так сказать все спеки у наших тестеров и разработчиках в головах, что не есть хорошо. Что автоматизировать можно не всё - это я знаю. Год сам делал исследовании в области автоматического тестирования.
Меня больше интересует экономический вопрос, как потратить меньше и получить больше.
Есть 3-и начальных пути.
1) Оутсортинговая компания. (спеки как таковой нет)
2) Консультант.
3) Купить тулу и самим всё раскапывать.

Есть ли тут кто-то, кто имел опыт с проектами такого размера и в таком "частично запущенном" состоянии.

Кто и как пытался внедрить автоматизацию тестирования, и что из этого получилось?

[KaNoN]

Есть 3-и начальных пути.
1) Оутсортинговая компания. (спеки как таковой нет)
2) Консультант.
3) Купить тулу и самим всё раскапывать.

Если позволяют средства, то предпочтительнее 3-й вариант ( я так считаю). Все-таки внутри конторы лучше знают требования к своему продукту и его тестированию. Трудности с использованием я указывал. А выбор тулзы - на ваше усмотрение.

[Mike]

Я думаю, что предпочтительный вариант - консультант. То есть, человек, имеющий опыт автоматизации, который поможет выбрать инструмент и наладить процесс - обучить персонал, в частности. Причём желательно - специалист не афилированный с определёнными вендорами софта, или аутсорсинговыми компаниями (они, по понятным причинам, не заинтересованы в развитии Вашего отдела тестирования). А разбираться самим - это, извиняюсь, изобретение велосипеда.

Есть вариант с наймом подобного специалиста, но это выйдет дороже.

Кроме того, судя по тому, что Вы пишете, Вам категорически не хватает хорошего аналитика. Мне кажется, первое что надо сделать - отправить одного из тестировщиков на курсы аналитиков (UML, RUP (или другая методология), Объектно-ориентированное проектирование) и засадить его писать спеки, use-cases (опционально - и тесткейсы). Для начала - на новую функциональность. Облегчите труд тестировщиков (да и программистов) кардинально.

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

Ну и, понятно, процесс надо налаживать.

[Kaluga]

Есть 3-и начальных пути.
1) Оутсортинговая компания. (спеки как таковой нет)
2) Консультант.
3) Купить тулу и самим всё раскапывать.

3й вариант - вернуый путь к утверждению, что "автоматизация - Г...". На изучение тулза и набор опыта уйдет не менее 1 года. Да и то с непредсказуемым эффектом (тул может оказаться не тот и тп).
Однозначно, что если есть желание это делать, то надо делать силами специалистов.
Или консультант, или аутсорс, или тот же консультант, устроенный на позицию тест-менеджера.

[Deman]

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

Надо книжки нормальные почитать будет ;)

[Kaluga]

Надо книжки нормальные почитать будет ;)

Книжки не панацея. Нужен практический опыт.

[KaNoN]

3й вариант - вернуый путь к утверждению, что "автоматизация - Г...".

Вот не факт. Зависит от самой тулзы, от уровня знакомства персонала с автоматизированным тестированием как таковым. В последнем случае, действительно, имеет смысл обратиться к консультантам

На изучение тулза и набор опыта уйдет не менее 1 года. Да и то с непредсказуемым эффектом (тул может оказаться не тот и тп).

У нас на подобные вещи ушло около полугода ( могли бы и быстрее ) . К этому времени мы уже успели написать не один десяток скриптов. Хотя, я и
не исключаю, что подобное мнение сформировалось на основе горького опыта.

[Kaluga]

У нас на подобные вещи ушло около полугода ( могли бы и быстрее ) . К этому времени мы уже успели написать не один десяток скриптов. Хотя, я и
не исключаю, что подобное мнение сформировалось на основе горького опыта.

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

[KaNoN]

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

Да, такой грешок и я за собой замечал. Но ничего, попустило

Спустя еще год у меня зародились смутные сомнения в этом...

Спустя год, нам уже заказывали тестинг. Так что наши скрипты мы уже не писали "в стол" или для тренировки

Сейчас, трезво оценивая, я могу сказать, что все-таки набор опыта идет не меньше года. Хотя это сильно зависит от количества и разнообразия проектов.
Тем не менее, рекомендую чуть-чуть подождать с формированием Вашего самомнения.

Я уже почти полтора года вожусь с автотестингом. Уже более 10 тестирований проводилось за это время (не считая дейли-тестингов для проверки работоспособности скриптов). Так что, мое самомнение имеет достаточно прочный фундамент.