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

Попросили Костю, frontend-разработчика Naumen, рассказать, какие возможности DevTools он использует в работе и на что стоит обращать внимание.

1️⃣ Как открыть DevTools, если F12 не сработал

Самый простой способ — клавиша F12 для Windows/Linux. На macOS сочетание отличается, но открыть DevTools можно не только с клавиатуры.

Например, через контекстное меню — нажать правой кнопкой мыши на элемент страницы и выбрать «Исследовать элемент». DevTools откроются сразу на нужном месте.

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

2️⃣ Как работать с версткой во вкладке Элементы

Вкладка Элементы показывает DOM-дерево страницы — структуру документа, из которого собран интерфейс. 

Здесь можно:

• навести курсор на элемент и посмотреть, где он находится на странице

• быстро найти нужный блок через селектор

• посмотреть размеры, фон и отступы

А еще можно посмотреть доступность — как элементы переключаются через Tab.

3️⃣ Как находить итоговые стили 

Если у элемента много CSS-правил, я перехожу во вкладку Вычисленные.

Там собраны все итоговые стили элемента — включая те, что пришли через наследование или заданы браузером. Можно быстро найти нужное свойство, например, border-radius, и понять, какое значение реально применяется.

4️⃣ Как проверять изменения без правок в коде

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

После обновления страницы все возвращается как было.

5️⃣ Как разбирать запросы во вкладке Сеть

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

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

6️⃣ Как подменять ответ бэка

В DevTools можно изменить ответ запроса и посмотреть, как на него отреагирует интерфейс.

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

7️⃣ Как проверять работу при медленном интернете

DevTools позволяют проверить, как работает интерфейс при плохом соединении. Во вкладке Сеть можно:

• выбрать готовые профили — 3G, 4G

• настроить собственную скорость сети

• протестировать поведение приложения в режиме офлайн

8️⃣ Как работать с локальными данными

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

1. Локальное хранилище — данные, которые сохраняются надолго и не исчезают после перезагрузки страницы.

2. Сессионное хранилище — данные, которые живут только пока открыта вкладка.

3. Файлы cookie — похожи на локальное хранилище, но у них есть срок жизни и дополнительные ограничения по источнику.

Все это можно просматривать, изменять и очищать. 

9️⃣ Как менять геолокацию и часовой пояс

DevTools позволяют изменить геолокацию и часовой пояс, не меняя настройки операционной системы.

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

🔟 Как записывать пользовательские сценарии

Инструмент Регистратор умеет записывать действия пользователя на странице — фиксируются шаги, например, клики и переходы по интерфейсу.

После записи сценарий можно воспроизвести, отредактировать, сохранить и отправить коллегам.

ИИ-помощник для анализа требований

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

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

Рассказываем, как они собирали данные, какие подходы пробовали и как в итоге пришли к решению на базе RAG.

1️⃣ Чем занимается техпресейл

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

Чаще всего работа техпресейла с клиентом начинается с опросника — Excel-документа с требованиями.

2️⃣ Почему Excel-файл оказался неудобным для анализа требований

Типичный опросник — это таблица с тремя колонками:

• требование клиента

• какой продукт соответствует

• комментарии

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

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

3️⃣ С чего мы начали автоматизацию

Сначала нужно было собрать данные. Поэтому первым шагом мы:

1. Собрали все опросники за год в единый массив.

2. Привели их к единому формату.

3. Классифицировали требования.

4. Проверили и почистили данные от дублей и неточностей.

В итоге получился датасет примерно из 2 000 требований, который стал основой нашей базы для тестирования ИИ-помощника.

4️⃣ Почему классические модели не сработали

Первой идеей было использовать классические методы анализа текста. Мы пробовали TF-IDF, Bag-of-Words и стандартные модели классификации.

Но столкнулись с двумя проблемами:

• низкое качество классификации

• дисбаланс данных

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

5️⃣ Как мы пришли к RAG-подходу

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

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

Так мы пришли к подходу RAG (Retrieval-Augmented Generation) — LLM сначала находит факты в базе знаний, а уже потом формирует ответ.

6️⃣ Как работает наш ассистент

Сервис работает в Telegram-боте и поддерживает два сценария.

Вопрос в чате — пользователь задает вопрос, бот ищет информацию в базе знаний и формирует ответ.

Загрузка Excel-файла — пользователь загружает файл с требованиями, после чего сервис проходит по каждой строке и автоматически заполняет:

