Про достижения и success amnesia

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

1. Регулярное ведение списка задач:

• Создайте файл/документ/таблицу: Выберите удобный для вас формат (Google Docs, Word, Excel, Notion, Trello, Obsidian, Evernote). У меня это бумажный блокнот.
• Регулярно добавляйте записи: Старайтесь делать записи как можно чаще (ежедневно, еженедельно или хотя бы раз в месяц). Чем свежее воспоминания, тем больше деталей вы сможете зафиксировать.
• Описывайте конкретные ситуации: Не просто "успешно завершил проект", а "Успешно завершил проект X, несмотря на нехватку ресурсов, внедрив Y, что позволило сэкономить Z времени и денег".
• Указывайте результаты: Описывайте не только действия, но и результаты, которых удалось достичь (например, "увеличил тестовое покрытие на 20%", "сократил количество дефектов на 15%").
• Не забывайте о мелочах: Записывайте не только крупные достижения, но и небольшие успехи, которые вы совершаете ежедневно (например, "помог коллеге разобраться с проблемой", "предложил улучшение процесса"). Вот это вообще мой любимый ключевой пункт - записывайте даже мелочи!

2. Использование системы управления задачами:

• Записывайте результаты выполнения задач: В Jira, Trello, Asana или других системах управления задачами добавляйте комментарии, описывающие, как вы выполнили задачу и какие результаты достигли. Кстати, очень удобно делать свой личный проект в рабочей TMS
• Прикрепляйте ссылки на выполненные работы: Добавляйте ссылки на код, тестовые сценарии, отчеты и другие материалы, связанные с задачей.
• Используйте теги и метки: Используйте теги и метки для классификации задач по типам, проектам, навыкам и другим критериям.
• Просматривайте историю задач: Регулярно просматривайте историю задач, чтобы вспомнить свои достижения и оценить прогресс.


3. Использование метода "Звезда" (STAR) для описания ситуаций:

• S (Situation): Опишите ситуацию, в которой вы оказались.
• T (Task): Опишите задачу, которую вам нужно было решить.
• A (Action): Опишите действия, которые вы предприняли для решения задачи.
• R (Result): Опишите результат, которого вы достигли.


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

Триумфальное возвращение (возможно!)

Надеюсь, вы тут без меня грустили! Пропала я не просто так - в Яндексе у меня были значительные (и замечательные!) карьерные изменения, и теперь я операционный руководитель не AI-тренеров, а ... Тестировщиков!
Да, попытка выйти из айти продолжает проваливаться, с другой стороны - за последние 3-4 месяца у меня ого-го сколько мыслей накопилось и про тестирование, и про менеджмент, и про технологии. И про конференции, кстати, тоже. И к консультированию я вернулась в полной мере. В общем, я - снова я!

А раз уж такое дело - то сегодня про AI.
1. Побывала на конфе ProductCamp и порадовалась, что все больше докладчиков говорят не только про сахарные горы и горы бабла при внедрении ИИ решений, но и про то, как делать не надо, и когда такие решени вообще не нужны. Да, они нужны не всегда! Особенно понравился доклад «Недовнедрение: почему буксуют ИИ-инициативы» с Дмитрием Твердохлебовым, очень жду, когда появится в сети, обязательно прикреплю ссылку.

2. Наша команда (передаю пламенный привет!) делает одно очень крутое ИИ решение для тестирования, и чем больше я в этот проект погружаюсь, тем больше проникаюсь тем, насколько сложно сделать что-то действительно крутое, нужное и работающее, а не очередной хайповый, но бесполезный продукт. А еще все больше меня бесят те, кто пишут что "ой а че там, обучить иишку это дел на пару часов, они уже все и так умеют!"

Про безопасность и QA

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

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

1. Некорректный ввод данных:
Пустые поля: Попробуйте оставить логин, пароль, email пустыми. Должны быть внятные сообщения об ошибках.
Неправильный формат: Введите email без символа @, пароль, не соответствующий требованиям (слишком короткий, без цифр/спецсимволов), или логин с запрещенными символами. Система должна корректно отказать в регистрации.
Очень длинные данные: Введите очень длинную строку (сотни, тысячи символов) в поля логина, имени, email. Система не должна "упасть" или зависнуть.
Специальные символы: Введите в поля регистрации символы типа ' " < > %. Убедитесь, что они корректно обрабатываются (экранируются) при сохранении и отображении, а не ломают страницу или код.

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

3. Ограничения и защиты:
Слабые пароли: Попробуйте создать аккаунт с очень простым паролем (например, 123456, password). Система должна его отклонить или предупредить. Если нет - прекрасный повод обсудить это с коллегами.
Множественные попытки: Попробуйте быстро зарегистрировать несколько аккаунтов подряд. Появляется ли CAPTCHA или другое ограничение для предотвращения автоматической регистрации ботами?

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

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

Про фактчекинг и подборки

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


