Эфир Не нанять ли нам QA?

В эту субботу к нам в гости приходит Сергей Тимохин. инженер по качеству с 13-летним опытом, и да, мы будем говорить про QA

✅Сергей руководил QA-командами в Wargaming и Mail.Ru Group, участвовал в разработке легендарных проектов, включая World of Tanks
✅ В настоящее время — SDET в Future State, выстраивает процессы тестирования с нуля и поддерживает CI/CD пайплайны

Обсуждаем:
🟢 Как тестируют WOT Когда компании нужно нанимать QA, и нужно ли вообще
🟢Заменит ли ИИ инженеров по качеству
🟢Прикольные и правильные фреймворки взаимодействия QA и продакт-менеджеров

Когда: суббота, 26 апреля, 12:00 по МСК

Ссылка на эфир
Если нужны напоминалки,⏰ можно зарегистрироваться на эфир через Timepad

Таня, [ex-B2B 👩‍💻]
Семейка продактов

Держи ноги в тепле, голову в холоде, а код чистым!

Заведу рубрику с рекомендациями по автоматизации.

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

В языках с жесткой типизацией принято проверять значения на NULL. Но вот в Js/Python почему-то нет. Благо появились костыли в виде Typescript’a или mypy. Которые до запуска могут указать нам об ошибке и заставить проверить значение. Но если ими не пользуетесь?

Поверьте “лишняя” строчка кода может сохранить пару часов дебага и выяснения — почему тесты не запускаются. Могут быть неочевидные случаи например для примера посмотри тут:


response = boto3Client.list_images(
registryId="1232313141414",
repositoryName=repository_name,
maxResults=1000
)

for image in response["imageIds"]:
tag = image.get("imageTag")
check_tag(tag)



var envValue = process.env[name.replaceAll("-", "_").toUpperCase()];
fillValues(envValue)


Тут python и js, где берем элемент из объекта и не проверяя отправляем дальше. В этом случае объект может быть null/none. Что может привести к ошибкам дальше в коде, которые нужно будет дебажить.

Поэтому лучше в таких местах "явно" проверять значение на null или none.


response = boto3Client.list_images(
registryId="1232313141414",
repositoryName=repository_name,
maxResults=1000
)

for image in response["imageIds"]:
tag = image.get("imageTag")
if tag is None:
# handle case!
check_tag(tag)



var envValue = process.env[name.replaceAll("-", "_").toUpperCase()];
if (envValue === undefined || envValue === null){
// handle case!
}
fillValues(envValue)


Расследовали подобные баги?

#qaroomTips

Мы с тобой одной цели! Ты и я!

Или нет?

На заре моей карьеры мне транслировалась мысль:
Отдел тестирования – рыцари на защите, а все остальные… чет не очень.
Эта мысль не засела в моем сознании. Ну как так можно думать? Над качеством продукта работают все!

Например, с продукт менеджером отдел тестирования в одной лодке!

Но с другой стороны действия друг для друга могут быть не очевидны. Предлагаю ознакомиться с каналом @vladimir_merkushev.

Цель — попытаться понять ход мысли продактов.
Владимир много и интересно пишет, например, про технический долг аналогия очень удачная.

Недавно пост, как говорится, в руку был – про юридические нюансы при выпуске продукта.

Наслаждайтесь!

Читаете каналы смежных отделов?

#qaroomInfo

Тестируете логирование?
Посмотрите на код ниже что тут не так?


import os
import logging
import sqlalchemy as db

class DataBase:
def __init__(self):
self.user = os.environ.get("DB_USER")
self.db_name = os.environ.get("DB_NAME")
self.password = os.environ.get("DB_PASSWORD")
self.port = os.environ.get("DB_PORT")
self.host = os.environ.get("DB_HOST")

self.connection_string = f"postgresql+asyncpg://{self.user}:{self.password}@{self.host}:{self.port}/{self.db_name}"

self.conn = db.create_engine(self.connection_string)

logging.info(f"Connect to db {self.connection_string}")


🔎Ответ лежит на поверхности: в логах приложения выдаем информацию о базе данных, включая пароль! И, кстати, это пример не из воздуха, а из реальной практики.