• соответствие (да / нет / не знаю)

• комментарий с объяснением соответствия

7️⃣ Из чего состоит база знаний

Мы используем два источника:

• документацию по продуктам Naumen

• структурированные опросники из прошлых проектов

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

8️⃣ Какие есть ограничения у ассистента

ИИ-ассистент помогает быстрее разбирать требования, но полностью заменить аналитика он пока не может.

Например, иногда клиенты присылают требования, которых еще нет в базе знаний. В таких случаях бот отвечает «не знаю», и требование разбирает специалист.

Также иногда встречается типичная проблема LLM — галлюцинации. Поэтому финальную проверку ответа все равно делает системный аналитик.

Как перестать тратить полдня на один вопрос в чате

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

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

В распределенных командах работают два формата общения:

• Синхронный — похож на живой разговор: встреча, быстрый чат, обсуждение в реальном времени.

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

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

Формат общения лучше выбирать под задачу. Я ориентируюсь на простое правило:

• Асинхронно — если есть время подумать и нет горящего дедлайна. Например, аналитик разбирается с SQL-запросом в начале спринта.

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

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

Чтобы переписка не превращалась в длинную цепочку уточнений, сообщение должно отвечать на три вопроса:

1. Что происходит?

2. В чем проблема?

3. Что нужно от собеседника?

Например:

Делаю импорт отчета клиента. Вот ссылка. Получаю ошибку Invalid format. Можешь посмотреть формат файла?

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

Почему чаты постоянно отвлекают

Частая ситуация: работаем над задачей → приходит уведомление → открываем чат → через 30 минут читаем какой-нибудь спор, который вообще нас не касается. Чтобы не распыляться, я выделяю отдельные блоки времени, когда разбираю все сообщения — «окна хаоса».

Однако «окна хаоса» не будут работать, если уведомления приходят каждую минуту. Поэтому важно настроить каналы:

• критичные чаты — уведомления включены

• обсуждения без срочности — выключены

Почему важна культура обратной связи

Когда сообщение прочитано, но в ответ тишина — это создает тревогу. Вполне очевидно, что собеседник будет приходить с вопросами дополнительно.

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

Как подружить работу дизайнера и аналитика

Думаем, многим знакома ситуация: на встрече все обсудили, договоренности и сроки зафиксировали — разошлись работать с ощущением ясности. Однако в процессе оказалось, что результат каждый представлял по‑своему.

С Настей, руководителем команды проектирования интерфейсов, разобрали эту ситуацию на примере взаимодействия аналитиков и дизайнеров.

1️⃣ Почему при согласованных требованиях все равно возникает недопонимание?

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

2️⃣ Как ты это проверила?

Я решила не опираться только на ощущения и провела быстрые интервью. Задала 20–25 коллегам два вопроса и попросила ответить коротко:  

1. Что ты делаешь на работе как аналитик или дизайнер?  

2. Что, по твоему мнению, делает другая сторона?

3️⃣ Что оказалось самым показательным в ответах?

Разница в уверенности в своих знаниях. Аналитики чаще говорили, что не до конца понимают, из чего состоит работа дизайнера и почему одни задачи занимают 2 недели, а другие делаются за пару часов. Дизайнеры, наоборот, обычно хорошо представляют работу аналитиков.

4️⃣ Какие формулировки сигнализировали о недопонимании?

• «Дизайнеры делают красиво, но малофункционально».  

• «Не понимаю, что дизайнер делает две недели».  

• «Красивый интерфейс — это субъективно».  

• «Да там же просто пару экранов, что тут обсуждать?».

• «Потом допилим UX, сейчас главное выпустить фичу».

Эти фразы редко звучат в лоб, но задают тон обсуждению решений.

5️⃣ Откуда появляется мнение, что дизайнер делает красиво, но не думает о функциональности?

Чаще всего это следствие негативного опыта: когда человек сталкивался с работой дизайнера, который сделал пиксель-перфект, но не успел в срок. Или сделал красиво и стильно, но не подумал о том, насколько это сложно или дорого в разработке. Или же решение оказалось неудобным, неполным по сценариям или «ломалось» на системных ограничениях. Такой опыт легко обобщается и проецируется на других дизайнеров.

6️⃣ Почему возникает вопрос «что ты делал две недели»?

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

7️⃣ Насколько справедлив тезис «красиво = субъективно»?

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

8️⃣ Как правильно формулировать задачу для дизайнера?

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

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

