Привет, Хабр! На связи программный комитет FrontendConf. Расскажем, как мы составляем программу нашей конференции и боремся за её актуальность — проводим исследования и общаемся с аудиторией.

FrontendConf = доклады + общение + опыт

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

Привет, Хабр! Меня зовут Антон Морозов, я инженер по тестированию в Яндекс 360. Я работаю над мобильным Яндекс Диском — это проект с тысячами тест-кейсов, который развивается уже тринадцатый год. 

Погружение в продукт и новую команду — непростая задача для новичка, но нам удалось выстроить безболезненную адаптацию. В статье поделюсь практиками в команде QA, которые помогли нам за последние четыре года успешно адаптировать новичков (с оттоком 0% за 4 года)

По мере увеличения кодовой базы любая компания начинает испытывать потребность в упорядочивании разрозненной документации, иными словами — создании собственной «базы знаний». О чём стоит помнить при выборе конкретных инструментов и как сделать их одинаково удобными для разработчиков и техписателей, попробуем разобраться в сегодняшней статье.

Привет, Хабр! Меня зовут Кирилл Веркин, я Senior QA в СберМаркете. Эта статья о том, как за 1,5 года моя команда прокачала уровень инженерной культуры с нуля до самого высокого среднего балла в компании среди 105 команд. 

(Да, у нас есть уровни инженерной культуры!) Хочу рассказать, как мы их оцениваем и повышаем, почему это круто бустит развитие и как соревновательный аспект делает жизнь инженера гораздо интереснее. А ещё это история о том, как у меня получилось повлиять на командный результат будучи тестировщиком — на заметку тем, кто хочет не только расти сам, но и «менять мир».

29-30 ноября прошла конференция для аналитиков FlowConf 2022. Основная особенность конференции — ее ориентация на конкретные практические рецепты. Одним из направлений, которое содержит много таких рецептов, стал Docs As Code или, в более широком смысле, DocOps в работе аналитика. В посте представляю обзор этого направления.

Казалось бы, с документацией всё просто — пишешь, публикуешь, поддерживаешь актуальность. Например, вот у нас в Ozon есть пользовательские инструкции на docs.ozon.ru: выглядит просто как текст на сайтике, что ж необычного-то в его размещении и в целом в работе техписателей? 

Если начать раскапывать, всплывёт ещё несколько вопросов:

• где хранить тексты и почему Confluence не подходит?

• как красиво оформить документацию с помощью статических генераторов сайтов

• зачем техписателям знать git и CI/CD?

• в какой момент пора искать разработчиков в команду и превращать документацию в платформу?

На связи Катя — руководитель отдела технических писателей в Ozon, и сегодня расскажу о платформе Docs Ozon изнутри.

Привет! Я Катя, руководитель группы технических писателей в Ozon. Сейчас нас уже 9 человек и целая платформа документации, но коллеги всё ещё не всегда понимают, чем мы занимаемся ​:)

Из непонимания появляются запросы вида: “Хотим себе собственного техписателя в команду, но не знаем, чем именно он будет заниматься”. В итоге команда подстраивается под тренды и заводит себе документацию, но через пару месяцев оказывается, что доку не читают, а техписатель плавно превратился в аналитика.  

Поэтому пришло время делиться опытом и рассказывать о каких-то концептуальных штуках ​:)

Всем привет! Меня зовут Нина, я работаю в команде платформы для продавцов  AliExpress. Сегодня я расскажу о том, как совместно с коллегами из команды Knowledge Engineering мы адаптировали систему для загрузки товаров, чтобы всё работало в пару кликов. Поехали!

Привет, Хабр! Мы продолжаем рассказывать о развитии «AliExpress Россия» (об истории этого проекта можно почитать здесь), и сегодня речь пойдёт о том, почему нам понадобилось сделать версию мобильного приложения маркетплейса для Рунета, чем китайские интерфейсы отличаются от европейских и как адаптировать приложение на пять миллионов строк кода под локальный рынок на лету. 

Мы запустили блог на «Хабре» совсем недавно, и в комментариях к первой же статье было много вопросов о том, когда и как мы планируем устранять проблему с логином на сервисах AliExpress. И сегодня я расскажу, что вообще пошло не так, как мы чинили баг(и), с чем уже удалось справиться, а что будет улучшено в будущем.

Месяц назад мы приняли участие в конференции SQA Days. Наши эксперты выступили с докладом (вот презентация, ждите подробную статью и видео выступления) и провели ряд активностей на стенде. Сегодня мы хотим рассказать об одной из них – и интересна она тем, что по факту это задание, которое в «AliExpress Россия» используется на собеседования тестировщиков.

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

В заголовке использовано слово сложной, под которым можно понимать все, что угодно. Утверждение о том, что 2 * 2 = 4, если вдуматься, тоже очень не просто. Но в данном случае всё банальнее. Речь идёт о ЕСКД, ГОСТ, ОСТ и тому подобных скучных терминах, отягчаемых бюрократической процедурой согласования.

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

Сразу решили, что попробуем сделать документацию актуальной, т.е. обойтись без покраски травы в зелёный цвет. И сразу решили, что это будет Asciidoc. Почему? Потому что из текстовых языков разметки для подготовки документации он наиболее функциональный, а разворачивать неповоротливые DITA и Docbook не хотелось.

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

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

Однако помимо ТЗ есть еще куча другой документации, которую тоже стоит проверить. Как минимум вычитать, нет ли ошибок. Давайте посмотрим, какая бывает документация:

В больших проектах, состоящих из десятков и сотен взаимодействующих сервисов, всё чаще становится обязательным подход к документации как к коду — docs as code.

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