Важность тестирования логирования я поднимал еще в первой лекции базового курса. Теперь хочу обсудить это в письменном варианте.

‼️Логи приложения важный аспект оперирования!

Когда приложение уже в релизе, многие инструменты по обнаружению и анализу ошибок становятся недоступны.
Тут на помощь приходят логи!

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

Приведу некоторые рекомендации при тестировании.

☑️Тестируйте на продакшен логировании. Обычно это info уровень. Для чего? При обнаружении проблемы: посмотрите в логи приложения. Сможете проблему обнаружить и понять с помощью логов. Если нет, значит в логировании проблемы, которые нужно исправлять.
☑️Наличие мусорных логов, которые мешают чтению. Бессмысленный спам который засоряет логи, очень мешает расследованиям. Возможно, это важная информация, но либо она передается неправильно, либо в приложении баг.
☑️Размер в 1GB логов за 1 час работы REST сервиса, скажет нам о том, что мы пишем явно что-то не то.

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

Дискуссионный вопрос — что писать в продакшен логи. Но ряд обязательных условий выделить можно:

☑️Изменение стейта или состояния. Например: платеж был pending, стал paid.
☑️Важные финансовые действия: покупки, продажи. Раскрывать приватную информацию в логах не нужно, достаточно описать факт.
☑️Если мы работаем с другими сервисами, мы должны видеть логи инициализации работы и запросы к ним.
☑️Любые ошибки, даже если они не привели к каким то критическим последствиям и на ваш взгляд не влияют на работу приложения. Поверьте вы, скажите себе спасибо когда будете расследовать странный баг из продакшена.

Идеального тестирования добиться сложно, но маленькими шагами мы можем улучшить этот процесс. Казалось бы логи. Но по опыту могу сказать, что об их качестве могут вспоминать только, тогда когда начинают копать проблемы с продакшена. При этом, обещая себе, что следующий раз они сделают логи лучше!

Разбирали инциденты по логам?

#qaroomThoughts #qaroomTesting #testing

Это что за покемон?!

В одном из постов спрашивали - читал ли я эту книгу? Сегодня она приехала. Оценим!

Читали?

#qaroomBooks

Новая - восьмая лекция уже в монтаже!

Лекция получилась убойной:
☑️ накопали баги в API;
☑️ перешли с postman на Hurl и написали на это Ci;
☑️ протестировали безопасность API.

Кстати девятая лекция уже в работе! На скрине результаты Ci бекенда после фиксов багов, которые нашли в восьмой 🤭.

Ждете новую лекцию? Рекомендую обновить контекст в первой лекции!

#qaroomInfo #bts001 #testing

Тяжело в учении, легко в работе!

Подытожим посты про пирамиды и про ящики на реальном примере.

В курсе лекций на канале, мы тестируем приложение. Основная функциональность этого приложения – планировщик задач на день, с интегрированным таймером.

Для более чистого примера возьмем пример малого теста (он же юнит, он же модульный) для бекенда.
У нас есть эндпоинт для добавления задачи. Сам эндпоинт имплементируется функцией

pub async fn add_activity(
session: Session,
store: Store,
new_activity: NewActivity,
) -> Result {
info!("add activity");
let account_id = session.account_id;
if let Err(e) = store.add_activity(new_activity.clone(), account_id).await {
info!("Activity not added{:?}", new_activity.clone());
return Err(warp::reject::custom(e));
}
Ok(warp::reply::with_status(
json(&new_activity),
StatusCode::CREATED,
))
}

На вход функция принимает:
☑️ объект для задачи;
☑️ некий объект сессии пользователя;
☑️ объект хранилища.

Чтобы написать юнит тест для этой функции нам нужно:
☑️ создать фейковый объект для сессии;
☑️ сделать мок объекта хранилища.

Тест может выглядеть так:
#[tokio::test]
async fn medium_test_add_activities() {
let docker = Cli::default();
let node = docker.run(create_postgres());
let store = prepare_store(node.get_host_port_ipv4(5432)).await.unwrap();
let account_id = 1;
store.clone().add_test_account(account_id).await;

let record = NewActivity {
title: "test".to_string(),
content: "test".to_string(),
time: 1,
};
let result = add_activity(get_session(account_id), store.clone(), record)
.await
.unwrap()
.into_response();
assert_eq!(result.status(), 201);
}