9️⃣ Что в итоге помогает снизить напряжение между аналитиком и дизайнером?

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

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

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

Как перестать быть центром всех решений и не потерять контроль :)

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

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

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

1️⃣ Что происходит, когда процессы держатся на одном человеке

Я пришла в Naumen в 2015 году. В 2020 у меня появилась первая команда из трех аналитиков. Через год — уже две команды. Сейчас это три команды: три тимлида, два техлида и двадцать аналитиков.

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

2️⃣ Три страха, которые мешают передавать процессы

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

1. Я стану не нужна

2. Перегружу команду

3. Команда что-то сделает не так

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

А еще я поняла: если процесс живет только при моем участии — это слабое место, а не моя ценность.

3️⃣ Как мы перестроили систему консультаций

Раньше все было просто: любой сложный вопрос — ко мне. Я объясняла одно и то же разным людям, и это отнимало все больше времени.

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

• Опытные аналитики по каждой заявке

• Скриптолог дня для базовых техвопросов

• Техлиды для сложных техвопросов

• Третья линия как финальная инстанция

В этой схеме больше нет обязательного шага «спросить у Кати» :)

Важно, что я не просто объявила новые правила. Я объяснила команде, зачем им это, и дала возможность сказать, если что‑то не работает.

В результате консультации ускорились, экспертиза выросла, а я перестала быть узким горлышком.

4️⃣ Как мы перестали тратить часы на планирование дежурств

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

Теперь оставила себе только рамки: сколько слотов нужно закрыть и какие роли должны быть в дежурствах. Все остальное передала команде.

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

Я больше не держу в голове десятки нюансов — команда решает их самостоятельно.

5️⃣ Как быть с кризисными ситуациями

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

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

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

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

Когда задача считается выполненной

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

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

Мы поговорили с коллегами и попросили их рассказать, в какой момент для них задача считается завершенной. Их ответы читайте ниже.

Настя, тестировщик:

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

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

Ваня, системный аналитик:

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

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

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

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

Олег, android-разработчик:

Задача выполнена, когда:

1. Функциональность реализована и проверена вручную — примерно так, как это сделал бы тестировщик, но без учета конкретных тест-кейсов.

2. Новое поведение решает цель задачи, а не просто повторяет постановку. Иногда по ходу работы находится вариант проще для разработки/поддержки или удобнее для пользователя — выбираю его. Фича должна закрывать потребность.

3. Пограничные случаи поведения (corner cases) проработаны и учтены. В постановке не всегда учитываются моменты, которые становятся заметны в коде. Например, что показать на мобильном клиенте при 500 ответе сервера или при долгой загрузке из-за задержки ответа сервера.

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

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

Как развивать документацию и продвигать техписателей

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

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

С чего вообще началась эта работа и какую задачу вы перед собой ставили?

Мы начали с целей. Во‑первых, хотелось сформировать понятное представление о роли технических писателей внутри команды. Во‑вторых — понять, чего заказчики действительно ждут от документации.

Как вы к этому подошли на практике?

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

Еще мы выделили ключевых заказчиков и сгруппировали их. Это были аналитики и руководители продуктов, разработчики и тестировщики, поддержка, инженеры инфраструктуры, коллеги из маркетинга и дизайна. Благодаря этому вместо 51 интервью получилось провести 19, этого оказалось достаточно.

Как проходили интервью и что оказалось самым сложным?

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

Сложнее всего было работать с эмоциональными запросами. Потому что важно не останавливаться на эмоции, а докапываться до сути. Очень помогал метод «5 почему»: позволяет превратить раздражение в конкретное и решаемое требование.

Что получилось после обработки всех интервью?

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

Как вы поняли, за что браться в первую очередь?

Использовали простой фреймворк приоритизации «ценность / усилия». Смотрели не только на то, как часто звучит проблема, но и на силу боли. Поэтому, например, поиск в документации стал приоритетнее аналитики — о нем говорили реже, но намного острее.

Какие результаты уже есть?

Мы собрали регламенты и знания о работе технических писателей в одном месте, сделали публичный каталог услуг, обновили интерфейс документации вместе с дизайнерами и разработчиками, а документацию по API переработали совместно с командой разработки: улучшили навигацию и примеры.

Твой главный вывод из этого опыта?

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

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

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

1️⃣ С чего начинаем тестирование верстки?

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

• максимально короткие значения — точка, пробел;

• максимально длинный текст, который можно ввести;

