Всем привет! Меня зовут Мария Макарова, я являюсь системным аналитиком в Мир Plat.Form. В ИТ я почти 10 лет, а непосредственно в аналитике сравнительно недавно.

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

Сначала немного предыстории

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

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

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

Как и многие руководители проектов, я мечтаю об инструменте, который бы позволял мне легко и непринуждённо планировать проектные работы на горизонте всего проекта, а также на месяц и на неделю, мониторить выполнение работ, управлять ресурсами, сроками, пользоваться удобными дашбордами, быстро формировать отчёты для руководства (а не рисовать картинки в Share Point) и т.д. Мечты, мечты… В большинстве проектов мне был доступен MS Project и MS Excel. Ну хотя бы так.

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

В своих проектах я часто использую два плана-графика: верхнеуровневый (для проектов длительностью до шести месяцев среднеуровневый) и детальный на ближайшую неделю. Почему два? На мой взгляд, детальный план-график проект на всю его длительность делать сложно, а зачастую и вредно. Слишком много неопределённости на старте проекта и много чего меняется в его ходе. И если у вас нет команды планировщиков (а в ИТ я их не встречал), то всё нужно будет делать самому, и постоянная актуализация детального плана-графика «съест» всё время руководителя проекта. Поэтому такие расписания лучше делать верхнеуровневыми до конца проекта и среднеуровневыми на ближайшие два месяца, с длительностью задачи на нижнем уровне иерархии не менее 5 рабочих дней.

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

Рассмотрим такие планы-графики на моём любимом кейсе – проекте «засунуть слона в холодильник». Могу, конечно, ошибаться, но на простых и весёлых примерах всегда проще и интереснее объяснять методику.

Когда я только начинала работать тестировщиком, снифферы трафика казались мне чем-то далеким. В голове было что-то типа: "Ну, это для тестировщиков мобилок и для разработчиков. Мне оно не надо". Но потом я постепенно начала их использовать и поняла, что сниффер это маст хэв вещь в некоторых случаях!

В этой статье расскажу о нескольких кейсах, где снифферы трафика могут реально сохранить кучу времени и некоторое количество нервов. Let's go!

Decision Table (таблица решений) — техника, помогающая наглядно изобразить комбинатору условий из ТЗ.

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

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

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

Язык программирования Scratch — это относительно молодой язык, который появился в 2007 году как способ обучения детей кодингу. Он прост, интерактивен и доступен для ребят, так как в нем не нужно писать строчки кода, составлять скрипты с тегами и классами, подключать внешние библиотеки. Scratch сравним с детской компьютерной игрой: у вас есть сцена, на которой происходит действие с персонажами. Они могут прыгать, бегать, кидать мяч, гонять на машинках и выполнять любые другие действия. Чтобы создать в Скретч программу, нужно построить её из специальных «кирпичиков» — цветных блоков-операторов. Так, при помощи синих блоков мы перемещаем объект на поле, зеленым блоком проводим все математические действия и настраиваем логику, красным задаем значения переменных и так далее.

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

Михаил Абрамов, технический писатель платформы МТС Exolve, подготовил для начинающих специалистов чек-листы с основными правилами и процедурами тестирования.

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

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

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

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

Хотите, чтобы ваш ребенок научился кодить? Тогда эта подборка платных и бесплатных уроков Minecraft программирования для вас.

Если вы не знаете, что такое don’t keep activities, и не понимаете, что может произойти с приложением, когда вы его сворачиваете или когда меняете тему системы на тёмную, то можете считать, что ваше приложение не протестировано!

Что происходит под капотом вашего android приложения, зачем это знать тестировщику, какие критические сценарии можно и нужно проверять основываясь на жизненном цикле activity, и как это убережёт вас от краша на проде.

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

В самом начале июля мы выкатили статистику публикаций для всех авторов Хабра: теперь каждый может не только оценивать рейтинг и просмотры, но и видеть, как именно его статью читают, в какой момент уходят и сколько пользователей решают покинуть страницу почти сразу. Это классная опорная статистика, которая позволяет понять, что нравится аудитории и исходя из этого скорректировать подачу контента. Июль закончился, статистика поднакопилась, мы решили попробовать собрать компоненты успешной статьи и разобраться, как же написать «ту самую» звёздную статью. А заодно посмотреть, что и как писали лучшие авторы месяца.

"Не вредные советы для Лидера Проекта". Часть 1. Как подготовиться к встрече с Волан-де-Мортом и защититься от Дементоров в проекте.

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

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

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

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

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

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