Теперь представим что у нас меняется реализация реального хранилища, при этом поведение системы измениться не должно (золотое правило рефакторинга).

❗️Наш тест упадет, так как у нас используется не реальное хранилище, а мок.
❗️То же самое произойдет когда мы поменяем имплементацию хранения сессии пользователя.

Все потому, что мы, помимо проверки функции добавления, еще завязались на детали имплементации. Это привело к тому, что наш тест становится хрупким к рефакторингу. Да, ещё его поддержка очень дорогая, так как нам нужно его править каждый рефакторинг.

❓Нужен нам такой тест? Нет, он проверяет не так много, зато проблем приносит в три раза больше.

Так что же с тезисом про «самый низкий возможный уровень»?

‼️Скажу, что в этом тезисе одно из главных слов – это «возможный». Если по какой-либо причине мы не можем написать тесты на низком уровне, значит идем выше.
Для данной функциональности нужно писать тест на уровне эндпоинта.

{
let add_body = &serde_json::json!(
{
"title": "awesome title",
"content": "awesome content",
"time": i32::MAX
});
let add_path = format!("/{}/activity", VERSION);
let add_req = warp::test::request()
.method("POST")
.header("Authorization", t.token.clone())
.path(&add_path)
.json(add_body)
.reply(&filter)
.await;
let raw_act = convert_to_string(add_req.body()).await.unwrap();
let new_act: NewActivity = serde_json::from_str(&raw_act).unwrap();
assert_eq!(new_act.time, i32::MAX);
assert_eq!(new_act.title, "awesome title");
assert_eq!(new_act.content, "awesome content");
assert_eq!(add_req.status(), 201);
// some code with get response below
}
Полный тест можно посмотреть тут.

В тесте помимо проверки основной функциональности мы также проверяем косвенную работу сессии и хранилища. Данный тест не будет падать при рефакторингах!

Этот пример показателен тем что:
☑️ мы проанализировали наш первый тест с точки зрения доступа к коду;
☑️ задизайнили наш тест с учетом поведения функциональности;
☑️ поместили тест на самый возможный низкий уровень пирамиды. А могли вынести и на е2е уровень. Что не совсем эффективно.

Надеюсь разжевал!

#qaroomThoughts #testingPyramid #testing

Что по ящику?

Наверняка знаете термины Черного и Белого ящика.

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

❕Тестирование это тестирование поведения системы, модуля, функции, фичи. Без тестирования внутренней имплементации. 

❌ «Белый ящик» как раз подразумевает тестирование имплементации, что приводит к нестабильным тестам которые нуждаются в постоянной поддержке. 

❌ «Серый ящик» это вообще чепуха, которую лучше не озвучивать.

Для примера давайте возьмем функцию логина. С точки зрения поведения нужно проверить:

☑️при верно введенных данных, получаем токен;
☑️при неверных – ошибку;
☑️ошибки не выдают информацию, которая может быть использована для взлома;
☑️обработку пользовательского ввода, чтобы не передавать сырой ввод пользователя дальше и не быть подверженными различными инъекциями;

Здесь не нужно проверять:

❌валидацию почты;
❌валидацию пароля.

Это должно быть проверено отдельно. Если в этой функции начнем проверять валидацию почты и пароля, то завяжемся на детали имплементации. А это приведет к тому, что если внутренняя логика валидации изменится – наши тесты для логина начнут падать. Хотя поведение логина не изменилось!

☝️Знание и понимание кода помогает проанализировать возможные сценарии поведения системы. Если по каким либо причинам это не описано в документации. Также мы можем провести ревью наших тестов на предмет пропущенных кейсов.

❔Возможно кто-то и подразумевает этот способ как серый ящик. Но мне кажется это не точно, и лучше не использовать этот термин. 

Согласны?

#qaroomThroughts  #testing

Выше по пирамиде.

Нижний ярус.

Продолжим разбирать практический пример использования пирамиды тестирования. Напомню что мы проверяем функцию валидации пароля.

Сама функция не будет существовать в вакууме. В нашем приложении она используется в функции логина при регистрации. 

