Запись моего доклада с митапа Ministry of Testing Abu Dhabi

#video #testing #talk
Это становится для меня традицией зимой принимать участие в митапе от Ministry of Testing Abu Dhabi.
В этом году я рассказывал о проблемах современного тестирования.
В прошлый раз мой доклад был про контрактные тесты.

Спасибо организатору митапа Антону - за то, что пригласил. Надеюсь, не последний раз принимаю участие в таком мероприятии.

О пользе “огурцов” в рационе тест инженера

#testing #automation #fun
Тема “Behavior Driven Development” подхода и инструментов будоражит умы тестировщиков и автоматизаторов уже много лет. Сообщество делится на два лагеря. Первые говорят о том, что: BDD “не работает!”, “не нужно!”, и “лишние абстракции и слои!”. Вторые парируют в ответ: “Вы неправильно используете BDD!”, “У нас работает!”, “Вы все врете!”.

Я использовал BDD инструменты в автоматизации на разных проектах. Это был Specflow (C#), Cucumber (Java, Scala), Thucydides (Serenity) + JBehave, встроенный BDD в Rest Assured, Gauge (Java). Кроме тех, что перечислил - есть еще много инструментов и оберток, использующих подходы BDD на разных языках и платформах.

Почему же у многих инженеров “полыхает” при этом слове - BDD? Или все-таки BDD может нести прохладу и силу Земли? Давайте разберемся. Все совпадения с реальными людьми и проектами прошу считать вымыслом. У вас на проекте, конечно, все по-другому и все работает.

Как “продают” BDD заказчику?
- вся команда будет следовать парадигме BDD (когда собирается 3-amigo митинг - и тестер, девелопер и бизнес аналитик вместе пишут эти самые сакральные сценарии, понятные для всех. И так происходит на каждую задачу в беклоге)!
- менеджеры и сам заказчик сможет писать бизнес-сценарии, которые потом будут автоматизироваться!
заказчик, да и вообще люди из бизнеса, смогут понимать, что тестировалось и что не работает - просто просматривая отчет!
- тестировщики смогут легким движением руки писать сценарии и безболезненно автоматизировать их!
все участники команды смогут понимать тесты и писать их (и девелоперы, и даже вон тот бородатый девопс если нужно)!
- в отдельных случаях получаем еще красочные отчеты (привет, Serenity)!
- можно легко сменить тестовый фреймворк и оставить сценарии без изменений!

Что происходит в реальном мире?
1. Когда разработку и бизнес разделяет океан и часовые пояса, а бизнесу (как обычно) нужно деливерить “быстро и на вчера” - BDD как процесс или вовсе не начинает работать или затухает. Тестер (или какой-нибудь приглашенный Agile коуч) могут конечно пытаться раздуть этот тлеющий уголек, но реальность обычно жестока.

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

3. Если у тестировщика нет достаточных скиллов для написания сценариев и автотестов для них - нанимается отдельно взятый инженер-автоматизатор. Задача этого человека будет как раз превращение этих самых сценариев в автотесты. (Привет рутина!)

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

5. Приглашенный автоматизатор или сам тест инженер быстро понимают, что слой BDD добавляет только больше “боли” в поддержке. Сценарии растут, становятся монструозными полотнищами из 30+ шагов. Вроде шаги хочется и переиспользовать, но это не так-то просто. Автоматизатор терпит (и поглядывает на рыночек за окном). А там - HR манят сказочными офферами на новые проекты без BDD).

6. В итоге количество сценариев переваливает за мыслимые и немыслимые рамки. Поддерживать их становиться сложно. Заказчик уже и забыл, что сценарии в формате текста.

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

8. Заказчик счастлив. Команда ликует. Менеджмент открывает шампанское!

9. И только где-то в другой компании, поседевший автоматизатор продолжает вздрагивать при звуках - “Given, When, Then...”

О пользе “огурцов” в рационе тест инженера (Продолжение)

Так ли плох BDD? Может мы его неправильно “варим”?

Есть ведь успешные кейсы! Многие зарубежные продуктовые компании успешно используют подход BDD. Так команды маленькие, в одной локации. Бизнес заинтересован в понятных сценариях. Если тестеры что-то неясно - он пойдет и быстро “дернет” аналитика в соседней комнате и уточнит детали. Менеджмент реально смотрит детали отчетов, думает над бизнес-сценариями каждой фичи. В JIRA тикете описание идет сразу в формате Gherkin.

Не только Gherkin! Кроме того, есть такие инструменты, которые дают ту же абстракцию как и Cucumber, но не вкладывают ограничений в виде Given-When-Then. Например тот же Gauge. В нем сценарии можно писать в вольном стиле. Можно даже хранить тест-кейсы в виде Markdown файлов - и выгружать в TMS по надобности.

