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

Подход к ведению тестовой документации и выбранные для этого инструменты — важная часть процесса разработки, которая напрямую влияет на качество продукта. Особенно важно поддерживать тестовую документацию в актуальном виде. Qase может быть одним из подходящих для этого инструментов. Кроме того, он помогает объединить мир ручного тестирования с автоматизированным, а описанные тест-кейсы — с их исполнением.

В статье мы рассмотрим реализацию связки Qase с Playwright и GitLab CI, которую мы используем в SmartHead: от создания проекта до получения отчетов об автоматизированном тестировании.

В SmartHead мы активно обмениваемся опытом и я хочу поделиться некоторыми подходами к организации рабочих процессов для начинающих тестировщиков.

Представь, что к тебе подошел руководитель проекта и сказал, что нужно протестировать автомобиль. Что будешь проверять в первую очередь?

Изменив одно местоимение, можно на 90% увеличить показатель кликабельности (CTR) кнопки, которая приведет новых пользователей. Дописав одно предложение, можно увеличить количество оплаченных покупок и снизить нагрузку на саппорт. Поставив одну запятую, можно было бы сохранить 5 миллионов долларов. ОК, третий пример про договоры, но все равно показателен.

Текстам в интерфейсе уделяется незаслуженно мало внимания. Их игнорируют, про них забывают, про них вспоминают, когда уже поздно: дизайн сделан, код написан, огребаем на проде. Печально. А ведь хороший текст — один из самых дешевых способов сделать продукт лучше, и заработать больше денег.

Исследование Nielsen Norman Group показало, что лаконичный, объективный (без маркетологического хвастовства) текст, который легко читается пользователем, увеличивает юзабилити сайта на 124%. Только текст. UX и навигацию не трогали.

В вашем продукте (сайте, программе, приложении и т.д.) есть английский текст, и вы хотите, чтобы он приносил вам выгоду, а не просто занимал место? Читайте статью дальше. Я расскажу, как писать по-английски нужно, и как не нужно.

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

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

Функциональное программирование может отпугивать сложностью и непрактичностью: «Я далек от всех этих монад, пишу на обычном C#, в докладе про функциональщину ничего не пойму. А если даже напрягусь и пойму, где мне потом это применять?»

Но когда объясняет Скотт Влашин, все совершенно не так: его доклад о композиции с конференции DotNext 2019 Moscow — пример того, как можно доносить функциональные идеи простыми словами. Он за час перешел от бананов к монадам так, что второе кажется немногим сложнее первого. А в конце объяснил, почему осмыслить композицию полезно даже тем, кто не собирается покидать мир ООП. Примеры кода в докладе как на F#, так и на C#.

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

Говоря о качестве, обычно имеют ввиду некое соответствие требованиям. Часто под требованиями подразумевают те, что явно выдвинул заказчик, аналитик или кто-то другой, кто ставит задачи. Хуже, если они трактуются как неоспариваемые, и это неявно ведёт к самоцели — удовлетворить требования заказчика. Это часто происходит в аутсорсе, и такой фокус внимания негативно влияет на конечный результат — то, что видят и с чем работают пользователи.

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

Качество — это про «сделать классно» с точки зрения многих сторон: разработки, заказчика и конечного пользователя.

Как это сделать? Сложно. Начать стоит с формирования mindset на «встроенное» качество. Расскажу о принципах, которые могут помочь в этом.

Мы всё-таки смогли дойти до третьей части и добрались до самого интересного — организации асинхронных вычислений.

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

Теперь посмотрим, как можно управлять потоком исполнения (control flow) в случае обработки асинхронных задач.

• Параллелизм (часть 1)
  
  
  • Потоки: scheduling, сон
  • Синхронизация: Spinlock, семафоры, барьеры памяти
  • Атомарность: TAS, CAS
  
  
• Кооперативность (часть 2)
  
  
  • Корутины (coroutines)
  • Акторы
  
  
• Асинхронность (часть 3, текущая)
  
  
  • Event loop
    • select
  • Callbacks
  • Async Monad
  • Промисы (promises, обещания)
  • async/await — промисы + корутины
  
  

• доклады по iOS- и Android-разработке,
• воркшоп по Firebase от Google,
• трек по UX/UI от преподавателей Британской высшей школы дизайна.