Давайте подумаем над набором интеграционных тестов. Основными идеями для тестов на этом уровне будут:

☑️ убедиться что функция используется;
☑️ используется правильно;

Для этого проверим 2 кейса:

Т1: позитивный — вводим пароль, который отвечает требованиям;
Т2: негативный — пароль не проходящий по требованиям;

Если пойдём ещё выше по пирамиде - к е2е сценариям. Специальных тестов для функции проверки пароля уже не нужно. Фича на этом уровне является деталями имплементации функции логина. 

❕Главное правило тестирования —  тестировать поведение, не имплементацию!

В итоге получилось 15 тест кейсов для тестирования на модульном и интеграционном уровне. Тесты легко запускаются как на машине разработчика, так и на уровне CI. Что сокращает время получения фидбек о качестве фичи!

Раний фидбек приводит к ускорению Time To Market! В итоге все довольны!

#qaroomThoughts #testingPyramid #testing

Что вы могли пропустить в этом месяце:

❕Отпраздновали 1 год первому видео на YouTube канале qaroom!

❕Порассуждали о том что изучать: подходы или инструменты?

❕Подняли важный вопрос о пирамиде тестирования.

❕Поговорили о том кто же такие SDETы.

Какой пост для вас был самым интересным?

#qaroomInfo

От теории пирамиды к практическим примерам. Часть 2.

Оптимальный набор для тестирования функции валидации пароля. Вспомнить контекст можно тут.

Давайте на практике разберем как нам нужно спроектировать оптимальный набор тест кейсов. Напомню параметры:
✔️длина минимальная и максимальная(min, max);
✔️заглавные буквы(cap);
✔️набор спецсимволов и цифр(spec, digits).

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

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

У нас есть 2 глобальных класса: это валидный пароль и невалидный.

❗️Напомню что позитивные кейсы мы можем объединять, а вот негативные нет.

Далее каждый большой класс нужно разделить на подклассы для увеличения покрытия.

Я буду расписывать сразу подходящий тест кейс для каждого класса. В скобках указаны значения для условий.

Валидный пароль:

T1: (min=34, max=34, cap=2, spec=28, digits=1) набор необходимых символов согласно заданным параметрам. Пароль может быть таким - "AbcD1x!#$%&()*+,-./:;<=>?@[]^_{|}~". В данном кейсе очень классно, что мы ещё и граничные значения проверяем. Заодно я вбил все возможные спец символы;
T2: (min=2, max=8, cap=0, spec=0, digits=0) обнулим все требования. Данный кейс позволит нам проверить что при отключении любой из опции это действительно работает. Пароль тут может быть любым - password;
T3: (min=2, max=9, cap=2, spec=2, digits=1) теперь предлагаю проверить верхнюю границу настроек . Пароль - ABcD12!#$. Данный кейс позволит нам проверить кейс когда условия выполнены больше чем требуется. Так как это валидный пароль, но в коде могут быть ошибки когда требования могут жестко сравниваться с условиями;

Невалидный пароль:

Т4: (min=2, max=8, cap=0, spec=0, digits=0): Важно занулить спец символы, для уверенности, что фейл действительно из-за нужного параметра. Проверим минимальную длину, пароль - а;
Т5: (min=2, max=2, cap=0, spec=0, digits=0): проверим максимальную длину, пароль - ааа;
Т6: (min=2, max=8, cap=1, spec=0, digits=0): проверяем заглавные, пароль - аа;
Т7: (min=2, max=8, cap=0, spec=1, digits=0): проверяем специ символы - аа;
Т8: (min=2, max=8, cap=0, spec=0, digits=1): проверяем цифры - аа;
Т9: (min=2, max=8, cap=2, spec=2, digits=0): проверяем кейс когда одно условие выполнено, а одно нет. Пароль - “ААw!A” В данном кейсе 2ое условие выполним на половину;
Т10: (min=2, max=8, cap=0, spec=2, digits=2): пароль - “!$1d%”;
T11: (min=2, max=8, cap=2, spec=2, digits=2): пароль - “A!@235”;

Кстати, пока писал кейсы, понял что я не сделал проверки в коде! На то, что настраиваемые параметры не должны превышать максимальной допустимой длины пароля.

