Мб я ошибаюсь, но видела, что они хотят 6 месяцев опыта

то есть усложнение должно быть только там, где без него нельзя

Мб я ошибаюсь, но видела, что они хотят 6 месяцев опыта

исткуб? хоть адвансд левел сдавай без секунды работы

А, ну ок.

то есть усложнение должно быть только там, где без него нельзя

так базовым функционалом никто не мешает пользоваться, а скрипты уже для тех, кто ценит свое время :)

а у qTest и TFS есть какой-нибудь двиг для написания скриптов, типа как у HP ALM?

не знаю, как у HP, в VS-премиум можно писать UI-тесты с использованием CodedUI, запись скриптов там тоже есть, но работающий проект одной записью не сделаешь. Потом можно эти тесты привязывать к кейсам в Test Manager и оттуда же запускать https://msdn.microsoft.com/en-us/library/dd380741.aspx

так базовым функционалом никто не мешает пользоваться, а скрипты уже для тех, кто ценит свое время :)

ну время на написание скриптов и их мейнтейн тоже нужно считать

не знаю, как у HP, в VS-премиум можно писать UI-тесты с использованием CodedUI, запись скриптов там тоже есть, но работающий проект одной записью не сделаешь. Потом можно эти тесты привязывать к кейсам в Test Manager и оттуда же запускать https://msdn.microsoft.com/en-us/library/dd380741.aspx

не, я про автоматизацию процесса взаимодействия с софтом, а не автотесты :)

ну время на написание скриптов и их мейнтейн тоже нужно считать

эт да, согласен

оу, прошу прощения. в понедельник как-то плоховато думается.

не знаю, как у HP, в VS-премиум можно писать UI-тесты с использованием CodedUI, запись скриптов там тоже есть, но работающий проект одной записью не сделаешь. Потом можно эти тесты привязывать к кейсам в Test Manager и оттуда же запускать https://msdn.microsoft.com/en-us/library/dd380741.aspx

это немного не то, что обсуждаем, но VS+TFS мощнейшая подсистема, если взять правильный коллаб дев+куа+менеджмент - лучше не найти

это немного не то, что обсуждаем, но VS+TFS мощнейшая подсистема, если взять правильный коллаб дев+куа+менеджмент - лучше не найти

сразу мимо весь ынтерпрайз на жаве :)

сразу мимо весь ынтерпрайз на жаве :)

схера? то есть совершенно ничего не мешает кодить в студии на джаве ))) но так то на джаве всё равно надо линковать одни тулы к другим

в большинстве случаев это норм работает без свистоперделок, но кому-то этим всё равно придётся заниматься и проверять или после очередного апгрейда не слетела синхронизация

в ТФС, а ещё и если в Азуре варианте такое почти невозможно

схера? то есть совершенно ничего не мешает кодить в студии на джаве ))) но так то на джаве всё равно надо линковать одни тулы к другим

о, она умеет в жаву? я как-то давно интересовался, тогда вроде еще не умела, да и наши все на idea сидят

о, она умеет в жаву? я как-то давно интересовался, тогда вроде еще не умела, да и наши все на idea сидят

умеет через плагины (плюс есть же интегрированный VS Code), но это очевидно не самый удобный варик

Всем привет, столкнулся с такой проблемой , при запуске автотеста после перехода на веб страницу она постоянно грузится (даже после того как все элементы уже подгрузились) и тест не продолжается. Кто-то сталкивался с такой проблемой и как ее можно решить ? Использую Selenium + Java + TestNG

Она же просила не кидаться тапками=)

https://t.me/qa_jobs

Только обратите, пожалуйста, внимание на правила оформления

Она же просила не кидаться тапками=)

Ну, это как начать фразу с "Ты только не обижайся, но...". Потом можно говорить какие угодно любые гадости и человек обязан не обижаться.

Это не тапки, это помощь!

Там у вакансии гораздо больше шансов быть увиденной

