Spock

 

 

как вы относитесь к такой штуке, как PicoContainer ?  (https://cucumber.io/...cucumber/state/)

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

https://cucumber.io/...ep-definitions/

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

навыки навыками, но ведь главное это какой именно вклад Вы сможете сделать на данной вакансии

 

 

и я не помню чтобы мне попадалась статья лучшего качества на эту тему. Пока никто не написал лучше - просто must read.

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

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

чтобы не было как в анекдоте,

Начинающий Тестировщик: НТ

Синьор: С

Начинающий Тестировщик: Синьор, а расскажите мне про клиент-серверную архитектуру, а то я вообще зеленый в этой теме

Синьор: Конечно! Вот тут клиент, тут сервер ... а потом накидываем холодный бэкап ... проверяем безопасность от хакеров ... сейчас выберем какой жесткий диск купить ... устанавливаем ХАМРР базу данных ...

Начинающий Тестировщик: Синьор, а Вы с кем сейчас разговариваете?

а вообще правда в том, что надо все величины внутри проверять, начиная с 200.00, затем 200.01 и так далее до 499.98 и 499.99

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

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

но конечно по методу границ таких проверок не надо делать

 

 

ЕСЛИ сумма <=200 И сумма >=499,99, ТО скидка = сумма/100*2.

тут видимо скорее:

ЕСЛИ сумма <=200 ИЛИ сумма >=499,99, ТО скидка = сумма/100*2

а вообще да, "значение в середине" это избыточный тест, но его всегда и все делают, типа как Богу помолиться, это не поможет но всё равно так делают

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

так что перед кликом просто скрольните страничку используя вызов джаваскрипта (гуглится)

а вообще это хорошая идея кандидатов отсеивать

ну как бандосы "на фене" начинают разговаривать и сразу "палят" подсадного

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

и смотришь как тот выкрутится :)

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

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

тестирование должно быть более исследовательским чем заскриптованным

а тест-кейсы не нужны, Вас же не заставляют их писать

тестируйте фичи , регрессионное тестирование по чек-листу

и работайте с начальством отдела разработки и инициативной группой чтобы было больше юнит-тестов, компонентных тестов и АПИ тестов

 

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

 

Вокруг меня, как правило, разработчики считают, что на тесты нужно тратить минимум времени. Пишут для формального покрытия кода, и пишут в стиле "2+2=4" вместо проверки хотя бы граничных значений.

 

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

вводить такую систему просто

пусть отдел разработки в "Definition of Done (DoD)" добавит пункт "написать автоматические тесты"

а Вы потом при тестировании просто иногда заглядывайте в код, и смотрите чтобы там нормальные тесты были (конечно иногда там и должно быть 2*2=4, например если это тест АПИ а функционал уже протестирован уровнем ниже)

да, просто пришел и тебя берут ))) Находишь любую компанию и говоришь "буду у вас работать", а они такие "Ок. Когда вас оформлять ?" ))

user12 да, это работает

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

тогда берут

вообще эти слова не имеют смысла

имели бы смысл в формате "оценка влияния А на Б", то есть "оценка влияния какого-то фактора на что-то"

например: "оценка влияния трезвости тестировщика на точность проведения тестирования"

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

а для парсеров надо что-то типа:

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

 

 

Тут опять же я просто думал что если диспатчить action то этим действием можно заменить компонентный тест, поправьте если я не прав. В остальном придельно понял. Спасибо

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