Т12: (min=2, max=2, cap=1, spec=1, digits=1): ожидаемые результат, приложение завершится с ошибкой;
Т13: (min=2, max=1, cap=0, spec=0, digits=0): так же проверим что макс не может быть меньше мин;

На мой взгляд – это достаточно оптимальный и полный набор проверок. Но, возможно, я не прав? Пишите в комментариях.

#qaroomThoughts #testingPyramid
#testing

Пока ехал на работу, слушал доклад. Не со всеми тезисами полностью согласен. Доклад тем не менее очень крутой. Пересекается с моими постами и в целом подходом. Очень рекомендую! https://youtu.be/gbsh-7yIyc4

А кто такие фиксики SDETы большой, большой секрет?
Согласно опросу мало кто в моем канале думает что SDET должен соответствовать своей каноничной роли.

Каноническое описание для меня это описание из книги «Как тестируют в Гугл» Здесь я увидел его впервые я увидел данную позицию.
Приведу небольшой отрывок.

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

Наверное, второе предложение – это ключевое что должно бросится в глаза. Хотя книга 2012 года, часть положений все же остается актуальными до сих пор.
В частности, все мы глубоко наслышаны про Shift Left и прочие техники. Ключевая особенность — делать надо быстро и желательно качественно. Поэтому позиция SDET на текущий момент играет важную роль в разработке. Разработчику некогда писать фреймворки для тестов или окружение, от него требуют фичей. Это не значит что разработчик может забить и не писать тесты. На мой взгляд, он обязан это делать. Работа SDETов в том, что бы облегчить и ускорить этот процесс.

Дальше выходят инженеры по тестированию, которые уже занимаются более сложными е2е сценариями и нефункциональными тестами. Хотя, часть нефункциональных тестов мы можем и обязаны уносить также на ранние этапы. Про это рассказывал на конференции.

Тестирование — это сложный домен. Мы можем бесконечно набирать людей в отделы тестирования, добавлять новые и новые должности, но это не решит проблемы. Ключевая задача инженера по тестированию — это внедрять и развивать лучшие практики по тестированию во всей команде. Поддерживать культуру тестирования, а главное, соблюдение ее во всей команде. Это сложно и во многих командах, может казаться, что не возможно.
Но только так можно избавиться от ярлыка «узкого горлышка» для отдела тестирования.

Что думаете?

#qaroomThoughts

От теории пирамиды к практическим примерам

Проблематику озвучил в этом посте. Чтобы не быть голословным предлагаю рассматривать все на примерах.

У нас веб-сервис с авторизацией и есть некоторые требования к паролю, все параметры настраиваемые:

☑️ минимальная длина;
☑️ максимальная длина;
☑️ минимальное количество заглавных символов;
☑️ минимальное количество спецсимволов;
☑️ минимальное количество цифр;

К вам приходит задача, которая утверждает что данная валидация сделана в такой-то ветке.

❗️Внимание знатоки! ❗️

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

Свои рассуждения напишу сразу, но надеюсь вы задумались.

Верный ответ:
☑️ Посмотреть в код и проанализировать написанные тесты на все требования. У нас простой пример бизнес логики и тут все проверки должны быть протестированные на модульном уровне.
☑️ Далее мы смотрим вообще эта функция или модуль подключены к эндпоинту регистрации. Есть ли тест на уровне интеграционных тестов?
☑️ Запустим приложение и проверим позитивный кейс.
☑️ Все!

Если на одном из шагов у нас отрицательный ответ, то нужно дописывать тесты.

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

В следующих постах я принесу примеры с кодом.

#qaroomTesting
#testingPyramid

Еще Египтяне подозревали, что пирамиды важны!

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

Вроде как это программистская кухня мы это не трогаем. И вот появляются доклады вида: «Как мы оптимизировали X UI/e2e тестов и т.д.». Ребята доблестно рассказывают как они борются с последствиями неверного подхода к организации автоматических скриптов для регрессии.

Основная проблема не в том что Х тестов нестабильны. Проблема более концептуальная, она в игнорировании пирамиды тестирования.

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