- В тг сейчас можно найти много подборок, в том числе и про тестирование, но одна моя любимая (и не только потому что в ней есть я 🫠), а потому что раз в период сообщество авторов каналов голосует за каждый из них, его ценность и полезность, убирая рекламные, сомнительные и недостоверные.
- В сети появился плейлист SQA Days 36: очень жалею, что не попала, но доверяю серьезному походу ПК в отборе докладов и уже приметила довольно много полезного.
- В профсообществах все больше паники/отрицания работы с ИИ в любой форме, а тем временем это отличный инструмент для упрощения многих рабочих задач. У меня, конечно, запланированы посты на эту тему, а пока - хорошая статья.
- Мы тут в отпуске с подругой довольно много говорили о том, что значит быть хорошим руководителем - и как раз на днях мне попался вот этот пост, который мне очень близок
- Ну и последнее на сегодня - продолжаем искать начинающего автоматизатора ко мне в крауд! Можно с меньшим опытом, чем указано в вакансии, самое важное - чтобы был опыт в программировании и написании автотестов и понимание того, как и зачем их пишут.

Снобизм - убийца профессионализма

Пост - крик души. Как же бесит ИТ-снобизм, сил нет!

Я в ИТ уже неприличное количество лет, и меня вот прямо с первого дня кипятит подход «да я уже 10 лет работаю, не надо меня учить, эта молодежь пороху не нюхала, не страдала, поэтому я им покажу дедовщину». Нет, чуваки, стаж не делает вас мудрыми и крутыми профи по умолчанию. Знаю джунов, до которым многим далеко, как и знаю коллег тестировщиков веба с опытом 15 лет, которые не знают про DevTools.
Особая категория - те, кто презирают джунов/аутсорс/аутстафф/асессоров и считают, что это люди второго сорта. ОСОБЕННО если так делают лиды. No comments
Вишенка на торте этого поста - снобизм в отношении смежников. Как в коммуникации, так и в игнорировании даже попыток узнать, а чего там делают твои коллеги. Никого не призываю поголовно становиться t-shaped специалистами, но хотя бы базово поинтересоваться стоит, это полезно для всей команды.

На сегодня - хватит, но у меня еще есть что сказать по этой теме!

Лонгрид о преподавании

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

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

- Курс для джунов - потрясающий способ каждый год, постоянно, обновлять «базу». Новые подходы, технологи, идеи - все идет в дело. А еще важно знать, что делаешь вклад в светлое будущее ИТ: обожаю встречать своих бывших студентов в рабочей жизни, особенно уже на лидских позициях
- С университетскими студентами своя прелесть - это хороший способ себя почелленджить, как вопросами от молодых первокурсников, которые рвутся в бой, так и от опытных специалистов, которые решили получить вышку. А вопросы и правда часто ого-го какие!
- Особая история - преподавание на курсах для смежных специалистов, например, для рекрутеров, потому что это способ показать индустрию с другой точки зрения тем, кому она интересна.
- Вообще это и прекрасный способ нетворкинга. Хотя знаете - да фиг с ним с нетворкингом, я столько друзей нашла! *машет рукой нынешним и бывшим коллегам*
- Это отличный способ прокачаться в ораторском мастерстве - чтобы не просто бубубу на работе делать, а вот прямо четко и внятно доносить свою мысль. Тут конечно сноска, что лучше сначала этому базово научиться и не мучить студентов кашей во рту, но вот совершенствоваться можно, по моему мнению. Мне вот точно есть еще, куда расти!

Есть ли еще плюсы - есть!
Есть ли минусы - ох, конечно тоже есть! Преподавание работа не слабонервных, но про это - уже другим постом, а я удаляюсь расссказывать студентам Вышки про то, зачем и как изучать математику в университете 🚀

От Марса до Суэца: Почему провалы — лучшие учителя в IT (и не только)

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

Вспомним несколько хрестоматийных примеров:

- Марсианский климатический орбитальный аппарат (Mars Climate Orbiter, 1999): Классика жанра. Потеря спутника стоимостью $125 миллионов из-за простой ошибки в единицах измерения – одна команда использовала английские фунты силы, другая – метрические ньютоны. Урок: требования и их интерпретация должны быть абсолютно однозначными и тщательно проверенными. Где был тестировщик, который бы спросил: "А в чем измеряем?"
- Therac-25 (1985-1987): Один из самых трагичных примеров. Дефект ПО в медицинском аппарате лучевой терапии привел к смертельным передозировкам радиации. Проблема была в гонках условий (race condition), которые не были выявлены при тестировании. Урок: тестирование безопасности и устойчивости к некорректным последовательностям действий пользователя – не прихоть, а необходимость.
- Boeing 737 MAX (2018-2019): Хотя это и авиация, но в основе катастроф лежал сложный, скрытый баг в системе MCAS, неправильно спроектированной и недостаточно протестированной. Система, призванная повысить безопасность, при определенных условиях приводила к потере управления. Урок: недостаточное тестирование сложных алгоритмов, особенно тех, что взаимодействуют с реальным миром и человеческой жизнью, имеет катастрофические последствия.

И провалы случаются не только в софте, но часто с его участием или по схожим причинам:

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

Что общего у всех этих провалов?

- Недооценка сложности: Чем сложнее система, тем больше точек отказа.
- Недостаточное тестирование: Особенно граничных условий, неочевидных сценариев, интеграций и отказоустойчивости.
- Плохая коммуникация и управление требованиями: Недопонимание между командами, отсутствие четких спецификаций.
- Давление сроков: "Сделаем быстрее, а потом поправим" – иногда "потом" не наступает.
- Игнорирование мелких предупреждений: Часто большие провалы начинаются с серии маленьких, незамеченных или проигнорированных проблем.

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

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