Текст может быть полезен! Плюс, в отдельных случаях (я сам видел и участвовал), при грамотном использовании этой текстовой “надстройки” и data-driven подхода - можно добиться того, что тест инженеры с минимальными знаниями автоматизации - смогут писать огромное количество новых тестов быстро “копируя” шаги и подставляя новые данные в тест. (Можно даже для одного текстового сценария сделать запуск на разных браузерах и даже платформах).

Так хорош или плох этот BDD? Вам решать:) Но я думаю, что все зависит от того - как использовать инструмент и процесс. Применять ли инженерный подход для устранения “боли” - или “продолжать есть кактус”. Искать способы применения инструмента в команде - а если таковых нет - устранять боль и двигаться дальше.

А что вы думаете о BDD?

HTTP/3 - что это такое и как это изменит HTTP?

#web #http
Сегодня хочу поделиться интересным докладом о новом этапе развития протокола HTTP - "HTTP/3 is next Generation HTTP. Is it QUIC enough?".
Теперь он будет работать не на TCP(TLS 1.2+) поверх IP, а на QUIC + UDP (TLS 1.3) поверх IP.

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

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

[Простыми словами] Что такое цифровая подпись?

#security #blockchain #cryptography

Зачем это вообще?
В прошлых заметках мы уже кратко познакомились с методами, которые позволяют скрыть передаваемую информацию от третьих лиц (шифрование).

Довольно часто при передаче сообщений между двумя сторонами нужно решить две большие задачи:
1. Как получателю быть уверенным, что сообщение отправлено именно отправителем?
2. Как получателю быть уверенным, что сообщение не было изменено злоумышленником во время передачи?

Обе эти задачи решаются с помощью механизма цифровой подписи (digital signatures).

Какие бывает виды цифровой подписи?
Алгоритмы цифровой подписи могут быть основаны на методах симметричного и асимметричного шифрования. Чаще используется последний.

Как работает цифровая подпись?
Суть цифровой подписи сообщения (в упрощенном виде) заключается в сочетании шифрования и хеширования:
- Вычисляется хеш документа с помощью хеш-функции.
- Хеш документа шифруется с помощью приватного ключа отправителя.
- Документ + зашифрованный хеш отправляются получателю.
- Получатель с помощью той же хеш функции получает хеш сообщения.
- Получатель с помощью публичного ключа отправителя расшифровывает подпись и получает хеш от отправителя.
- Хеш от отправителя и хеш, полученный на стороне получателя сравниваются. Если они равны - то можно сказать, что сообщение не было модифицировано и личность отправителя подтверждена.

Примеры алгоритмов цифровой подписи?
RSA-PSS, DSA, ECDSA, Rabin signature, Schnorr signature.

Как цифровая подпись используется в блокчейне?
Каждый раз, когда вы в кошельке совершаете новую транзакцию, “под капотом” транзакция подписывается вашим ключом. В дальнейшем в блокчейне можно проверить - кто создал ту или иную транзакцию.
В Bitcoin изначально использовался алгоритм ECDSA. Буквально пару лет назад этот алгоритм заменили и сейчас транзакции можно подписывать с помощью алгоритма Шнорра. У него есть ряд весомых преимуществ - особенно для мультиподписи транзакций. Сам алгоритм очень интересный - расскажу о нем подробнее в следующих заметках.
В Ethereum сейчас используется ECDSA, Cardano - Ed25519.

Какие атаки могут быть на сообщение с цифровой подписью?
- Подделка документа (коллизия первого рода) - попытка подбора документа под определенный хеш. Крайне маловероятно - т.к. документы обычно большого размера.
- Получение двух документов с одинаковой цифровой подписью (коллизия второго рода).
- Социальные атаки. Основаны на манипуляциях с ключами: кража приватного ключа, попытка заставить отправителя подписать неправильный документ, замена публичного ключа отправителя.

Звучит интересно, но как “попробовать это руками”?
В следующих заметках, я расскажу об инструментах и приложениях, которые можно использовать для шифрования и подписи сообщений на вашем компьютере.

Шифруем и подписываем данные с gpg и Mailvelope

#blockchain #security #cryptography
В прошлых заметках мы говорили о шифровании (тут и тут), а также о цифровой подписи.
Но одно дело просто узнать о концепции - а другое дело - “пощупать” своими руками.

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