Кстати, я поднимал вопрос измерения покрытия уже в четвертой лекции (https://youtu.be/nEt0TCpUWGU) моей базовой стратегии. Там мы считаем покрытие с учетом всех существующих тестов.

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

А вы учитываете юнит тесты?

#qaroomThoughts
#testingPyramid

Учить конкретные инструменты или подходы?

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

Сейчас записываю лекцию в которой мы перепишем наш е2е фреймворк с Postman на Hurl.

Hurl это инструмент написанный на Rust по вверх libcurl, который добавляет удобства в использовании curl из коробки.

Почему же не использовать curl? В curl, к сожалению, из коробки нет возможности написать тесты и нужно будет использовать сторонние скрипты, например bash.

Люблю bash, но у начинающих с ним могут возникать сложности.
Давайте разберем пример: мы пишем тест на GET запрос. Пример из общедоступных API что бы вам нужна была только командная строка:

curl https://catfact.ninja/fact

простой тест на баше мог бы выглядеть так:

#!/usr/bin/env bash

curl https://catfact.ninja/fact

# тут мы сравниваем результат выполнения последней команды с 0, 0 это успех все остальное ошибка.
if [[ $? -ne 0 ]]; then
echo “test failed with error $?”
exit $?
fi

echo “test passed”
exit 0;

Данный тест проверяет выполниться команда или нет, предлагаю его улучшить:


#! /usr/bin/env bash

# получаем только статус код ответа
status_code=$(curl -s -o /dev/null -w "%{http_code}" https://catfact.ninja/fact)

# сравниваем его с ожидаемым
if [[ $status_code -ne 200 ]]; then
echo “status code is not 200, received $status_code”
exit 1
fi

echo “test passed”
exit 0

Но мы хотим проверить не только статус код, но и контент ответа. Тут нам нужно написать еще более сложный скрипт:


#!/usr/bin/env bash

# получаем боди в json формате и статус код на новой строке
response=$(curl -H "Accept: application/json" -X GET https://catfact.ninja/fact --write-out '\n%{http_code}\n')

# фильтруем наш сырой ответ получаем боди
body=$(head -n 1 <<< $response)
# а тут достаем отдельно статус код
status_code=$(tail -n 1 <<< $response)

# сравниваем код ответа с ожидаемым
if [[ $status_code -ne 200 ]]; then
echo “status code is not 200, received $status_code”
exit 1
fi

# еще немного магии, получаем длинну текста в ответе и убираем из подсчета двойные кавычки
fact_length=$(jq '.fact' <<< $body | tr -d "\"" | wc -c )
# получаем значение длинны ответа
from_response_length=$(jq '.length' <<< $body)

# сравниваем 2 показателя
if [[ $from_response_length -ne $fact_length ]]; then
echo “content length: $fact_length not equal variables length $from_response_length”
exit 1
fi
echo “test passed”
exit 0

Это достаточно примитивный тест. Безусловно хочется оптимизировать. Написать хелпер функции и, в общем, накатать фреймворк. Но зачем?

Я предлагаю рассмотреть инструмент, который похожие вещи делает чуть проще ниже пример для hurl:


GET https://catfact.ninja/fact
Content-Type: application/json; charset=utf-8
HTTP 200
[Asserts]
jsonpath "$.fact" != null
jsonpath "$.length" > 0

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

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

#qaroomTesting #qaroomInfo

Ровно год назад я выложил первый урок курса! Я долго его мусолил, мониторовал, уточнял у знакомых - «Как оно?»

За год на канале появилось уже 11 видео, 7 в рамках курса и 4 в различных рубриках. Скажу честно, когда я начинал, то за год я планировал закончить базовую стратегию. Но немного не рассчитал своих сил и внешних факторов.

Пока, по грубым прикидкам, для окончания базовой стратегии нужно еще 5-6 лекций. Возможно, в ходе этого появятся дополнительные видео в различные рубрики. Так что работы достаточно в этом направлении.

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

Пишите в комментариях ваши предложения и идеи по развитию канала и курса.

#bts001 #testing

🤝Куда вы попали?
За последнюю неделю присоединилось много человек! Приветствую вас и благодарю за внимание!

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

Здесь появляются посты с идеями, книгами и рабочими лайфхаками, которыми хочется поделиться.
С навигацией по каналу поможет 👉 этот пост.

Общаться в обсуждениях рекомендую так, как будто собеседник сидит перед вами.

В моем канале НЕ будет - мемов, развлекательного контента и историй.

Добро пожаловать!

Поделитесь в комментариях, чем вы занимаетесь и какие темы из сферы тестирования интересны.

#qaroomInfo

Выступал на QA Crew подлодке сегодня и с радостью делюсь записью своего доклада!

В докладе поговорили о важности нефукнциональных проверок на каждом этапе разработки. Я показал много примеров кода. Так же есть репозиторий с примерами, которые можно пощупать.

https://youtu.be/sEmhZBYaB8A

Комментарии, предложения и вопросы приветствуются!

#qaroomPresentation

Разница между Джуниором и Сеньором.

Джуниор:
☑️ Обнаруживаешь баг, который разламывает систему и радостно несешь его! Трубишь в чатике - ОМГАД, у нас критикал-блокер!
☑️ Убеждаешь разработчика, что он должен это пофиксить прямо сейчас.
☑️ Он переключается на твой «блокер».
☑️ Оказывается, что это «ложный баг».
☑️ Либо система настроена неправильно. Либо я, как пользователь что-то не понял.

Мидл:
☑️ Со временем скилл растет, мы узнаем продукт и таких факапов становится меньше. Но, тем не менее, иногда бывают. Например, при работе со сторонними сервисами.

Сеньор:
☑️ Объясняешь Джуниорам что это НЕ баг. Плавно направляешь в нужное русло.

Лид:
☑️ Баги при взгляде на приложение выстраиваются по ранжиру, согласно северети и приорити.

Ну а если серьезно, на мой взгляд, одно из более точных и коротких различий:
☑️ Джуниор: нужно расписать задачу и контролировать ее выполнение.
☑️ Мидл: некоторые задачи можно не расписывать, контроль почти не требуется.
☑️ Сеньор+: сам найдет задачи и себе и отделу.

Углубление в технологии не делает тебя автоматически крутым специалистом. «Выучу вот это и стану сеньором» – так не работает! Сеньорность про базовые знания и самостоятельность.

Технологии могут устаревать. Изучайте основы!

#qaroomThoughts

С коллегами тестировщиками провели ревью телеграм каналов про тестирование и создали единую папку для подписки.

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

✅ Подписывайтесь тут https://t.me/addlist/PNmSaWa9ktw2YjRi

Внимание! Это не учебная тревога!

Новое видео «Page Object Model. Tests» уже на канале!
Было много факторов, которые оттягивали этот момент, но наконец это свершилось.
Я долго думал делать ли полноценную лекцию, либо выносить в другую категорию. Но понял, что материал объемный и тянет на полноценный урок.

Напомню, чтто на прошлом занятии мы написали фреймворк на selenium для е2е сценариев со стороны клиента.

В новой лекции:
✔️немного поговорим о том, почему не стоит иметь мейн класс, для организации работы с POM;
✔️перепишем все end-to-end сценарии на наш новый фреймворк;
✔️также вы получите несколько домашних заданий, которые я с удовольствием проверю.

Рекомендую смотреть с открытым редактором кода. Пробуйте реализовывать самостоятельно, а видео используйте для самопроверки.

Буду рад комментариям и предложениям по улучшению видео и в целом курса.

В следующей серии:
✔️мы наконец избавимся от Postman в нашем бекенде (перепишем все на Hurl);
✔️поговорим об OpenApi spec и Swagger;
✔️разберем более детально безопасность для API.


Следите за обновлением на канале!

#bts001 #testing #QA #qaroomInfo

А пока смотрите новое видео «Page Object Model. Tests» и, давайте обсуждать в комментариях.

«Everything as code»
«Тесты – лучшая документация»
Мед в уши!
Правда похоже на мои лейтмотивы? Но это слова не инженера по тестированию, а архитектора! Знакомьтесь – Руслан Сафин!

Случайно попал на его бомбический доклад про тестирование архитектуры. И, конечно, подписался на канал.

На днях проходил марафон для аналитиков (BA+QA=лучшие друзья), где выступил Руслан. Остальные доклады тоже заслуживают внимания!

Не будет выводов, просто хотел познакомить вас с крутым человеком!

Хотя, будут: смотрите шире и изучайте чем живут смежные специалисты.

#qaroomInfo

«Сила слова» отдела тестирования!

В последнем посте в комментариях уповали на то, что у отдела тестирования нет «силы слова»!

На мой взгляд, это общая тенденция индустрии. Хотя, есть и исключения.

Возникает логичный вопрос: а почему?
Мне кажется, дело в низкой технической компетенции в отделах тестирования. Вина тут, безусловно, не в людях, занимающих должности. А в компаниях, которые пытаясь сэкономить денег набирают специалистов без инженерного бэкграунда. Кто-то учится, а кто-то нет, но в итоге получаем низко эффективные отделы. Да ещё на слова которых могут и не обращать внимания, нашли баги и молодцы.

«Каждая лягушка свое болото хвалит», но я считаю, что в тестировании без инженерного бэкграунда делать нечего. Уверен, данное утверждение валидно для большого количества позиций в IT.

#qaroomThoughts

Большое количество багов в таск-трекере – показатель некомпетентности отдела тестирования.

Выдохните, сейчас объясню.
Цель тестирования  – это не найти все баги мира, а показать текущее качество продукта. Обнаруженные и оформленные баги – это пост эффект данной активности.

Если баг попал в Jira, о чем это говорит? 
Что его НЕ обнаружили
☑️ на стадии статического анализа;
☑️ на уровне модульных тестов на CI;
☑️ на уровне интеграционных тестов;
☑️ на уровне системных тестов на CI;
☑️ нефункциональные тесты на CI;
☑️ в момент приемки новой фичи* 
* Последний пункт со звездочкой. У меня на проектах принято баги, которые нашли в мерж реквестах не заводить, а писать их в комментариях к мерж реквесту. Конечно, не блокирующие мерж баги оформляются).

Если кратко: по какой-то причине баг был пропущен на предыдущих этапах.

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

Вернемся к названию поста. Получается, если баги “утекают” в мейн, то стоит задуматься над нашими процессами. Наша задача состоит в том чтобы наладить процесс по раннему обнаружению проблем!

Что думаете?

#qaroomInfo

Объявлен месяц подготовки к новому выступлению, количество постов может сократиться!
p.s: выступать буду тут https://podlodka.io/qacrew
p.s.s: 7 лекция монтируется.

Как начать автоматизировать?

Есть идеальный вариант когда руководитель говорит:«Вот тебе время сиди и разбирайся».

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

Типичный ход размышлений инженера:
➡️ Регресс и занимает очень много времени. Надо это автоматизировать!
➡️ Вот выучу язык программирования, фреймворк и все на свете (нужное подчеркнуть);
➡️ Но у меня нет на это время, потому что… см. пункт 1

В итоге попадаем в замкнутый круг и капкан бесконечных “туториалов”. А “регрессим” по-прежнему руками.

Так что же делать?
Просто брать и делать!

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

☑️ Напишите скрипты для настройки окружения, чтобы реально все работало по “одной кнопке”. Запустил скрипт и через N времени получил готовое окружение на нужной ветке с нужными настройками.
Что использовать: Bash, Batch scripts, PowerShell (оно тебя сожрет). Для более продвинутых можно попробовать на python/ruby/javascript.

☑️ Теперь надо проанализировать какие действия и проверки делаем каждый день/неделю. Условно, если мы делаем что-то более одного раза, то это кандидат на автоматизацию.
Зайти в приложение и прокликать кнопки? Тут уже нужно, что-то более прикладное. Для веба можно взять Selenium IDE, например, и на нем накликать. Положить себе и радостно запускать, фиксить косяки и улучшать.
Для API можно взять тот же Postman (я это показывал еще в первой лекции), либо более продвинутый Hurl, где почти не надо писать код.

☑️ Мы уже получили некоторые артефакты, дальше уже можно смотреть прикладные вещи. Подбираем курсы по конкретным инструментам, изучаем и начинаем строить фреймворки в той области где болит больше всего.

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

Го начнем?

#qaroomForJunior