Size: a a a

2019 August 14

DA

Dmitry Archie in QA Alliance
Дмитрий Игоревич
шож там за разрабы такие пряморукие
Мидлов стараемся не брать.
источник

DA

Dmitry Archie in QA Alliance
А, ещё из работы с гитом у нас "1 фича = 1 коммит". То есть перед вливанием в мастер у нас все коммиты ветки сливаются в 1 результирующий с красивым описанием. И хорошей приметой считается прогнать на нём тесты (но если ты видел что тесты зелёные до слияния, то можно и без них: ведь там по факту ни буквы кода не поменялось)
источник

DA

Dmitry Archie in QA Alliance
Это позволяет откатывать разом целую фичу и использовать историю коммитов мастера для ченджлога
источник

DA

Dmitry Archie in QA Alliance
Знакомый проходит собеседование. Ему дали листбоксер. Я удивлён что оно до сих пор запускается на десятке.
источник

В

Вовка in QA Alliance
Dmitry Archie
А, ещё из работы с гитом у нас "1 фича = 1 коммит". То есть перед вливанием в мастер у нас все коммиты ветки сливаются в 1 результирующий с красивым описанием. И хорошей приметой считается прогнать на нём тесты (но если ты видел что тесты зелёные до слияния, то можно и без них: ведь там по факту ни буквы кода не поменялось)
у нас такое же, ребейз со сквошем комментов 🙂
источник

DA

Dmitry Archie in QA Alliance
Есть 2 секты по этому поводу и раньше я принадлежал к другой :)
источник

R(

Roman (rpwheeler) in QA Alliance
Дмитрий Игоревич
Привет. Это хорошая тема и важно понимать, что здесь серебряной пули нет. Очень много факторов которые влияют.
Мне больше симпатизирует разработка по гит-флоу... очень мощный инструмент, если которого строго придерживаться, то будет относительно все хорошо..

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

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

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

Далее, когда планируемый фунционал закончен, и смержен с девелопом.. из девелопа собирается релизная ветка. И по ней уже прогоняется полное регрессионное тестирование..
При обнаружении багов в релизной ветке идем таким же путем...

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

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

Только с
> будет относительно все хорошо..
я, разумеется, не согласен -- и наглядно это доказывал и показывал :)
источник

ДИ

Дмитрий Игоревич... in QA Alliance
Roman (rpwheeler)
Нормально расписал. У нас такое на прошлой работе тоже было.

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

или у тебя есть примеры, которые лучше?
источник

R(

Roman (rpwheeler) in QA Alliance
Дмитрий Игоревич
я имел ввиду, что будет лучше, ежели работать по другому флоу..

или у тебя есть примеры, которые лучше?
Ну да. Флоу это лишь одна из слагаемых.

Мержи девелопа в фича-бранч перед пулл-реквестом, прогон проверок по фиче-бранчу смерженному с девелопом, потом после мержа в девелоп прогон проверок по девелопу -- всё тут важно, и чтобы проверки были, и они покрывали нужные места, а не только флоу.

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

R(

Roman (rpwheeler) in QA Alliance
TWIMC
У ребят из Postman не совсем прямые руки на документацию, и я долго не мог заставить валидировать Json schema в респонсе с required.

Пошарился там-сям, и нашёл что респонс для валидации надо *сначала таки распарсить*.

Вот так заработало:

pm.test("response json is valid for tv4", function () {
   var parsed_response_body = JSON.parse(responseBody);
   pm.expect(tv4.validate(parsed_response_body, node_schema)).to.be.true;
});

pm.test("response json is valid for ajv", function () {
   var parsed_response_body = JSON.parse(responseBody);
   pm.expect(ajv.validate(node_schema, parsed_response_body)).to.be.true;
});
источник

R(

Roman (rpwheeler) in QA Alliance
Отягощающее обстоятельство -- "тест зелёный", пока ты не прописываешь что определённый элемент required, после этого "моя твоя не понимай" (а до этого "всё хорошо было").

О обязательных проверках полей был не один вопрос в чате автоматизаторов.
источник

K

Korwwyn in QA Alliance
Ну за required - об этом вся json schema

У меня так проверки стоят
const jsonData = pm.response.json();

pm.test('Schema is valid', function() {
   const result = tv4.validateResult(jsonData, schema);
   if(!result.valid) {
       console.log(result);
   }
   pm.expect(result.valid).to.be.true;
});
источник

K

Korwwyn in QA Alliance
Еще из забавных штук - если у вас есть сваггер, то можно тянуть json schema прямо оттуда.

Pre-requested script:
let schema = {};
const url = pm.environment.get("url");

pm.sendRequest(url + '/someapi/api/json', function (err, response) {
   schema = response.json();
});

pm.environment.set("schema", schema);


В Tests:

const jsonData = pm.response.json();
const schema = pm.environment.get("schema");

pm.test('Schema is valid', function() {
   const result = tv4.validateResult(jsonData, schema);
   if(!result.valid) {
       console.log(result);
   }
   pm.expect(result.valid).to.be.true;
});

Тогда не надо прописывать ожидаемую схему нигде, она в сваггере
источник

В

Вовка in QA Alliance
Korwwyn
Еще из забавных штук - если у вас есть сваггер, то можно тянуть json schema прямо оттуда.

Pre-requested script:
let schema = {};
const url = pm.environment.get("url");

pm.sendRequest(url + '/someapi/api/json', function (err, response) {
   schema = response.json();
});

pm.environment.set("schema", schema);


В Tests:

const jsonData = pm.response.json();
const schema = pm.environment.get("schema");

pm.test('Schema is valid', function() {
   const result = tv4.validateResult(jsonData, schema);
   if(!result.valid) {
       console.log(result);
   }
   pm.expect(result.valid).to.be.true;
});

Тогда не надо прописывать ожидаемую схему нигде, она в сваггере
бывает что не всегда сваггер обновляют до корректной схемы, подымал уже тут как-то этот вопрос…
У нас же валидация схемы идет в Cypress в Postman чет пока не дошел писать тесты
источник

K

Korwwyn in QA Alliance
Вовка
бывает что не всегда сваггер обновляют до корректной схемы, подымал уже тут как-то этот вопрос…
У нас же валидация схемы идет в Cypress в Postman чет пока не дошел писать тесты
Ну так надо делать чтобы там была корректная схема 🤷🏻‍♀️
источник

K

Korwwyn in QA Alliance
Нормально делай - нормально будет
источник

В

Вовка in QA Alliance
Korwwyn
Нормально делай - нормально будет
это само собой разумеется, но иногда наши разрабы забывают ее обновлять
источник

D

Daria in QA Alliance
Korwwyn
Еще из забавных штук - если у вас есть сваггер, то можно тянуть json schema прямо оттуда.

Pre-requested script:
let schema = {};
const url = pm.environment.get("url");

pm.sendRequest(url + '/someapi/api/json', function (err, response) {
   schema = response.json();
});

pm.environment.set("schema", schema);


В Tests:

const jsonData = pm.response.json();
const schema = pm.environment.get("schema");

pm.test('Schema is valid', function() {
   const result = tv4.validateResult(jsonData, schema);
   if(!result.valid) {
       console.log(result);
   }
   pm.expect(result.valid).to.be.true;
});

Тогда не надо прописывать ожидаемую схему нигде, она в сваггере
Оооо, спасибо))) еще лучше
источник

В

Вовка in QA Alliance
А я вот нашел классный учебник по JS
https://learn.javascript.ru/
источник

В

Вовка in QA Alliance
если кому интересно
источник