• соответствие ограничениям из постановки — например, максимально доступно 64 символа.

Если ограничений в ТЗ нет, смотрим, какой тип поля используется в базе данных. Часто это varchar(255), от этого и отталкиваемся при проверке.

2️⃣ Почему проверяем текст с пробелами и без?

Очень частый кейс: текст с пробелами красиво переносится, а без пробелов — вылезает за границы или ломает блок.

Иногда нам кажется, что пользователь так точно не напишет, но ничто не мешает ему назвать кнопку: «дезоксирибонуклеиноваякнопка». Поэтому проверяем с пробелами и без пробелов, а еще смотрим, как ведет себя перенос строк.

Для таких проверок удобно использовать максимально широкие буквы:

• для кириллицы — «Щ»;

• для латиницы — «W».

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

3️⃣ Что проверяем в макете?

Например, в макете Figma мы смотрим:

И, конечно, отступы между всеми элементами по вертикали и горизонтали.

4️⃣ Как проверяем реализацию?

В браузере используем стандартные DevTools: смотрим вкладку Elements + разделы Styles и Computed.

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

Так проще напрямую сравнивать реализацию с макетом и не теряться в длинных CSS-цепочках.

5️⃣ Что важно знать о состояниях элементов?

Чаще всего это кнопки. В DevTools можно вручную включить состояния:

• :hover

• :active

• :focus

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

6️⃣ На что еще обращаем внимание?

Отступы могут быть реализованы через padding (внутренний) и margin (внешний).

Важно помнить, что высота текстового блока определяется line-height. Если высота строки отличается от макета — поплывут и расстояния между элементами, даже если padding и margin заданы верно.

7️⃣ Когда удобно считать руками, а когда — линейкой?

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

Для текста и иконок лучше ориентироваться на границы блоков и отступы, а не пытаться измерять «на глаз».

При этом в тестировании верстки почти всегда появляется вопрос баланса: где достаточно базовых проверок, а где уже начинается избыточный pixel perfect.

Интересно сравнить подходы: какие проверки верстки вы считаете обязательными в своей практике, а какие — избыточными? 

Развитые софт-скилы для аналитика — +1000 к долгосрочному профессиональному успеху, ведь с ними преуспевать в работе будет проще. Благо софты, как и харды, всегда можно прокачать. 

Поэтому делимся несколькими важными для аналитика софт-скилами и рассказываем о методах тренировки этих «мягких» навыков.

Стратегическое мышление, или, иначе, helicopter view

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

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

Фасилитация встреч

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

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

Понимание потребностей и выявление требований

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

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

Самоорганизация

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

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

Коммуникация и обмен информацией

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

Как развивать: через практику живого общения с другими людьми и через понимание, что перед нами человек, которому, как и нам, важна ясность. Документы — это тоже общение. Концепцию можно передать через схемы, диаграммы, таблицы, они проще воспринимаются при чтении. Можно использовать user stories и рассказывать истории так, чтобы командам разработки и заказчика были понятны суть и ценности предлагаемого решения.

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

Мы поговорили с Лизой, аналитиком по информационной безопасности, о том, как она работает с этими требованиями и что помогает избежать разночтений с заказчиком.

Почему регистрация событий ИБ — это всегда вызов

Событие ИБ — состояние системы, указывающее на важное с точки зрения безопасности действие, например, нарушение политики ИБ или сбой. 

Звучит просто, но в реальности возникает множество проблем:

• требования часто сформулированы абстрактно — «иные действия пользователей», «события, связанные с безопасностью»;

• невыполнение требований ИБ может заблокировать весь проект;

• нет универсальной базы — нормативные документы дают общее направление, а у каждого заказчика есть свои внутренние требования и особенности.

Откуда берутся требования

Во внедрении я сталкиваюсь сразу с несколькими источниками:

• требования по защите персональных данных — например, приказ ФСТЭК № 21;

• документы регуляторов с описанием инцидентов и состава событий;

• отдельные требования финансовых организаций;

• внутренние документы заказчика, к которым не всегда есть доступ;

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

Недавно в нормативке появились практические ориентиры. ФСТЭК выпустил рекомендации по базовой настройке регистрации событий безопасности — с примерами настройки логирования в ОС.

Как я структурирую требования по событиям ИБ

Чтобы работать с этим массивом, я условно делю требования на четыре группы.

Общие требования

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

Общий перечень событий

