Существующая инфраструктура тестирования (CI, selenium grid итпх) и ее автотестеры используют java.

Ну собссно это и является, ИМХО, определяющим фактором.

 

 

Ни одного реально значимого аргумента за Python не увидел.

 

Будут ли программисты что-то делать с селениумовым кодом? Да вряд ли.

 

 

Инфраструктура использует java, но запуск тестирующей системы, написанной на python - вполне возможен.webDriver...

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

Какой язык выбрать для написания автотестов: Python или java?

 

Специфика ситуации коротко: продукт и разработчики на питоне, автотесты и инфраструктура на яве.

 

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

Аргументы за java:
- Существующая инфраструктура тестирования (CI, selenium grid итпх) и ее автотестеры используют java.
- На java есть откуда копипастить куда обращаться за решениями по кодированию именно автотестов (пользуясь случаем, передаю привет)
- Я уже писал автотесты на java
- WebDriver первыми выпускает обновления для java и вообще лучше работает с этим языком (тут я могу и ошибаться)
- Лично мне больше нравится java (а тут я могу и передумать)

Аргументы отсортированы по весу, первыми - самые значимые.

 

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

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

Мое слово - не последнее, но кино будет именно моим, хотелось бы запастись аргументами.

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

Чем ближе тестирование к ctrl+s в IDE программиста, тем лучше.

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

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

Поделитесь, это происходит у вас :)

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

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

Всем добрый день!

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

Kaner, Lessons Learned in Software Testing, chapter 11 (глава внезапно так и называется - стратегия тестирования).
Стратегия - набор идей, определяющих дизайн тестов. Стратегия тестирования является частью плана тестирования.
Lesson 274: Три основных вопроса о стратегии тестирования «Зачем?», «Кому это нужно?» и «Сколько?»
Lesson 281: Стратегия тестирования содержит ответ на вопрос - почему я провожу именно эти тесты?
Lesson 282: Стратегия объясняет тесты

Почему?

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

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

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

Принято. Я полагаю, что ваши цели неверны. После этого все остальные рассуждения смысла не имеют.

Прочитайте "Цель" Эли Годратта. Я его читал раза три. И вам советую.

Читал его книги, читал. Замечательные они, да. В одной из них Элияху настоятельно рекомендует отделить мух от котлет, а области влияния и контроля - от того, что я менять не могу. Мудрая мысль, сдается мне. И если к ней не прислушаться, то вы мне сейчас еще порекомендуете идти и учить жизни ПМа, техдира, топ-менеджеров и акционеров.

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

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

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

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

К примеру.
Быстро (минуты) удостовериться, что большой объем (тысячи фич) функциональности работает VS Быстро (часы) удостовериться, что одна фича обладает нужным уровнем качества.

Вам нужна регрессия и скорость, у вас дофига денег - автоматизируйте.

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

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

Я специализирусь на больших системах. Реально больших. И 10 тысяч дефектов в продукте - это не запредельная цифра. Может быть и 50 тысяч.

Я верю, что большие. И мне действительно интересно, что за система. Это не секрет? Если я умею гуглить, то это colvir, получается заказной корпоративный crm, erp, биллинг, бухучет, расчет бюджетов? И госсектор. А у вас проектная или продуктовая разработка?

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

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

По теме - регрессия - тестирование того, что уже было протестировано. Не?

На днях меня озадачили "сверху" - попросили оценить, а выгодны ли нам автотесты, которые мы пишем?
И не лучше ли потратить ресурсы, затраченные на их написание и поддержку, на аналогичное тестирование вручную?

Не стоит сравнивать автотесты и ручное тестирование. Это разные виды деятельности. Чаще всего с разными целями.
Куда направить больше ресурсов - на ту цель, которая в данный момент важней для вас. Мы хотим купить переднеприводный автомобиль или зеленый? На что лучше потратить ресурсы?
Вам нужна регрессия и скорость, у вас дофига денег - автоматизируйте. Ваши проекты длятся по месяцу - тестируйте руками.

Гм. Интересно было бы поработать вместе с SALar, посмотреть, что ж он так не любит автоматизацию, что за продукт и программисты с 35 багами в день.

Вот смотрите пример расчета. Статистическими методам установлено, что приложении будет около 10 000 дефектов из которых до продакшена нужно выявить и устранить порядка 9 000. Мой отдел из пяти тестировщиков ищет дефекты со скоростью около 700 багов в месяц (не слишком много, потому что я уделяю много времени обучению), с коэффициентом пропущенных дефектов менее 1%. Отдел программирования правит дефекты ориентируясь на отдел тестирования, с отставанием в месяц. Вопрос: когда можно будет выпускать продукт?

Цифры близки к реальным? Все найденные 35 багов в день - только в новых фичах? Все 35 исправляются через месяц? Вы уверены, что в данном случае не стоит уделить время автоматическому регрессионному тестированию?

2cryofrost. А если у вас будет отдел из 10 автоматизаторов, то когда?

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

я тут один тестировщик.
...
Что нужно подтянуть, изучить, ПОЧИТАТЬ для того, чтобы стать руководителем отдела тестирования???

Стать руководителем себя? :)

Ну а кроме шуток, вы хотите стать лидом или менеджером? Это две большие разницы.

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

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

Канер, "Тестирование ПО", а дальше по списку литературы на сайте.

Что делать?

• Спросить у руководства "а почему мне предложили стать тестировщиком?" Какую проблему решают тестировщиком? Чего от тебя ждут? Плясать от этого, остальное лирика.
• Вам как саппорту проще - вы знаете какие баги ловят клиенты. Собственно, для того, чтоб они их ловили меньше, вас скорее всего и переместили.
• А значит берем список багов, которые нашли клиенты за последний год, и применяем творчество и воображение. Делаем так, чтоб они такие баги, баги такого класса - не находили.

То же самое на форуме и в блоге.

Мы часть той силы, что "вечно хочет зла и вечно совершает благо".

Дадада.
Хороший тестировщик - антагонист процесса создания ПО, являющийся продуктом этого процесса и ставящий своей целью создание ситуации в которой он не будет нужен.
И прочая философская муть.

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

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

... то может последовать ответ, "аа кнопочки по нажимать, проверить работают ли они. Делов то куча, фигня работа".

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

Я еще работаю, но хочу сменить место работы, подскажите пожалуйста, что нужно отвечать на собеседовании, если задают вопрос: Почему решили сменить место работы? мол что вас там не устраивало и так далее..? (я же не скажу им что мол мало зп платят, или так можно говорить?)... Вообщем помогите пожалуйста. Заранее спасибо!

Где-то даже целая статья была на эту тему. Как-то так:
А я еще не решил менять работу. Меня устраивают отношения в коллективе и то, чем я занимаюсь на текущем месте. Но ваше предложение достаточно интересно, давайте поговорим о нем.