Size: a a a

QA — русскоговорящее сообщество

2019 August 14

АГ

Артур Гарифуллин in QA — русскоговорящее сообщество
Я поставил флаги в  хром "acceptInsecureCerts", "ignore-certificate-errors", "acceptSslCerts",  "--no-sandbox"
источник

АГ

Артур Гарифуллин in QA — русскоговорящее сообщество
Это должно решать пробелму с сертификатами
источник

МA

Мария Amanalyre in QA — русскоговорящее сообщество
Lavrentiy Beriya
а не подскажете сайт где можно задачки брать в тестирование за деньги, типо фриланс? где-то в закладках лежал но потерялся
Апворк?
источник

DS

Denis Sitnikov in QA — русскоговорящее сообщество
Ребят, нужен совет: есть 2 проекта с одинаковым базовым функционалом (отличия в дизайне и мелком функционале), тест-кейсами покрыт один проект. Как лучше поступить: 1) создать копию и отредактировать необходимые кейсы, и потом саппортить 2 проекта или 2) унифицировать тест-кейсы таким образом, чтобы они подходили под 2 проекта. В планах 3-ий рескин, и на поддержку в актуальном состоянии тест-кейсов для всех проектов будет уходить слишком много времени. Если у кого-то есть похожая ситуация, поделитесь опытом, пжлста.
источник

O

Olga in QA — русскоговорящее сообщество
Артур Гарифуллин
Я поставил флаги в  хром "acceptInsecureCerts", "ignore-certificate-errors", "acceptSslCerts",  "--no-sandbox"
а там, где вы это нагуглили, не было случайно совета так не делать? :)
если есть самописные сертификаты, можно их добавить через ssl-root-cas
источник

LM

Leonid Mail in QA — русскоговорящее сообщество
Denis Sitnikov
Ребят, нужен совет: есть 2 проекта с одинаковым базовым функционалом (отличия в дизайне и мелком функционале), тест-кейсами покрыт один проект. Как лучше поступить: 1) создать копию и отредактировать необходимые кейсы, и потом саппортить 2 проекта или 2) унифицировать тест-кейсы таким образом, чтобы они подходили под 2 проекта. В планах 3-ий рескин, и на поддержку в актуальном состоянии тест-кейсов для всех проектов будет уходить слишком много времени. Если у кого-то есть похожая ситуация, поделитесь опытом, пжлста.
Мне кажется, что попытка сэкономить время, в перспективе обернётся ещё большими временными затратами на поддержку унифицированного варианта, к которому ты будешь вынужден обращаться с изменениями постоянно.
Чем дальше, тем больше будет различий в 2 проектах, тем больше придётся редачить различные условия приводящие к ожидаемому результату и тд.
Ну это личное мнение конечно.
источник

nA

nea Alecu in QA — русскоговорящее сообщество
Denis Sitnikov
Ребят, нужен совет: есть 2 проекта с одинаковым базовым функционалом (отличия в дизайне и мелком функционале), тест-кейсами покрыт один проект. Как лучше поступить: 1) создать копию и отредактировать необходимые кейсы, и потом саппортить 2 проекта или 2) унифицировать тест-кейсы таким образом, чтобы они подходили под 2 проекта. В планах 3-ий рескин, и на поддержку в актуальном состоянии тест-кейсов для всех проектов будет уходить слишком много времени. Если у кого-то есть похожая ситуация, поделитесь опытом, пжлста.
Логично #1, но на деле работает третий вариант (который будет злить тестировщиков): юзаем один набор тестов на всех проектах. Если в ходе работы тестировщик выясняет, что тест-кейс неадекватен проекту, он помечает тест каким-то особым статусом вроде ToBeUpdated. Позже все такие кейсы отсматриваются и или 1)  подгоняются под проект, или 2) выбрасывают из конкретного проекта.

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

DS

Denis Sitnikov in QA — русскоговорящее сообщество
nea Alecu
Логично #1, но на деле работает третий вариант (который будет злить тестировщиков): юзаем один набор тестов на всех проектах. Если в ходе работы тестировщик выясняет, что тест-кейс неадекватен проекту, он помечает тест каким-то особым статусом вроде ToBeUpdated. Позже все такие кейсы отсматриваются и или 1)  подгоняются под проект, или 2) выбрасывают из конкретного проекта.

В итоге каждый проект снабжен уникальным набором тест-кейсов, тестировщики раздражены, менеджерам всë норм.
если будет N проектов, и надо будет добавить в сьют авторизации, например, авторизацию через linked in, то вы редактируете каждый проект?
источник