Самый опасный пункт — «иные действия пользователей». Моя тактика: фиксировать конкретный список событий, показывать демо и добиваться согласования, чтобы исключить разночтения.

Состав полей события безопасности

Важно понимать не только что регистрируется, но и какие атрибуты попадают в лог. Я всегда ставлю себя на место специалиста SOC: хватит ли этих данных, чтобы расследовать инцидент?

Мониторинг и передача в SIEM-систему

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

Что я вынесла из практики

1. Требования в ТЗ — это только часть картины, всегда нужно копать глубже.

2. Требования меняются по ходу проекта и это нормально.

3. Все договоренности важно фиксировать письменно.

4. Нужно учитывать не только нормативные документы, но и локальные требования заказчика.

5. Про SIEM-интеграцию стоит думать сразу, чтобы не пришлось переделывать позже.

6. Важно заранее договориться, кто и сколько хранит логи.

→ Подробнее своим опытом Лиза поделилась в статье.

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

Делимся ее ответами на непростые вопросы, с которыми может столкнуться руководитель в команде джунов.

Как понять, что сотрудник застрял в задаче, но боится сказать?

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

Как быть, если команда боится просить помощи, даже когда тяжело?

Я сталкивалась с этим в своей команде: каждый видел, что у других завал, и считал, что жаловаться неуместно. Начала проговаривать на общих созвонах, что просить помощи — нормально, это не слабость. Потом попробовала сама писать в личку с конкретными вопросами. До сих пор периодически пишу: «Привет! Вижу, что у тебя много задач. Давай заберу какую-нибудь?» и почти всегда в ответ получаю ссылку на задачу, которую можно передать. Ведь принять помощь гораздо проще, чем просить о ней самому.

Что делать, если в команде очень разные стили работы?

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

Как говорить о повторяющихся ошибках, чтобы не потерять доверие?

Если ошибка повторяется или нарушаются договоренности, я говорю об этом строго, но без давления. Наедине обсуждаем, почему так произошло и что помешало. Также подробно разбираем, как можно было поступить по-другому. Человек не закрывается и понимает, что ошибка — не повод для страха, а точка роста.

Как помочь, если сотрудник теряет уверенность в себе?

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

→ Подробнее своим опытом Вика поделилась в статье.

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

Диана, инженер по тестированию в Naumen, делится личным опытом: как перестать бояться задавать вопросы, говорить о багах без конфликтов и выстраивать рабочие отношения на старте.

Как я справилась со страхом задавать вопросы

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

В этот период меня очень поддержал наставник. С ним можно было обсудить, как корректно сформулировать баг, что именно стоит спросить у разработчика и как не растеряться на созвоне. Он сказал мне важную мысль: «Даже самый глупый вопрос — это нормально, если ты действительно хочешь разобраться».

Как говорю о багах, чтобы меня поняли

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

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

Когда я сообщаю о баге, всегда прикладываю:

• шаги воспроизведения;

• скриншоты или видео;

• ожидаемое и фактическое поведение;

• логи.

Что я делаю, если разработчик говорит «у меня все работает»

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

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

Ответы коллег могут быть сухими и перегруженными техническими деталями. Если я не до конца поняла, я прямо пишу об этом и прошу объяснить проще.

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

Что помогает выстроить рабочий контакт:

• приносить максимум информации;

• избегать обвинений — мы ищем решение, а не виноватого;

• предлагать созвон, если переписка не помогает;

• не бояться переспрашивать;

• напоминать аккуратно, если задача «зависла».

Почему важно уточнять требования

Аналитики формируют требования, а тестировщики проверяют реализацию. Казалось бы, все должно быть просто: есть ТЗ — идем по нему. Но на практике почти всегда возникают нюансы.

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

У меня была задача с новым функционалом. Я разработала тест-кейс и пошла к аналитику — уточнить корректность сценария. Аналитик сказал, что сценарий невозможен.

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

Почему полезно делиться опытом

Даже внутри команды важно поддерживать открытость и готовность помогать друг другу. В моей команде это чувствуется: если не уверена, как проверить сценарий или где найти нужную информацию — всегда могу обратиться к коллегам.

И сама стараюсь делать то же самое: делиться тем, что знаю, помогать, если кто‑то только погружается в проект. Команда работает лучше, когда в ней не боятся спросить и не жадничают знаниями.

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

→ Подробнее своим опытом Диана поделилась в статье.

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

• «Думай медленно… Решай быстро», Даниэль Канеман

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