gpg
Открытый стандарт шифрования OpenPGP существует в двух имплементациях PGP и GPG (GnuPG). Если первая - закрытая, то вторую любой пользователь установить на свой компьютер (как в Unix так и в Windows).
Установка утилиты описана - здесь.
Что можно делать с ее помощью:
- генерировать ключи (публичные и приватные): gpg --gen-key
- смотреть какие ключи уже импортированы: gpg --list-keys (а также - gpg --list-public-keys и gpg --list-secret-keys)
- импортировать свои ключи из внешних источников: gpg --import public_key.txt
- экспортировать свои ключи (в файл): gpg --export -a "email" > pub.asc (или gpg --export-secret-key -a "email" > priv.asc). Без перенаправления в файл - можно просто вывести в консоль текст ключа.
- выкладывать свои ключи на открытые сервера ключей для распространения: gpg --keyserver pgp.mit.edu --send-keys KEY_ID
- зашифровать и подписать сообщение для заданного получателя: gpg --encrypt --sign --armor -r samplerecipient@mail.com message.txt
- дешифровать данные: gpg --decrypt message.txt.gpg
- ставить цифровую подпись на сообщение: gpg —detach-sign message.txt
- проверять подлинность подписи: gpg —verify message.txt.sig

Mailvelope
Если утилита командной строки - слишком “дедовский” способ для вас - то есть отличный выход. Можно установить плагин Mailvelope для Google Chrome (есть также для Firefox и Edge). С его помощью можно делать то же самое, что и с gpg - только в браузере и с приятным и удобным интерфейсом.
О том как установить и настроить этот плагин можно почитать тут.

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

А вы шифруете свои сообщения?

Учим теорию распределенных систем бесплатно, без регистрации и смс

#distributedsystems #learning #course

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

Сегодня я хотел бы порекомендовать отличный (и бесплатный!) курс по распределенным системам от Мартина Клепманна. (А он между прочим автор того самого Кабанчика). Осторожно - все на английском!

Курс преподается в University of Cambridge.

Что полезного можно узнать из курса?

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

- канонические теоретические задачи от двух генералов до Византийских.

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

- понятие репликации и кворумов, а также алгоритмы броадкаста сообщений

- алгоритмы консенсуса - от самых простых до еще более простых (RAFT)

- как функционирует Google Spanner и разные средства для коллаборации между пользователями

Курс мне очень понравился. Особенно хорошо и подробно автор разбирает алгоритмы консенсуса. RAFT вообще можно просто по слайдам брать и сразу имплементировать (может руки дойдут как-нибудь сделать).

Более упрощенно и живо о распределенных системах говорит Chris Colohan в этом курсе.

Более академично (и слегка монотонно) Lindsey Kooper рассказывает еще в этом курсе. Контент очень перекликается с Клепманном. Чуть более подробно рассматривается время и синхронизация в системах. Мало практического применения.

Как работает TLS/SSL

#security #cryptography #web

Я тут открыл для себя дополнение к Телеграм заметкам - Telegraph. Тут нет ограничений по количеству символов, легко редактировать посты и вставлять туда картинки и видео. Попробую писать основные заметки в таком формате.

Сегодня мы поговорим о практическом применении шифрования - TLS/SSL.

Почему тестирование - это не просто или в поисках идеального тест инженера

#testing

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

Подробнее - тут

Что такое блокчейн и как он работает?

#blockchain #distributedsystems

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

Подборка статей о тестировании и инженерии в целом [1]

#testing #engineering #compilation
Не хочу заниматься простым пересказом чужих статей, поэтому решил наиболее интересные из них сохранять и публиковать в виде подборок. По каждой статье будет краткое описание - почему стоит ее читать.
Надеюсь, такой формат тоже будет полезен.

Сегодня - компиляция numero uno.

gRPC с Postman - первые впечатления

#grpc #testing

Всем доброе утро!
Вчера попробовал Postman для тестирования gRPC сервисов.
Мои впечатления - тут

Что делать, если затянула "рутина" и совсем нет времени на обучение?

#learning

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

Шпаргалка по Linux command line

#testing #linux

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

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

А какие команды вы используете чаще всего?

Обзор книги "Perfect Software: And Other Illusions about Testing"

#testing #books

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

[Thursday's Mix #2] Code Health, тестирование в Lyft, качество телескопа James Webb и другое

#testing #engineering #compilation

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

Сравниваем инструменты тестирования gRPC сервисов

#grpc #testing #tools

Не так давно я говорил о работе с gRPC в Postman. Сегодня - чуть более расширенная версия с большим количеством инструментов.
Сравнивал только самые базовые возможности инструментов.

Обзор книги "The Culture Map"

#books #management

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

Почему не стоит "слепо" доверять инструментам и отчетам

#testing #performance

История о том, что "зеленые отчеты" могут скрывать проблемы.

Недетерминированные ошибки в распределенных системах

#testing #paper #distributedsystems

Надежны ли известные распределенные системы, такие как Cassandra, ZooKeeper и другие? Какие сложные ошибки возникают в таких системах? Есть ли возможно такие ошибки обнаружить и предотвратить?

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

[Thursday's Mix #3] Тестирование Metaverse, качество видео в Netflix, UI тесты в Pinterest и другое

#testing #engineering #compilation

Снова четверг - и снова новая подборка статей.