Darrie
23.10.2017
08:19:16
Мб я ошибаюсь, но видела, что они хотят 6 месяцев опыта
Roman
23.10.2017
08:19:21
то есть усложнение должно быть только там, где без него нельзя
Darrie
23.10.2017
08:20:52
А, ну ок.
Google
Zewa ?
23.10.2017
08:21:07
Ann
23.10.2017
08:29:00
Roman
23.10.2017
08:30:45
Zewa ?
23.10.2017
08:32:31
Ann
23.10.2017
08:33:52
оу, прошу прощения. в понедельник как-то плоховато думается.
Roman
23.10.2017
08:34:10
Zewa ?
23.10.2017
08:35:52
Roman
23.10.2017
08:36:40
в большинстве случаев это норм работает без свистоперделок, но кому-то этим всё равно придётся заниматься и проверять или после очередного апгрейда не слетела синхронизация
в ТФС, а ещё и если в Азуре варианте такое почти невозможно
Zewa ?
23.10.2017
08:37:42
Roman
23.10.2017
08:38:24
Google
Anton
23.10.2017
09:35:24
Всем привет, столкнулся с такой проблемой , при запуске автотеста после перехода на веб страницу она постоянно грузится (даже после того как все элементы уже подгрузились) и тест не продолжается. Кто-то сталкивался с такой проблемой и как ее можно решить ? Использую Selenium + Java + TestNG
Белов
23.10.2017
11:27:10
Она же просила не кидаться тапками=)
Darrie
23.10.2017
11:27:17
https://t.me/qa_jobs
Только обратите, пожалуйста, внимание на правила оформления
Richard
23.10.2017
11:28:53
Darrie
23.10.2017
11:29:20
Это не тапки, это помощь!
Там у вакансии гораздо больше шансов быть увиденной
Andrey
23.10.2017
11:57:35
Спасибо, да, Минск точно был
Andrey
23.10.2017
12:35:50
Далгат
23.10.2017
13:55:25
Всем привет! Возник вопрос по выбору методики тестирования, мб кто сталкивался или может подсказать. К сути- есть параметр, значение которого меняет другой параметр, к примеру тип операции = 1 укажет что это покупка, а тип операции = А0 укажет что это зачисление на карту. Все это различные транзакции карты, таких операций около 50. Еще есть другая таблица, где в зависимости от кода приходит различный ответ об отмене транзакции, к примеру не достаточно средств на счету или обрыв транзакции. В этой таблице уже порядком 100 значений. Все проверки 1 к 1, если писать кейсы на все эти проверки будет около 150 кейсов, это только по двум таблицам, а в спецификации еще под 40 кейсов. Не будут ли такое количество кейсов избыточными и возможно есть какая то методика как к примеру класс эквивалентности ?
тип операции всегда приходит верным, риск ошибки в этом маловероятен, поэтому класс эквивалентности, для сокращения этих тестов не подойдет
Shoo
23.10.2017
13:57:33
И тут в тред врывается Pairwise Testing, про который так любят спрашивать на собеседованиях.
Valery
23.10.2017
13:58:02
гадание на параметрах, обожаю
Shoo
23.10.2017
13:58:51
Далгат
23.10.2017
14:00:33
тип операции присылает way4 ) думаю если поймаю их баг будет круто, но маловероятно )
Shoo
23.10.2017
14:01:03
Ну, вот "маловероятно" не тот случай с внешними зависимостями. В прочем whatever.
Pairwise помогает существенно сократить количество проверок.
Хотя более правильным вариантом мне кажется отталкиваться от данных аналитики и разделять транзакции на "типовые" и "не-типовые", в зависимости от этого и плясать.
Далгат
23.10.2017
14:08:40
Maxim
23.10.2017
14:09:23
Google
Shoo
23.10.2017
14:10:22
Ну, примеры будут индивидуальны для сервиса, как вы понимаете.
Но в целом да, приведенный пример правильный.
Соотв. приоритет проверки типовых кейсов всегда выше, чем не-типовых.
Соотвественно негативные кейсы тут тоже надо уметь обрабатывать (или по крайней мере корректно уходить fallback, что бы вы знали о таких ситуациях, а не просто пятисотили где-то в глубинах логов).
Это вы сейчас к чему?
Это не самый плохой кейс из возможных.
Далгат
23.10.2017
14:14:38
Shoo
23.10.2017
14:15:50
были случаи?
Про way4 не скажу, но с другими ребятами это вполне регулярные истории.
Maxim
23.10.2017
14:16:34
не однократно, или в транзакцию добавлялись еще какие либо параметры без которых в конце концов не считалась успешно на стороне банка, а на стороне сервиса ок
ну тут еще зависит от того какой апи, клиентский или меж сервисный
много много нюансов, если есть время лучше покрывать как сказал Shoo самые типовые, а потом менее популярные, поскольку если на типовых рухнет, потерь будет просто банально больше
Далгат
23.10.2017
14:19:31
Спасибо коллеги, если менеджер пропустит, так и сделаю )
Andrey
23.10.2017
15:33:39
Добрый вечер, коллеги.
Данный вопрос скорее относится к представителям компаний с налаженным тестированием и несколько уходит уже в менеджмент.
Используются ли у вас метрики для определения того, какое количество задач является оптимальным для тестировщика? Допустим у продукта уже 500-1000 кейсов в основной регрессии, каждый релиз добавляет еще 40-50 тикетов (5-7 крупных изменений, остальные требуют 10-15 минут на подтверждение фикса/реализации), то каком образом вычисляется минимальный размер команды тестирования? Существуют ли какие-то типовые подходы? Спасибо.
Shoo
23.10.2017
15:35:39
Andrey
23.10.2017
15:37:52
коэффициент вычислен эмпирически?
Shoo
23.10.2017
15:38:22
Ну, я просто не сильно верю, что человек на рабочем месте будет тратить на непосредственные спринтовые задачи больше, чем 60% времени.
Кофе попить, покурить, поскрамить, туда-сюда.
Andrey
23.10.2017
15:39:19
Понял, спасибо
Shoo
23.10.2017
15:40:13
Ну, митинги - это планируемая активность, в общем-то. Она должна учитываться во времени спринта.
Google
Vage
23.10.2017
15:41:56
Если не ошибаюсь, то в аджайле считается что из 8 часов рабочих на выполнение задач берётся 6ч. + на UAT не забывайте накинуть 10-30% (в зависимости от команды) времени на баги и всё что с ними связано
Valery
23.10.2017
15:42:31
и получите кашу
Roman
23.10.2017
19:10:57
про размер команды - всё просто, какой бюджет - такой размер команды
если бюджет неограничен, то зависит от продукта и возможности автоматизации выполнения тестов
старая калькуляция для энтерпрайза по "мануальщики онли" - 1 дев, 2 куа, но неактуально, более актуально считать, что если у нас тестирование мануальное, то количество куа не может быть меньше 30% размера команды
но реальность такова, что бывает куча разной лютой фигни. в ТДД ваще не нужны выделенные куа, в БДД нужны именно куа, а не тестировщики, в общем куча опций
Alexei
23.10.2017
19:36:42
Roman
23.10.2017
19:37:13
например?
Alexei
23.10.2017
19:38:05
Куа это кто? Тестировщик, которому стало стыдно за свою профессию?
Например миф про то, что при TDD тестирование вообще не нужно. Опровергается чисто математически.
Roman
23.10.2017
19:39:56
QA - это люди, обслушивающие стандартизованные процессы (CMMi, QMS, ISO-based)
при тдд не нужны выделенные тестировщики
Alexei
23.10.2017
19:40:53
Что такое TDD - это по факту, когда всё что мы написали покрыто юнит-тестами.
Значит ли это, что мы всё написали правильно?
Давайте возьмём и напишем произвольный говногод, которые делает херню.
Затем покроем его на 100% тестами.
Стал наш говнокод волшебным образом правильным качественным кодом?
TDD ни каких гарантий не даёт, это способ попробовать заставить программиста больше думать о том, как его код используется. Это может улучшить качество кода, но не сделает из манки-программиста внезапно звезду.
ISO, как критерий качества это вообще смешно. ISO может например прописывать, что у вас должна быть роль тест менеджера, или там что у вас тест-кейсы должны храниться в специальном хранилище. И что? Это качество какое-то обеспечивает? Прикрытие жоп - единственное, что обеспечивает ISO
Google
Roman
23.10.2017
19:50:32
ТДД - это процесс, в этом процессе совершенно не нужно иметь выделенную роль "тестировщик", процесс тестирования строится как активность во время разработки