Где вы тестируете веб-приложения?

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

Голосуем, про преимущества/недостатки приведеных способов - пишем. =)

Не хватает варианта: "На Production сервере" :).

Не хватает варианта: "На Production сервере" :).

У нас такой опыт был =)
Один тестировщик со стороны нашего кастомера решил протестировать на живом сайте. При чем не просто работу магазина (чекаут, или каталог), а скрипт запустил, который все айтемы и категории испортил. К нам прибежали с криками: "Что ж вы делаете! Ваш скрипт нам тут всё поламал!!!" После разбирательства выяснилось, что он в properties не заменил ссылку на входной файл. А там была ссылка на тестовый файл, с тестовыми айтемами и категориями, которые они на QA сервере используют.
Мораль: на Production сервере не тестируют, а пользуются готовыми фичами. Правильно пользуются.

На тестовом. В моем случае следующие плюсы:
1. доступен круглосуточно;
2. максимально приближен к продуктивному серверу (локально это пока сделать не получится);
3. что хочу, то и ворочу (в определенных пределах конечно).

Не хватает варианта: "На Production сервере" :).

ага, реально не хватает.
Бывает так, что некоторые вещи работают только на проде, соответственно, там и тестируются.
Кстати, а почему в опросе только 1 вариант ответа можно выбрать?
Вот я тестирую в проде, локально, на тестовом сервере и иногда на компе программистов
Ну и разница между локально и тестовым сервером размыта.

На тестовом-2 сервере :)
У нас 2 внутренних сервера: на одном крутится dev-версия, где программисты могут в любой момент что-то изменить или вообще сломать, на другом — pre-release, где все уже более-менее стабильно работает, и его мучают тестировщики.

на живом тоже тестим, но только в рамках «все работает, ничего не сломалось при обновлении»

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

Вот для этого лучше всего иметь несколько тестовых окружений: каждому тестировщику свой енв.

Зависит от задачи.
В бытность саппортом тестил на боевом - слишком специфичны баги.

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

Ну а для личного пользования и для автотестов - локальный чистый стенд.

Вот я тестирую в проде, локально, на тестовом сервере и иногда на компе программистов

Я имела ввиду чаще всего. На Production и я тестирую (базовые вещи), когда его обновляем; и у программиста на машине, когда у него быг не получается повторить. Но основное место тестирования для меня - тестовый сервер.

Ну и разница между локально и тестовым сервером размыта.

Не поняла?..

На тестовом-2 сервере :)
У нас 2 внутренних сервера: на одном крутится dev-версия, где программисты могут в любой момент что-то изменить или вообще сломать, на другом — pre-release, где все уже более-менее стабильно работает, и его мучают тестировщики.

Ваш тестовый как часто обновляется, если не секрет?

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

Вот для этого лучше всего иметь несколько тестовых окружений: каждому тестировщику свой енв.

Т.е. Вы за тестирование на локальной машине, правильно я поняла?

Т.е. Вы за тестирование на локальной машине, правильно я поняла?

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

Вот я тестирую в проде, локально, на тестовом сервере и иногда на компе программистов

Я имела ввиду чаще всего.

В описании опроса нет слова чаще ;-)

Ну и разница между локально и тестовым сервером размыта.

Не поняла?..

Ну, я могу поднять тестовый сервер у себя локально, которым будут пользоваться несколько человек. И напротив, могу в одиночестве тестировать на выделенном тестовом сервере, который конфигурю не я, но если что-то там сломаю, то это коснется только меня. :)

В описании опроса нет слова чаще ;-)

Пусть это будет багом - я его исправила. =)

Ну, я могу поднять тестовый сервер у себя локально, которым будут пользоваться несколько человек. И напротив, могу в одиночестве тестировать на выделенном тестовом сервере, который конфигурю не я, но если что-то там сломаю, то это коснется только меня. :)

И часто подобное делали? ;-)

Мораль: на Production сервере не тестируют, а пользуются готовыми фичами. Правильно пользуются.

Плохая мораль. И что вы будете делать в случае, если всё упадёт на Production сервере, потому что какой-то пользователь юзнул не правильно фичу(либо апдейт на продакшн стал криво, а вы не заметили потому что боялись сделать шаг вправо или влево)? Это будет косяк отдела тестирования в итоге.

Так что в этом плане тестировать везде надо одинаково качественно и с особым цинизмом и извращенством.
Если что-то упадёт это не минус, а плюс. Нет в этом ничего страшного. Всё всегда можно исправить.
Единственное исключение когда вам дан приказ с выше: что нужно тестировать так, чтоб ничего не упало)

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

Мораль: на Production сервере не тестируют, а пользуются готовыми фичами. Правильно пользуются.

Плохая мораль. И что вы будете делать в случае, если всё упадёт на Production сервере, потому что какой-то пользователь юзнул не правильно фичу(либо апдейт на продакшн стал криво, а вы не заметили потому что боялись сделать шаг вправо или влево)? Это будет косяк отдела тестирования в итоге.

Так что в этом плане тестировать везде надо одинаково качественно и с особым цинизмом и извращенством.
Если что-то упадёт это не минус, а плюс. Нет в этом ничего страшного. Всё всегда можно исправить.
Единственное исключение когда вам дан приказ с выше: что нужно тестировать так, чтоб ничего не упало)

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

Я не говорю, что нужно бояться сделать шаг впрево-влево. Более того, после обновления нужно делать не только впрево-влево, но ещё и вперёд-назад те шаги, которые может сделать сам пользователь.
Я писала о другом: тестировщик зашёл как админ и обновил Production тестовыми айтемами и категориями. И скрипт, как раз в том случае, отработал правильно. Но зачем же такое делать? На Production, в то время, когда там ходят обычные кастомеры? С таки же успехом можно было rm -rf сделать, а потом нервничать, что это живой сайт, и мы же клиентов теряем.

У нас есть два сайта:

site.com - продакшен
beta.site.com - для тестирования функционала и новых фич, мержится в site.com

Любое локальное окружение вносит свои баги. У меня нет времени отделять баги кода от багов окружения.

dev сервер у нас разобран в большинстве случаев разработчиками по запчастям), но бывает тестируем на нем.
в основном тестируем на production
часто приходится тестировать локально (на боевой версии).

проблем никогда никаких со стороны тестирования не было.=)

плюсы - минусы... хм..

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

Иногда бага которая не ловится на тестовом - ловится на боевой.
Тогда печально