• «Предсказуемая иррациональность», Дэн Ариели

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

• «Высоконагруженные приложения», Мартин Клеппман

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

• «Гибкое сознание», Кэрол Дуэк

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

• «Ментальные ловушки», Андре Кукла

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

• «Профессиональная разработка программного обеспечения», Стив Макконнелл

Книга о системности, ответственности и качестве в разработке. Макконнелл объясняет, что делает разработчика профессионалом: от планирования и коммуникации до оценки рисков и качества.

• «Верховный алгоритм», Педро Домингос

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

• «Искусство тестирования программ», Гленфорд Майерс

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

• «Жалоба — это подарок», Джанелл Барлоу, Клаус Мёллер

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

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

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

Что происходит с профессией?

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

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

Почему ИИ — главный тренд?

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

Какие навыки важны?

Чтобы быть полезным тестировщиком, важно развивать как технические, так и гибкие навыки:

• Внимательность, критическое и системное мышление — чтобы видеть не только конкретную ошибку, но и ее влияние на продукт в целом.

• Английский язык — чтобы читать логи, понимать настройки.

• Информационная безопасность — чтобы понимать принципы защиты данных, шифрования и как избежать утечек.

Что еще необходимо?

• REST, HTTP, Linux, Docker — это основа, особенно если вы работаете с DevOps‑задачами. Чтобы глубже тестировать инфраструктурные задачи, полезно пройти курсы и прокачать навыки.

• Работа в команде и инициативность — в любой задаче важно уметь взаимодействовать с разными ролями: аналитиками, разработчиками, другими тестировщиками. Тестировщик не просто проверяет — он помогает команде находить и устранять слабые места.

Как развиваться тестировщику?

• Развитие через практику и обмен опытом

Новые подходы можно черпать на конференциях, например, Heisenbug, SQA Days. Дополнительное развитие — брать задачи не только по тестированию, но и по улучшению процессов, участвовать в аналитике, работать над задачами смежного продукта, тестировать мобильное приложение. Наставничество также помогает расти — учишься вместе с теми, кого поддерживаешь.

• Развитие через ИТ-сообщество и техбазу

Начинающим тестировщикам будут полезны материалы Артёма Русова. У него есть сайт и тг-каналы: @qachanell, @qa_sklad.

Развиваться помогают и внутренние ресурсы в компании: коллеги делятся опытом, обсуждают кейсы, рассказывают, как решают задачи. Если у вас в компании есть что‑то подобное — не упускайте. Это классный способ расти и смотреть на профессию шире.

Полезные книги:

1. «Тестирование DOT COM», Роман Савин

2. «Тестирование ПО», Святослав Куликов

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

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

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

Чем занимается наша команда

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

В команде 9 человек, почти все работают удаленно и живут в разных городах. Мы разделены на две группы по продуктам: Low Code и NoCode.

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

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

В чем была главная сложность

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

В такой системе:

• невозможно оценить загрузку;

• нельзя планировать ресурс;

• нет общей картины, кто чем занят.

Мне, как руководителю, это мешало выстраивать базовое управление. Без прозрачности все превращается в хаос. Мы решили, что пора менять подход.

Как мы выстроили систему

В 2022 году мы внедрили следующие изменения:

• собрали таск-трекер на базе нашей платформы Naumen SMP;

• сделали Telegram-бота и перевели всю коммуникацию с менеджерами туда.

Теперь процесс выглядит так:

1. Менеджер оставляет запрос в боте.

2. Тимлид ведет коммуникацию и ставит задачу на одного из сотрудников.

3. Сотрудник берет задачу в работу, оформляет результат, закрывает.

Мы ушли от личных сообщений и получили понятную нагрузку, удобный контроль и прогресс. Работать стало спокойнее.

Как поддерживаем связь внутри команды

Удаленной команде без постоянного взаимодействия довольно сложно работать. Поэтому у нас есть несколько форматов:

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

Дэйли внутри каждой группы — тимлид уточняет загрузку, корректирует задачи, если нужно.

Один-на-один со мной — каждый месяц встречаюсь с сотрудниками: обсуждаем годовые цели и путь к ним.

Есть еще «Флеймтайм» — раз в месяц любой может поделиться тем, что его особенно выбило из колеи. Это помогает выговориться и не держать напряжение внутри. Команда слушает и поддерживает.

Что важно в распределенной команде

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

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

Когда такие люди собираются в одной команде — неважно, где они территориально. Все и так работает.

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