C

Cadabrum in QA — русскоговорящее сообщество
Denis Sitnikov
если будет N проектов, и надо будет добавить в сьют авторизации, например, авторизацию через linked in, то вы редактируете каждый проект?
Там отличия проектов насколько большое? Чисто ui, не может быть такого, что фичи разъедутся?
источник

DS

Denis Sitnikov in QA — русскоговорящее сообщество
Cadabrum
Там отличия проектов насколько большое? Чисто ui, не может быть такого, что фичи разъедутся?
фичи точно одни (все проекты на одной версии админки)
источник

O

Olga in QA — русскоговорящее сообщество
а возможно ли написать общие для всех кейсы по бизнес-логике и отдельные чек-листы по Ui - свой для каждого проекта?
источник

C

Cadabrum in QA — русскоговорящее сообщество
Cadabrum
Там отличия проектов насколько большое? Чисто ui, не может быть такого, что фичи разъедутся?
Вручную поддерживать несколько наборов кейсов - действительно сложно, 100% кто-то накосячит. Лучше декомпозировать конечно, и максимально переиспользовать тесты.
источник

DS

Denis Sitnikov in QA — русскоговорящее сообщество
Olga
а возможно ли написать общие для всех кейсы по бизнес-логике и отдельные чек-листы по Ui - свой для каждого проекта?
да, я как раз выделил в отдельные сьюты бизнес-логику и UI в первом проекте, который уже покрыл
источник

nA

nea Alecu in QA — русскоговорящее сообщество
Denis Sitnikov
если будет N проектов, и надо будет добавить в сьют авторизации, например, авторизацию через linked in, то вы редактируете каждый проект?
N проектов - N вариантов. Это как ветки в разработке, в перспективе каждая начинает жить отдельной жизнью с отдельным менеджментом, историей и условностями, которые понятны только нескольким посвященным.

При переиспользовании сущностей в режиме демо всегда всë просто, а на деле неизбежно появляются сущности "с мелкими отличиями". В итоге будет отчаяние и ненависть, бо рядом стоящие
AuthorizeAtLinkedin
AuthorizeAtLinkedin2
AuthorizeAtLinkedinVova
AuthorizeAtLinkedin2-1
AuthorizeAtLinkedinVovaTanya
AuthorizeAtLinkedinNew
уже не помогают, а бесят.

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

nA

nea Alecu in QA — русскоговорящее сообщество
От этого всего выгорание и забухание неизбежны.

Но вам может помочь понимание того, что излишняя оптимизация — может быть злом. Не всегда проектов N. Не всегда все надо обновлять. Не всегда все надо тестировать. Ограничения иногда наш друг, товарищ и еда, а иногда единственное спасение.
источник

nA

nea Alecu in QA — русскоговорящее сообщество
Идея какого-то единого набора тестов, которые можно прикладывать ко всем новым проектам (у нас платформа, у нас проекты в принципе идентичны, все дела) разумна, но только если все новые проекты на платформе поставляются as is, без тюнинга.

У меня был фэйл в таких условиях: вроде тесты показывают, что багов нет, а на деле багов выше крыши, заказчик злой, программисты злы, бухгалтерия зла, империя зла, а дурак — тестировщик, бо исходные данные были неверны ("Да там разница мелкая, только в юай, не парься!").

Да, все магазины на платформе в принципе похожи, как все люди друг на друга похожи. Но предлагать всем одни и те же ботинки — ой, будет бэмц…

С тестами та же проблема.

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

DS

Denis Sitnikov in QA — русскоговорящее сообщество
спасибо всем, кто отозвался, примерная модель образовалось. чувстую, прям в больное место попал :)
источник

nA

nea Alecu in QA — русскоговорящее сообщество
Denis Sitnikov
спасибо всем, кто отозвался, примерная модель образовалось. чувстую, прям в больное место попал :)
Бухать & Выгорать! (© на пиратском стяге нашего боевого судна)
источник

NN

Nick Nickc in QA — русскоговорящее сообщество
Lavrentiy Beriya
а не подскажете сайт где можно задачки брать в тестирование за деньги, типо фриланс? где-то в закладках лежал но потерялся
test.io, bugfinders(digivante.com)
источник

LB

Lavrentiy Beriya in QA — русскоговорящее сообщество
test.io лол, не знал что епам такой хернёй занимается
источник