Спасибо, да, Минск точно был

Всем привет, столкнулся с такой проблемой , при запуске автотеста после перехода на веб страницу она постоянно грузится (даже после того как все элементы уже подгрузились) и тест не продолжается. Кто-то сталкивался с такой проблемой и как ее можно решить ? Использую Selenium + Java + TestNG

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

Всем привет! Возник вопрос по выбору методики тестирования, мб кто сталкивался или может подсказать. К сути- есть параметр, значение которого меняет другой параметр, к примеру тип операции = 1 укажет что это покупка, а тип операции = А0 укажет что это зачисление на карту. Все это различные транзакции карты, таких операций около 50. Еще есть другая таблица, где в зависимости от кода приходит различный ответ об отмене транзакции, к примеру не достаточно средств на счету или обрыв транзакции. В этой таблице уже порядком 100 значений. Все проверки 1 к 1, если писать кейсы на все эти проверки будет около 150 кейсов, это только по двум таблицам, а в спецификации еще под 40 кейсов. Не будут ли такое количество кейсов избыточными и возможно есть какая то методика как к примеру класс эквивалентности ?

тип операции всегда приходит верным, риск ошибки в этом маловероятен, поэтому класс эквивалентности, для сокращения этих тестов не подойдет

И тут в тред врывается Pairwise Testing, про который так любят спрашивать на собеседованиях.

гадание на параметрах, обожаю

тип операции всегда приходит верным, риск ошибки в этом маловероятен, поэтому класс эквивалентности, для сокращения этих тестов не подойдет

Вам, конечно, виднее, но по моему опыту первое утверждение видится весьма спорным. ;)

тип операции присылает way4 ) думаю если поймаю их баг будет круто, но маловероятно )

Ну, вот "маловероятно" не тот случай с внешними зависимостями. В прочем whatever.

Pairwise помогает существенно сократить количество проверок.

Хотя более правильным вариантом мне кажется отталкиваться от данных аналитики и разделять транзакции на "типовые" и "не-типовые", в зависимости от этого и плясать.

Хотя более правильным вариантом мне кажется отталкиваться от данных аналитики и разделять транзакции на "типовые" и "не-типовые", в зависимости от этого и плясать.

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

тип операции присылает way4 ) думаю если поймаю их баг будет круто, но маловероятно )

дело даже не в баге, они могут поменять тип транзы, а уведомить забудут

Ну, примеры будут индивидуальны для сервиса, как вы понимаете. Но в целом да, приведенный пример правильный.

Соотв. приоритет проверки типовых кейсов всегда выше, чем не-типовых.

дело даже не в баге, они могут поменять тип транзы, а уведомить забудут

А ещё добавить новых типов транзашек и прочее, и прочее, и прочее.

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

Это вы сейчас к чему?

Это не самый плохой кейс из возможных.

Ну, примеры будут индивидуальны для сервиса, как вы понимаете. Но в целом да, приведенный пример правильный.

Спасибо

дело даже не в баге, они могут поменять тип транзы, а уведомить забудут

были случаи?

были случаи?

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

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

ну тут еще зависит от того какой апи, клиентский или меж сервисный

много много нюансов, если есть время лучше покрывать как сказал Shoo самые типовые, а потом менее популярные, поскольку если на типовых рухнет, потерь будет просто банально больше

Спасибо коллеги, если менеджер пропустит, так и сделаю )

Добрый вечер, коллеги. Данный вопрос скорее относится к представителям компаний с налаженным тестированием и несколько уходит уже в менеджмент. Используются ли у вас метрики для определения того, какое количество задач является оптимальным для тестировщика? Допустим у продукта уже 500-1000 кейсов в основной регрессии, каждый релиз добавляет еще 40-50 тикетов (5-7 крупных изменений, остальные требуют 10-15 минут на подтверждение фикса/реализации), то каком образом вычисляется минимальный размер команды тестирования? Существуют ли какие-то типовые подходы? Спасибо.