Ира, продуктовый аналитик в группе AI-решений, рассказывает, как она организует эту работу на практике: от подготовки задач и взаимодействия с разработкой до поиска решений.

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

Что я собираю перед тем, как задача уходит в разработку

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

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

Как определяются приоритеты

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

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

Какие артефакты ускоряют реализацию

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

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

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

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

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

Что помогает выстраивать эффективную работу с разработкой

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

А еще мы регулярно проводим мозговые штурмы и обсуждаем логику функционала до реализации. Часто для объяснения рисуем схемы: они помогают быстрее находить общую логику.

Как я сокращаю количество уточнений и переделок

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

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

Инструменты, которые помогают работать быстрее

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

Сложные и объемные разработки фиксируем в Confluence — это наш ориентир, который помогает видеть всю работу по этапам и не терять контекст по крупным задачам.

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

В будущем планируем сделать ориентир на роадмап.

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

Pairwise online tool — инструмент для генерации парных комбинаций проверок

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

В чем польза:

• сокращает количество проверок без потери покрытия;

• учитывает логические условия и исключает невозможные сочетания;

• упрощает тестирование форм, статусов и сложных конфигураций;

• ускоряет подготовку кейсов, в том числе для группы автоматизации.

Катя: Использую Pairwise, когда нужно быстро собрать оптимальный набор проверок. Но важно учитывать ограничения: если дефект зависит от 3–4 условий, техника может его пропустить, а найденный баг сложнее локализовать — непонятно, какой параметр повлиял на воспроизведение.

Visual Studio Code — удобный редактор для создания, чтения и редактирования файлов

VS Code помогает работать с файлами разных форматов, подсвечивает параметры, делает структуру данных читаемой и ускоряет поиск нужных параметров. Особенно выручает там, где обычный блокнот превращает файл в нечитаемый набор строк.

В чем польза:

• красиво раскрашивает код до читаемого, удобная навигация;

• позволяет делать поиск по нескольким файлам одновременно;

• подходит для анализа конфигураций и настроек системы;

• поддерживает расширения — все доступно в бесплатном магазине. 

Катя: Использую VS Code как легкий и удобный текстовый редактор — аналог Notepad++. Для разработчиков, мне кажется, он еще полезнее: напоминает полноценную IDE, только в более гибком формате.

Bug Magnet — расширение для Google Chrome с библиотекой тестовых данных

Bug Magnet подставляет в поля формы готовые тестовые значения: длинные строки, разные алфавиты, необычные символы, валидные и невалидные email‑адреса, числа, города и многое другое. 

В чем польза:

• ускоряет проверку форм и валидации;

• предлагает значения, которые сложно придумать вручную;

• поддерживает разные режимы ввода — вставка, симуляция ввода с клавиатуры;

• экономит время, когда нужно быстро пробежать по разным типам данных.

Арина: Bug Magnet выручает, когда нужно быстро заполнить форму разными граничными значениями. В один клик получаешь данные, которые вручную подбирать долго и неудобно.

Flaticon — библиотека бесплатных иконок для интерфейса

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

В чем польза:

• есть большое количество бесплатных иконок;

• предлагает варианты под светлую и темную тему;

• можно скачать в форматах PNG и SVG;

• упрощает выбор готовых размеров под Android, iOS и веб.

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

Burp Suite — инструмент для тестирования безопасности веб‑приложений

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

В чем польза:

• позволяет перехватывать и подменять запросы и ответы;

• помогает изучать авторизацию и поведение параметров;

• дает возможность автоматизировать переборы значений через Intruder;

• упрощает анализ и сравнение запросов с помощью Decoder и Comparer;

• визуализирует структуру сайта и все перехваченные запросы.

Арина: Burp Suite кажется сложным из-за количества модулей, но на практике все просто: перехват — подмена — отправка — анализ. Это удобный инструмент для проверки авторизации, поведения параметров и работы безопасности в целом.

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

1. Давать осмысленные имена сразу же

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

2. Декомпозировать код и избегать вложенности

if внутри if или for внутри for путают: каждое разветвление создает еще одну ветку, которую приходится держать в голове. Лучше разбить логику на небольшие части — код становится прозрачнее и надежнее.

как не надо:

функция заказать_пиццу(адрес):
  если адрес_валиден(адрес):
    если у_ресторана_ингредиенты():
      если клиент_может_платить():
        печать "Пицца заказана!"
      иначе:
        печать "Недостаточно денег"
    иначе:
      печать "Нет ингредиентов"
  иначе:
    печать "Адрес некорректный"

как надо:

функция заказать_пиццу(адрес):
  если не адрес_валиден(адрес):
    печать "Адрес некорректный"
    вернуть
  
  если не у_ресторана_ингредиенты():
    печать "Нет ингредиентов"
    вернуть
  
  если не клиент_может_платить():
    печать "Недостаточно денег"
    вернуть
  
  печать "Пицца заказана!"

3. Регулярно делать рефакторинг

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

4. Настроить линтер и форматер

Линтер — статический анализатор кода, который следит за определенным стилем написания кода. Так как у каждого из нас свой подход, нам нужен «инструмент-судья», который беспристрастно оценит оформление кода. Форматер помогает автоматически исправить код и привести его к единому виду. 

5. Комментировать только неочевидную бизнес-логику

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

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

Мы поговорили с коллегами о том, какие навыки и подходы помогают им двигать продукты вперед и принимать сильные решения. Делимся их мыслями с вами.

Что важно для продакта?

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

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

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

Какие скиллы нужны?

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

2. Адаптивность — умение быстро подстраиваться под изменения. Порой продукту нужно меняться на ходу, если запланированная функциональность становится неактуальной. 

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

4. Любопытство и интерес — это основа генерации идей и внедрения инноваций. Важно не бояться задавать вопросы, например, «А что если?» и тестировать гипотезы.

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

Как развиваться продакту?

Продакту важно уметь говорить понятно — не нужно усложнять формулировки и смыслы. Например, помогают курсы по аргументации и выстраиванию речи — выражать свои мысли становится проще. 

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

Что почитать:

• Пиши, сокращай 2025: Как создавать сильный текст / Ильяхов М., Сарычева Л.

• Спроси маму: Как общаться с клиентами и подтверждать правильность идей, когда все вокруг врут / Фитцпатрик Р.

• Telegram-каналы с полезным контентом о продуктовой разработке и бизнес-трендах: Epic Growth, RB.RU, Product Management & AI, Продакты не нужны, Заметочки b2b продакта, Губкин | Про AI и B2B-продукты, Strategic move: стратегия, продукт и AI, Продуктовое мышление / от ProductSense и Клиентский опыт и качество.

Тестирование требований — это не про поиск багов в коде. Это процесс проверки того, насколько сами требования корректны, полны и понятны.

Зачем это вообще нужно?

Ошибки в требованиях → баги в реализации → потери времени и денег.

Тестирование требований позволяет:

• Выявлять дефекты до этапа кодинга

• Экономить время команды

• Делать ожидания всех сторон прозрачными

• Повышать качество продукта без доработок «в последний момент»

Как понять, что требование хорошо сформулировано:

Какие техники тестирования требований использовать?

Взаимный просмотр
Показываем свою работу коллегам

Вопросы
Уточняем у заказчиков и коллег

Тест-кейсы и чек-листы
Прорабатываем набор вопросов для проверки требований

Рисунки
Наглядно представляем приложение

Прототипирование
Делаем наброски интерфейса и переходов между экранными формами

Исследование поведения системы
Мысленно моделируем работу пользователя с системой

Как проверить количество и атомарность?

1. Делаем блок-схему, чтобы увидеть дубли и лишние шаги

2. Проверяем, что требование описывает Create / Read / Update / Delete / List

3. При помощи сценария использования проверяем, что требование покрывает весь путь пользователя

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

5. Ищем отсылки на неопределенную информацию — если есть «и т.д.», «как обычно», стоит уточнить

6. Проверяем на союз «и» — часто он объединяет в одном требовании сразу два, а иногда и больше

Как проверить выполнимость и однозначность?

Хорошее требование не вызывает споров — его можно понять одинаково, реализовать и проверить результат.

Что важно:

• Терминология

• Отсутствие качественных определений

• Простое изложение

• Возможность составить набор тестов

• Тестирование внешних сервисов

Как проверить актуальность и последовательность?

Если требование забыли, потеряли или поняли не так — беда в процессе.

На что обращаем внимание:

• Одно требование описано в одном месте

• Есть user story или хотя бы сценарий использования

• У автора требований есть знание предметной области

• Учтены интересы всех пользователей

• Договоренности из чатов перенесены в документацию

• Согласована дата последнего обновления требований и документации

Хорошие требования — это результат не только опыта, но и осознанной практики.