Добрый вечер, коллеги. Данный вопрос скорее относится к представителям компаний с налаженным тестированием и несколько уходит уже в менеджмент. Используются ли у вас метрики для определения того, какое количество задач является оптимальным для тестировщика? Допустим у продукта уже 500-1000 кейсов в основной регрессии, каждый релиз добавляет еще 40-50 тикетов (5-7 крупных изменений, остальные требуют 10-15 минут на подтверждение фикса/реализации), то каком образом вычисляется минимальный размер команды тестирования? Существуют ли какие-то типовые подходы? Спасибо.

Вы берете все задачи на тестирование (или средний их объем к спринту). Оцениваете их трудозатраты в человеко-часах. Делите полученное значение на длинну спринта в человекочасах * 0.6 и получаете количество тестировщиков, которое вам нужно.

коэффициент вычислен эмпирически?

Ну, я просто не сильно верю, что человек на рабочем месте будет тратить на непосредственные спринтовые задачи больше, чем 60% времени.

Кофе попить, покурить, поскрамить, туда-сюда.

Понял, спасибо

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

Если не ошибаюсь, то в аджайле считается что из 8 часов рабочих на выполнение задач берётся 6ч. + на UAT не забывайте накинуть 10-30% (в зависимости от команды) времени на баги и всё что с ними связано

и получите кашу

Добрый вечер, коллеги. Данный вопрос скорее относится к представителям компаний с налаженным тестированием и несколько уходит уже в менеджмент. Используются ли у вас метрики для определения того, какое количество задач является оптимальным для тестировщика? Допустим у продукта уже 500-1000 кейсов в основной регрессии, каждый релиз добавляет еще 40-50 тикетов (5-7 крупных изменений, остальные требуют 10-15 минут на подтверждение фикса/реализации), то каком образом вычисляется минимальный размер команды тестирования? Существуют ли какие-то типовые подходы? Спасибо.

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

про размер команды - всё просто, какой бюджет - такой размер команды

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

старая калькуляция для энтерпрайза по "мануальщики онли" - 1 дев, 2 куа, но неактуально, более актуально считать, что если у нас тестирование мануальное, то количество куа не может быть меньше 30% размера команды

но реальность такова, что бывает куча разной лютой фигни. в ТДД ваще не нужны выделенные куа, в БДД нужны именно куа, а не тестировщики, в общем куча опций

но реальность такова, что бывает куча разной лютой фигни. в ТДД ваще не нужны выделенные куа, в БДД нужны именно куа, а не тестировщики, в общем куча опций

... и другие мифы от Романа

например?

Куа это кто? Тестировщик, которому стало стыдно за свою профессию?

Например миф про то, что при TDD тестирование вообще не нужно. Опровергается чисто математически.

QA - это люди, обслушивающие стандартизованные процессы (CMMi, QMS, ISO-based)

при тдд не нужны выделенные тестировщики

Что такое TDD - это по факту, когда всё что мы написали покрыто юнит-тестами.

Значит ли это, что мы всё написали правильно?

Давайте возьмём и напишем произвольный говногод, которые делает херню.

Затем покроем его на 100% тестами.

Стал наш говнокод волшебным образом правильным качественным кодом?

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

ISO, как критерий качества это вообще смешно. ISO может например прописывать, что у вас должна быть роль тест менеджера, или там что у вас тест-кейсы должны храниться в специальном хранилище. И что? Это качество какое-то обеспечивает? Прикрытие жоп - единственное, что обеспечивает ISO

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

ISO, как критерий качества это вообще смешно. ISO может например прописывать, что у вас должна быть роль тест менеджера, или там что у вас тест-кейсы должны храниться в специальном хранилище. И что? Это качество какое-то обеспечивает? Прикрытие жоп - единственное, что обеспечивает ISO

Антихайп! Нон-конформизм! Долой стандартизацию