Storybook
(ссылка в конце)
Мы выяснили, что дизайн-система — это часть инфраструктуры проекта, как дизайн-макеты и кодовая база. А значит, было бы неплохо иметь инструмент, который позволяет удобно c ней взаимодействовать: разрабатывать, хранить, документировать и пользоваться.
⚙️ Знакомьтесь, это Storybook. Он позволяет делать все то, что я перечислила выше. Его используют Airbnb, Microsoft, Audi, JetBrains, Atlassian и еще много-много компаний. Он дружит с React, Vue, Angular, Svelte и даже Vanilla JS. Подключить его в проект очень просто, а пользоваться реально удобно.
Для каждого компонента, блока или целой страницы создается история — файл с расширением .stories.js (ts, mdx), который и отвечает за отображение вашего элемента. Storybook собирает все эти файлы и формирует библиотеку компонентов. Он разворачивает в браузере интерактивный интерфейс, где можно посмотреть каждый элемент библиотеки изолированно: как он выглядит, как работает, какие у него состояния и пропсы. И да, со всем этим можно взаимодействовать.
⚗️ Я не буду описывать, как подключить Storybook, потому что у него отличная дока и много понятных демок — они расскажут гораздо лучше. Если коротко: скачали npm пакет, запустили из консоли — все. Дальше все зависит от того, насколько хорошо вы опишете компонент. Придерживайтесь правила: одна история — один компонент со всеми его состояниями.
Storybook можно использовать внутри проекта или вынести в отдельный. Если вы только начинаете знакомство с ним, лучше оставьте внутри. Отдельным проектом можно, например, поделиться или собрать из него npm пакет и опубликовать.
Я думаю, вы уже поняли, что Storybook — крутая штука. Так что я предлагаю не медлить, а пойти и установить! Потыкайте и посмотрите, как он работает: не оторваться! Вот вам ссылка https://storybook.js.org/ и увлекательное занятие на выходные. 😜
#rdclr_frontend #product
(ссылка в конце)
Мы выяснили, что дизайн-система — это часть инфраструктуры проекта, как дизайн-макеты и кодовая база. А значит, было бы неплохо иметь инструмент, который позволяет удобно c ней взаимодействовать: разрабатывать, хранить, документировать и пользоваться.
⚙️ Знакомьтесь, это Storybook. Он позволяет делать все то, что я перечислила выше. Его используют Airbnb, Microsoft, Audi, JetBrains, Atlassian и еще много-много компаний. Он дружит с React, Vue, Angular, Svelte и даже Vanilla JS. Подключить его в проект очень просто, а пользоваться реально удобно.
Для каждого компонента, блока или целой страницы создается история — файл с расширением .stories.js (ts, mdx), который и отвечает за отображение вашего элемента. Storybook собирает все эти файлы и формирует библиотеку компонентов. Он разворачивает в браузере интерактивный интерфейс, где можно посмотреть каждый элемент библиотеки изолированно: как он выглядит, как работает, какие у него состояния и пропсы. И да, со всем этим можно взаимодействовать.
⚗️ Я не буду описывать, как подключить Storybook, потому что у него отличная дока и много понятных демок — они расскажут гораздо лучше. Если коротко: скачали npm пакет, запустили из консоли — все. Дальше все зависит от того, насколько хорошо вы опишете компонент. Придерживайтесь правила: одна история — один компонент со всеми его состояниями.
Storybook можно использовать внутри проекта или вынести в отдельный. Если вы только начинаете знакомство с ним, лучше оставьте внутри. Отдельным проектом можно, например, поделиться или собрать из него npm пакет и опубликовать.
Я думаю, вы уже поняли, что Storybook — крутая штука. Так что я предлагаю не медлить, а пойти и установить! Потыкайте и посмотрите, как он работает: не оторваться! Вот вам ссылка https://storybook.js.org/ и увлекательное занятие на выходные. 😜
#rdclr_frontend #product
Storybook
Storybook: Frontend workshop for UI development
Storybook is a frontend workshop for building UI components and pages in isolation. Thousands of teams use it for UI development, testing, and documentation. It's open source and free.
👍7
🥢 Пока ждем понедельника и нового разработчика на дежурстве — собрали для людей высокой культуры тайтлы, связанные с цифровыми штуками.
Для компутерщиков про компутерщиков, так сказать. Так что, если не знали, что посмотреть в выходные — теперь знаете. «SAO» мы сюда включать не стали!
— «BPS» или «Battle Programmer Shirase» — анимешка старая и больше для тех, кто с компьютером на «вы», но дух программирования передан неплохо.
— «Калигула» — действие происходит в месте под названием Мёбиус, где вы будете свободны от ужасов реальности, а любое желание будет исполнено. Управляет пространством виртуальный идол Мю, каким-то образом обретший сознание сознание. Она поет и заманивает людей в цифровой рай. Оттуда — нет выхода в реальность, там — нет понятия возраста и пола, ведь все равны.
— «Виртуальный спецназ» — пятеро опытных хакеров решают решают провернуть последнее совместное дело и разбежаться, однако все идет наперекосяк.
— «Нет игры — нет жизни» — История фокусируется на Соре и Сиро, брате и сестре, репутация которых как безупречных NEET, хикикомори и игроманов породила легенды по всему интернету. Вся их жизнь — очередная «отстойная игра».
Дополняйте список чем-нибудь, что считаете качественным.
Для компутерщиков про компутерщиков, так сказать. Так что, если не знали, что посмотреть в выходные — теперь знаете. «SAO» мы сюда включать не стали!
— «BPS» или «Battle Programmer Shirase» — анимешка старая и больше для тех, кто с компьютером на «вы», но дух программирования передан неплохо.
— «Калигула» — действие происходит в месте под названием Мёбиус, где вы будете свободны от ужасов реальности, а любое желание будет исполнено. Управляет пространством виртуальный идол Мю, каким-то образом обретший сознание сознание. Она поет и заманивает людей в цифровой рай. Оттуда — нет выхода в реальность, там — нет понятия возраста и пола, ведь все равны.
— «Виртуальный спецназ» — пятеро опытных хакеров решают решают провернуть последнее совместное дело и разбежаться, однако все идет наперекосяк.
— «Нет игры — нет жизни» — История фокусируется на Соре и Сиро, брате и сестре, репутация которых как безупречных NEET, хикикомори и игроманов породила легенды по всему интернету. Вся их жизнь — очередная «отстойная игра».
Дополняйте список чем-нибудь, что считаете качественным.
👍3
📌 Эвристики и мнемоники в тестировании: что это и как применять — первая тема
С самого детства все мы запоминали цвета радуги с помощью фразы «Каждый охотник желает знать, где сидит фазан». Как оказалось, это самая известная нам мнемоника. В тестировании они также применяются. Так что это такое: эвристика и мнемоника?
Простыми словами, мнемоника — полезный инструмент, который помогает запомнить различные схемы разнообразных моделей тестирования, которые в будущем можно использовать на практике. А эвристика — специальный алгоритм, помогающий эффективно ориентироваться в пространстве при решении какой-то определенной задачи. Существует разнообразное количество инструментов и технологий мнемоники, которые помогают не упустить важные моменты при тестировании. Рассмотрим некоторые.
SFDPOT (Structures, Functions, Data, Platforms, Operations, Time):
✌🏻 Structure — структура приложения, проверка составляющих его частей. На данном этапе разрабатываются тестовые идеи и сценарии, связанные со структурой приложения.
🖖🏻 Function — функциональность приложения, проверка того, что приложение делает. На этом этапе разрабатывается функциональное тестирование программного продукта.
🤜🏻 Data — работа с данными; проверка того, как приложение работает с данными. Тестировщики должны узнать, с какими данными работает система, и разработать тесты, проверяющие, как система получает, обрабатывает и выдает различные виды данных.
🤘🏻 Platform — платформа; проверка того, как приложение взаимодействует с платформой, на которой запущено. Тестировщики должны определить, на каких платформах выполнять ручное и автоматизированное тестирование.
👌🏻 Operations — использование, проверка сценариев использования приложения. В этом пункте тестировщики должны выяснить, кто конечные пользователи тестируемого программного продукта, для каких задач пользователи собираются его использовать.
🤏🏻 Time — время, проверка того, как приложение ведет себя в зависимости от времени.
Самая известная мнемоника для тестирования мобильных приложений — I SLICED UP FUN.
🕴🏻 Inputs — входные данные (вводимые с клавиатуры или набираемые пальцем).
👨🏼🦽 Store — Хранилище. Android Market, например.
🧍🏾♂️ Location — Расположение (ошибки гео-координат, движение, быстрая остановка).
🧑🏻🦯 Interactions/Interruptions — взаимодействие / прерывания. Сворачивание приложение, когда играет музыка, например.
🏃🏻 Communications — входящий звонок, смс, уведомление.
👬 Ergonomics — мелкие детали напрягают глаза, ищите такие проблемы.
🧍🏿♀️ Data — Данные. Все, что приложение обрабатывает.
🕺 Usability — удобство использования.
🧑🏽🦼 Platform — для каких платформ выпущено ПО, где будет работать.
🧎🏻♀️ Function — Функционал.
👯♀️ User Scenarioes — пользовательские сценарии.
🤳🏻 Network — сеть.
RCRCRC — эвристика, применяемая для регрессионного тестирования.
👕 Recent — какие новые функции были добавлены в текущей итерации, что было изменено из уже существующего функционала.
🩱 Core — основные сценарии. Что должно всегда работать.
🥼 Risk — какой функционал имеет максимальные риски — его и проверяем.
👘 Configuration — на каких окружениях и в каких конфигурация должно работать.
👞 Repaired — какой функционал мы чинили в релизе. Ретест багов, как минимум самых важных.
🧣 Chronic — регрессия областей с хроническими болезнями (где чаще всего находились баги ранее).
Лично вам чужая мнемоника может подойти, а может и нет. Она может не подойти под вашу систему или под ваши процессы. Вы всегда можете написать свою мнемонику, которая будет под вас, под вашу команду, особенности вашего продукта и процессы.
#rdclr_QA
📎 В первой статье (VPN) вы прочитаете более подробно о преимуществах и недостатках тестовых эвристик, об «оракуле» — дополнительном эвристическом механизме.
Во второй — расшифровку самых известных мнемоник и эвристик и их описание.
С самого детства все мы запоминали цвета радуги с помощью фразы «Каждый охотник желает знать, где сидит фазан». Как оказалось, это самая известная нам мнемоника. В тестировании они также применяются. Так что это такое: эвристика и мнемоника?
Простыми словами, мнемоника — полезный инструмент, который помогает запомнить различные схемы разнообразных моделей тестирования, которые в будущем можно использовать на практике. А эвристика — специальный алгоритм, помогающий эффективно ориентироваться в пространстве при решении какой-то определенной задачи. Существует разнообразное количество инструментов и технологий мнемоники, которые помогают не упустить важные моменты при тестировании. Рассмотрим некоторые.
SFDPOT (Structures, Functions, Data, Platforms, Operations, Time):
✌🏻 Structure — структура приложения, проверка составляющих его частей. На данном этапе разрабатываются тестовые идеи и сценарии, связанные со структурой приложения.
🖖🏻 Function — функциональность приложения, проверка того, что приложение делает. На этом этапе разрабатывается функциональное тестирование программного продукта.
🤜🏻 Data — работа с данными; проверка того, как приложение работает с данными. Тестировщики должны узнать, с какими данными работает система, и разработать тесты, проверяющие, как система получает, обрабатывает и выдает различные виды данных.
🤘🏻 Platform — платформа; проверка того, как приложение взаимодействует с платформой, на которой запущено. Тестировщики должны определить, на каких платформах выполнять ручное и автоматизированное тестирование.
👌🏻 Operations — использование, проверка сценариев использования приложения. В этом пункте тестировщики должны выяснить, кто конечные пользователи тестируемого программного продукта, для каких задач пользователи собираются его использовать.
🤏🏻 Time — время, проверка того, как приложение ведет себя в зависимости от времени.
Самая известная мнемоника для тестирования мобильных приложений — I SLICED UP FUN.
🕴🏻 Inputs — входные данные (вводимые с клавиатуры или набираемые пальцем).
👨🏼🦽 Store — Хранилище. Android Market, например.
🧍🏾♂️ Location — Расположение (ошибки гео-координат, движение, быстрая остановка).
🧑🏻🦯 Interactions/Interruptions — взаимодействие / прерывания. Сворачивание приложение, когда играет музыка, например.
🏃🏻 Communications — входящий звонок, смс, уведомление.
👬 Ergonomics — мелкие детали напрягают глаза, ищите такие проблемы.
🧍🏿♀️ Data — Данные. Все, что приложение обрабатывает.
🕺 Usability — удобство использования.
🧑🏽🦼 Platform — для каких платформ выпущено ПО, где будет работать.
🧎🏻♀️ Function — Функционал.
👯♀️ User Scenarioes — пользовательские сценарии.
🤳🏻 Network — сеть.
RCRCRC — эвристика, применяемая для регрессионного тестирования.
👕 Recent — какие новые функции были добавлены в текущей итерации, что было изменено из уже существующего функционала.
🩱 Core — основные сценарии. Что должно всегда работать.
🥼 Risk — какой функционал имеет максимальные риски — его и проверяем.
👘 Configuration — на каких окружениях и в каких конфигурация должно работать.
👞 Repaired — какой функционал мы чинили в релизе. Ретест багов, как минимум самых важных.
🧣 Chronic — регрессия областей с хроническими болезнями (где чаще всего находились баги ранее).
Лично вам чужая мнемоника может подойти, а может и нет. Она может не подойти под вашу систему или под ваши процессы. Вы всегда можете написать свою мнемонику, которая будет под вас, под вашу команду, особенности вашего продукта и процессы.
#rdclr_QA
📎 В первой статье (VPN) вы прочитаете более подробно о преимуществах и недостатках тестовых эвристик, об «оракуле» — дополнительном эвристическом механизме.
Во второй — расшифровку самых известных мнемоник и эвристик и их описание.
ДОУ
Эвристики и мнемоники в тестировании: что это и как применять
Антонина Тараненко, ISTQB Certified QA Engineer, рассказывает об основных тестовых эвристиках и мнемониках, зачем и для чего они применяются, в чем их преимущества и недостатки, и приводит примеры их практического применения.
🔥10👍1
Как писать хорошие тест-кейсы?
Тест-кейс — это детальное пошаговое описание проверки. Оно показывает определённый путь программы или сценарий проверки. От того, как хорошо написан тест-кейс будет зависеть насколько детально будет описан продукт и с каким успехом любой участник команды сможет протестировать его.
1️⃣ Один тест-кейс — одна проверка
Следи, чтобы в тест-кейсе был только один ожидаемый результат. Это поможет не запутаться — по крайней мере, пока ты учишься. Когда станешь опытнее, сможешь сочетать несколько проверок в одном тест-кейсе, но пока лучше следовать этому правилу.
2️⃣ Один тест-кейс — одни тестовые данные
Тестовые данные — данные, которые понадобятся тебе для тестирования. Например, ты проверяешь, что в поле можно ввести текст от 2 до 10 символов. Символы, которые ты вводишь в поле для проверки, — тестовые данные. В одном тест-кейсе используй одни тестовые данные. Например, если нужно протестировать поле с коротким и длинным именем, составь два разных тест-кейса.
3️⃣ Уникальный ID
ID тест-кейса не должен повторять другие. Если будет два одинаковых, команда запутается. Иногда ID для тест-кейсов задаёт система, в которой работает тестировщик. Если такого нет, следует уточнить у коллег какая система учет принята в команде.
4️⃣ Уникальный и полный заголовок
Хороший заголовок не повторяет заголовки других тест-кейсов, чтобы не запутаться. Он конкретный и отвечает на вопрос: «Что я проверяю?» или «Что? Где? Когда?».
5️⃣ Лаконичные и чёткие шаги
Когда описываешь шаги: не расписывай их чересчур подробно: включай в них только необходимую информацию: следи, чтобы каждый шаг отвечал на вопрос «Что нужно сделать?».
6️⃣ Если для проверки нужны особые настройки, укажи предусловие
Предусловие — всё, что нужно сделать до того, как приступать к основным шагам тест-кейса. Например, зайти в приложение под определённым логином или включить какие-то настройки.
7️⃣ Если после проверки нужно дополнительно проверить изменившиеся состояние, укажи постусловие
Постусловие — всё, что нужно сделать после того, как были выполнены основные шаги тест-кейса или вернуть систему в исходное состояние (выйти из профиля пользователя, удалить сохраненные данные).
8️⃣ Словарный запас
Избегай использование в тест-кейсе слов:
человек —> пользователь
есть —> находится, отображается
посмотреть —> проверить
как на макете —> согласно макету
Замени их на предложенные (—>)
И самое главное — соблюдай правила орфографии! 🌺
#rdclr_QA
Тест-кейс — это детальное пошаговое описание проверки. Оно показывает определённый путь программы или сценарий проверки. От того, как хорошо написан тест-кейс будет зависеть насколько детально будет описан продукт и с каким успехом любой участник команды сможет протестировать его.
1️⃣ Один тест-кейс — одна проверка
Следи, чтобы в тест-кейсе был только один ожидаемый результат. Это поможет не запутаться — по крайней мере, пока ты учишься. Когда станешь опытнее, сможешь сочетать несколько проверок в одном тест-кейсе, но пока лучше следовать этому правилу.
2️⃣ Один тест-кейс — одни тестовые данные
Тестовые данные — данные, которые понадобятся тебе для тестирования. Например, ты проверяешь, что в поле можно ввести текст от 2 до 10 символов. Символы, которые ты вводишь в поле для проверки, — тестовые данные. В одном тест-кейсе используй одни тестовые данные. Например, если нужно протестировать поле с коротким и длинным именем, составь два разных тест-кейса.
3️⃣ Уникальный ID
ID тест-кейса не должен повторять другие. Если будет два одинаковых, команда запутается. Иногда ID для тест-кейсов задаёт система, в которой работает тестировщик. Если такого нет, следует уточнить у коллег какая система учет принята в команде.
4️⃣ Уникальный и полный заголовок
Хороший заголовок не повторяет заголовки других тест-кейсов, чтобы не запутаться. Он конкретный и отвечает на вопрос: «Что я проверяю?» или «Что? Где? Когда?».
5️⃣ Лаконичные и чёткие шаги
Когда описываешь шаги: не расписывай их чересчур подробно: включай в них только необходимую информацию: следи, чтобы каждый шаг отвечал на вопрос «Что нужно сделать?».
6️⃣ Если для проверки нужны особые настройки, укажи предусловие
Предусловие — всё, что нужно сделать до того, как приступать к основным шагам тест-кейса. Например, зайти в приложение под определённым логином или включить какие-то настройки.
7️⃣ Если после проверки нужно дополнительно проверить изменившиеся состояние, укажи постусловие
Постусловие — всё, что нужно сделать после того, как были выполнены основные шаги тест-кейса или вернуть систему в исходное состояние (выйти из профиля пользователя, удалить сохраненные данные).
8️⃣ Словарный запас
Избегай использование в тест-кейсе слов:
человек —> пользователь
есть —> находится, отображается
посмотреть —> проверить
как на макете —> согласно макету
Замени их на предложенные (—>)
И самое главное — соблюдай правила орфографии! 🌺
#rdclr_QA
🔥5
Введение в тест-анализ #1: декомпозиция, визуализация, поиск серых зон
🍼 Тест-анализ (test analysis) — один из этапов тестирования, направленный на изучение требований и макетов. Когда будешь изучать, постарайся ответить на вопрос: что именно предстоит тестировать? Так ты составишь список объектов тестирования.
Объекты тестирования (test objects) — части приложения, которые нужно проверить. Например, компания сделала почтовый клиент — приложение, в котором можно обмениваться электронными письмами. В последнем обновлении разработчики добавили фичу: теперь приложение определяет спам и сохраняет его в отдельной папке.
Попробуй определить, что именно предстоит протестировать? Тестировщик будет проверять не всё приложение целиком, а определённую функциональность — работу со спамом. Но сначала нужно получить требования: с этого начинается вход в тест-анализ.
🌽 1. Декомпозиция
Декомпозиция — разделение целого на части. На этом этапе тебе предстоит разбить крупные объекты тестирования на более мелкие. Так с ними удобнее работать. Например, функциональность работы со спамом можно разбить на два объекта: определение спама и сохранение в отдельной папке
🍫 2. Визуализация
Когда декомпозируешь требования, попробуй их визуализировать. Визуализация — создание наглядной схемы всех объектов тестирования. Так проще воспринимать и структурировать информацию. Если поймёшь, что на схеме чего-то не хватает, уточни требования. Визуализировать можно с помощью mind-карт и блок-схем.
🍾 3. Поиск серых зон
Когда декомпозируешь и визуализируешь требования, сможешь увидеть в них несостыковки, противоречия и пропуски — серые зоны. В этом случае обращайся к менеджеру, он поможет разобраться. Иногда приходится искать серые зоны повторно. Например, тебе удалось заметить неявные требования, доуточнить их и дополнить схему. Но оказалось, что в ней всё ещё есть слепые зоны. Их тоже нужно уточнить, декомпозировать и визуализировать: так ты получишь полное представление о том, что предстоит тестировать.
Следом я расскажу о проблемах с поиском серых зон.
#rdclr_QA
🍼 Тест-анализ (test analysis) — один из этапов тестирования, направленный на изучение требований и макетов. Когда будешь изучать, постарайся ответить на вопрос: что именно предстоит тестировать? Так ты составишь список объектов тестирования.
Объекты тестирования (test objects) — части приложения, которые нужно проверить. Например, компания сделала почтовый клиент — приложение, в котором можно обмениваться электронными письмами. В последнем обновлении разработчики добавили фичу: теперь приложение определяет спам и сохраняет его в отдельной папке.
Попробуй определить, что именно предстоит протестировать? Тестировщик будет проверять не всё приложение целиком, а определённую функциональность — работу со спамом. Но сначала нужно получить требования: с этого начинается вход в тест-анализ.
🌽 1. Декомпозиция
Декомпозиция — разделение целого на части. На этом этапе тебе предстоит разбить крупные объекты тестирования на более мелкие. Так с ними удобнее работать. Например, функциональность работы со спамом можно разбить на два объекта: определение спама и сохранение в отдельной папке
🍫 2. Визуализация
Когда декомпозируешь требования, попробуй их визуализировать. Визуализация — создание наглядной схемы всех объектов тестирования. Так проще воспринимать и структурировать информацию. Если поймёшь, что на схеме чего-то не хватает, уточни требования. Визуализировать можно с помощью mind-карт и блок-схем.
🍾 3. Поиск серых зон
Когда декомпозируешь и визуализируешь требования, сможешь увидеть в них несостыковки, противоречия и пропуски — серые зоны. В этом случае обращайся к менеджеру, он поможет разобраться. Иногда приходится искать серые зоны повторно. Например, тебе удалось заметить неявные требования, доуточнить их и дополнить схему. Но оказалось, что в ней всё ещё есть слепые зоны. Их тоже нужно уточнить, декомпозировать и визуализировать: так ты получишь полное представление о том, что предстоит тестировать.
Следом я расскажу о проблемах с поиском серых зон.
#rdclr_QA
Введение в тест-анализ #2: проблемы с поиском серых зон
🍩 неуточнённые и неполные требования
С первого раза их не заметить. Например, как должно выглядеть сообщение «Заказ оформлен»? Отдельное всплывающее окно? А какого цвета должен быть текст сообщения? Ещё одна серая зона: почему поле «Отчество» обязательное? Что делать, если его нет?
🍩 скрытые требования
Авторы документации не всегда включают требования, которые кажутся им очевидными. Например, логотип состоит из двух слов и должен быть кликабельным: только первое слово при нажатии ведёт на главную страницу, а второе — на каталог товаров.
макеты и требования расходятся. На макетах есть нижний блок со ссылками, но в требованиях его функциональность не описана. Другой пример: на макете поле называется «Email», а в требованиях — «Электронный адрес».
🍩 требований нет.
Такое тоже бывает)
Тест-анализ заканчивается, когда тебе удастся декомпозировать и визуализировать все требования, а также исключить серые зоны.
Советую на почитать:
1. Как находить ошибки в бизнес-логике фичей
2. Зачем проводить декомпозицию требований
3. Mind Map в помощь тестировщику
#rdclr_QA #read
🍩 неуточнённые и неполные требования
С первого раза их не заметить. Например, как должно выглядеть сообщение «Заказ оформлен»? Отдельное всплывающее окно? А какого цвета должен быть текст сообщения? Ещё одна серая зона: почему поле «Отчество» обязательное? Что делать, если его нет?
🍩 скрытые требования
Авторы документации не всегда включают требования, которые кажутся им очевидными. Например, логотип состоит из двух слов и должен быть кликабельным: только первое слово при нажатии ведёт на главную страницу, а второе — на каталог товаров.
макеты и требования расходятся. На макетах есть нижний блок со ссылками, но в требованиях его функциональность не описана. Другой пример: на макете поле называется «Email», а в требованиях — «Электронный адрес».
🍩 требований нет.
Такое тоже бывает)
Тест-анализ заканчивается, когда тебе удастся декомпозировать и визуализировать все требования, а также исключить серые зоны.
Советую на почитать:
1. Как находить ошибки в бизнес-логике фичей
2. Зачем проводить декомпозицию требований
3. Mind Map в помощь тестировщику
#rdclr_QA #read
👍2
Помогите выбрать, о чем рассказать вам на выходных, а что оставить на попозже? 🧐
Anonymous Poll
29%
Типы мобильных приложений и как их тестировать
31%
Особенность тестирования Web-приложений
43%
Тестирование API: на что обратить внимание
26%
Куда развиваться тестировщику
Тестирование API: на что обратить внимание
API (Application Programming Interface — программный интерфейс приложения) — интерфейс, который помогает приложениям взаимодействовать.
Приложения тоже могут отправлять команды, и другие приложения будут их выполнять. API помогает сервисам «общаться» и обмениваться информацией друг с другом.
🧐 На что обратить внимание при тестировании АПИ?
🦴 1. В первую очередь на URL, т. к. вы указываете куда идти за ресурсом. Неверный URL запроса вернет вам ошибку Couldn’t not send request, вы просто не сможете отправить запрос.
🦴 2. Method, чтобы понимать что с ресурсом надо сделать.
🦴 3. Тело запроса также важно проверять, так как в теле вы передаете информацию или обновляете существующую. Например, если неверно указать id — вернется ошибка 400 Bad Request.
🦴 4. В теле ответа также следует быть внимательным, создалось ли то, что мы хотели; какие значения в наших полях.
🦴 5. Формат передаваемых данных (json/xml). Если сервис принимает запросы только в джейсон, то при отправке другого формата вы получите ошибку 415 Unsupported Media Type.
🦴 6. Перестановка мест параметров не должна вызывать ошибку, так как от перестановки слагаемых... дальше мы знаем :).
🦴 7. Статус-код показывает успешен или нет наш запрос, а текст ошибки поможет понять, где мы допустили ошибку. Так как только наше АПИ будут использовать другие разработчики при интеграции первое с чем они столкнутся — это с ошибками. Они могут забыть указать заголовок или опечататься, поэтому сообщение об ошибки должно быть понятным.
🦴 8. Регистронезависимость заголовков: вне зависимости от написания они все должны передаваться.
🤬 При тестировании API негативные тесты очень важны! Например:
1. Что будет, если какой-либо из заголовков не передать?
2. Что будет, если передать неправильно и какой текст об ошибке мы увидим?
Позитивные тесты мы проводим по документации (все ли вернулось?). Проверяем это независимо от метода. Различие лишь в том, есть ли тело у метода или нет.
Что еще почитать по теме:
- Различия в тестировании REST и SOAP
- Быстро про API
#rdclr_QA #read
API (Application Programming Interface — программный интерфейс приложения) — интерфейс, который помогает приложениям взаимодействовать.
Приложения тоже могут отправлять команды, и другие приложения будут их выполнять. API помогает сервисам «общаться» и обмениваться информацией друг с другом.
🧐 На что обратить внимание при тестировании АПИ?
🦴 1. В первую очередь на URL, т. к. вы указываете куда идти за ресурсом. Неверный URL запроса вернет вам ошибку Couldn’t not send request, вы просто не сможете отправить запрос.
🦴 2. Method, чтобы понимать что с ресурсом надо сделать.
🦴 3. Тело запроса также важно проверять, так как в теле вы передаете информацию или обновляете существующую. Например, если неверно указать id — вернется ошибка 400 Bad Request.
🦴 4. В теле ответа также следует быть внимательным, создалось ли то, что мы хотели; какие значения в наших полях.
🦴 5. Формат передаваемых данных (json/xml). Если сервис принимает запросы только в джейсон, то при отправке другого формата вы получите ошибку 415 Unsupported Media Type.
🦴 6. Перестановка мест параметров не должна вызывать ошибку, так как от перестановки слагаемых... дальше мы знаем :).
🦴 7. Статус-код показывает успешен или нет наш запрос, а текст ошибки поможет понять, где мы допустили ошибку. Так как только наше АПИ будут использовать другие разработчики при интеграции первое с чем они столкнутся — это с ошибками. Они могут забыть указать заголовок или опечататься, поэтому сообщение об ошибки должно быть понятным.
🦴 8. Регистронезависимость заголовков: вне зависимости от написания они все должны передаваться.
🤬 При тестировании API негативные тесты очень важны! Например:
1. Что будет, если какой-либо из заголовков не передать?
2. Что будет, если передать неправильно и какой текст об ошибке мы увидим?
Позитивные тесты мы проводим по документации (все ли вернулось?). Проверяем это независимо от метода. Различие лишь в том, есть ли тело у метода или нет.
Что еще почитать по теме:
- Различия в тестировании REST и SOAP
- Быстро про API
#rdclr_QA #read
YouTube
Что такое API
Простым и понятным языком, с примерами! :)
Объяснение для тех, кто с API еще не сталкивался
Это фрагмент моего курса по тестированию REST API — http://testbase.ru/learn/rest-api
Объяснение для тех, кто с API еще не сталкивался
Это фрагмент моего курса по тестированию REST API — http://testbase.ru/learn/rest-api
👍4❤2
Всем привет и хорошего начала недели! Написала так много, что побуду с вами чуть подльше. 😺 Продолжаем тему тестирования, и кто не знаком, — дежурю я, Настя, middle QA. ✌🏻
👍5
Web-приложения и особенности их тестирования
В отличие от веб-сайта, веб-приложение — это полноценная программа, доступ к которой пользователь получает через интернет, то есть она не требует установки на устройство. Веб-приложение интерактивно и позволяет пользователям взаимодействовать с разными элементами: например, оставить заявку на покупку товара, оформить покупку авиабилета или прокомментировать пост друга.
Веб-приложения можно классифицировать по-разному: в зависимости от их функционала и назначения. Давайте подробнее разберем эти типы приложений, чтобы лучше понимать, как они работают и какое подойдет для ваших бизнес-задач.
Есть три основных шаблона построения сайтов:
🥘 MPA (multi-page application): многостраничное приложение, которое отправляет запрос на сервер и полностью обновляет страницу, когда с ней совершается действие.
🍔 SPA (single-page application): одностраничное приложение, содержащее HTML-страницу,которая динамически обновляется в зависимости от действий пользователя — без полной перезагрузки.
🧅 PWA (progressive web application): приложение, которое пользователь устанавливает и может использовать в режиме офлайн.
Компоненты веб приложения:
🫖 UI — интерфейс пользователя. Реализуется через браузер в виде Web страниц. Написание на HTML, CSS, JavaScript.
🍵 Серверная часть. Языки программирования PHP, Perl, C/C++, Java, Python, Ruby, NodeJS.
Что тестировать? 🌅
1. Дефекты могут находиться как на клиентской, так и на серверной стороне.
2. Отображение клиента — кроссбраузерность.
3. Тестирование форм и ролевых моделей.
4. Тестирование установки веб-приложения.
5. Тестирование базы данных.
6. Тестирование передачи данных.
7. Безопасность, нагрузка.
Можно еще почитать о распространенных багах на веб.
#rdclr_QA #read
В отличие от веб-сайта, веб-приложение — это полноценная программа, доступ к которой пользователь получает через интернет, то есть она не требует установки на устройство. Веб-приложение интерактивно и позволяет пользователям взаимодействовать с разными элементами: например, оставить заявку на покупку товара, оформить покупку авиабилета или прокомментировать пост друга.
Веб-приложения можно классифицировать по-разному: в зависимости от их функционала и назначения. Давайте подробнее разберем эти типы приложений, чтобы лучше понимать, как они работают и какое подойдет для ваших бизнес-задач.
Есть три основных шаблона построения сайтов:
🥘 MPA (multi-page application): многостраничное приложение, которое отправляет запрос на сервер и полностью обновляет страницу, когда с ней совершается действие.
🍔 SPA (single-page application): одностраничное приложение, содержащее HTML-страницу,которая динамически обновляется в зависимости от действий пользователя — без полной перезагрузки.
🧅 PWA (progressive web application): приложение, которое пользователь устанавливает и может использовать в режиме офлайн.
Компоненты веб приложения:
🫖 UI — интерфейс пользователя. Реализуется через браузер в виде Web страниц. Написание на HTML, CSS, JavaScript.
🍵 Серверная часть. Языки программирования PHP, Perl, C/C++, Java, Python, Ruby, NodeJS.
Что тестировать? 🌅
1. Дефекты могут находиться как на клиентской, так и на серверной стороне.
2. Отображение клиента — кроссбраузерность.
3. Тестирование форм и ролевых моделей.
4. Тестирование установки веб-приложения.
5. Тестирование базы данных.
6. Тестирование передачи данных.
7. Безопасность, нагрузка.
Можно еще почитать о распространенных багах на веб.
#rdclr_QA #read
👍2
Библиотека: Все необходимое для ручного тестирования Web-приложений
🫁 Теория:
- Чек-лист тестирования WEB приложений
- Особенности тестирования веб-приложений
- Виды тестирования веб-приложений — как выбрать нужный?
- Основы тестирования и отладки Веб-приложений
- Web Application Testing: Step by Step Process to make it Right
- Frameworks
- Все про HTML и CSS
- Все про JavaScript
- Domain, Host, DNS: google support | статья
- Браузеры и движки: статья | Blink | Gecko | WebKit
🫀 Названия элементов UI:
- Гайдлайны платформ
- Статья с примерами и названиями элементов
- User Interface Elements
- UI Docs
- UI Kit Rambler
🧠 Статистика и аналитика:
- Яндекс.Радар
- gs.statcounter.com
👋🏻 Инструменты:
- extensions: Web Developer | EditThisCookie
- Chrome DevTools: Documentation | статья | breakpoints
- Responsive design testing tool
- Xenu's Link Sleuth (check broken links)
- Валидаторы данных: Валидатор JSON | Валидатор XML
- JSON encode/decode: json_encode | json_decode
- Fiddler: Fiddler | статья
- Charles: Charles Proxy | статья
🦷 Облачные платформы для кросс-браузерного тестирования:
Browserstack | CrossBrowser Testing | Browser Ling | Lambdatest | Sauce Labs | TestingBot | Comparium | Browseemall | Multibrowser | Digital.ai | Ranorex | TestComplete
#rdclr_QA #product #read
🫁 Теория:
- Чек-лист тестирования WEB приложений
- Особенности тестирования веб-приложений
- Виды тестирования веб-приложений — как выбрать нужный?
- Основы тестирования и отладки Веб-приложений
- Web Application Testing: Step by Step Process to make it Right
- Frameworks
- Все про HTML и CSS
- Все про JavaScript
- Domain, Host, DNS: google support | статья
- Браузеры и движки: статья | Blink | Gecko | WebKit
🫀 Названия элементов UI:
- Гайдлайны платформ
- Статья с примерами и названиями элементов
- User Interface Elements
- UI Docs
- UI Kit Rambler
🧠 Статистика и аналитика:
- Яндекс.Радар
- gs.statcounter.com
👋🏻 Инструменты:
- extensions: Web Developer | EditThisCookie
- Chrome DevTools: Documentation | статья | breakpoints
- Responsive design testing tool
- Xenu's Link Sleuth (check broken links)
- Валидаторы данных: Валидатор JSON | Валидатор XML
- JSON encode/decode: json_encode | json_decode
- Fiddler: Fiddler | статья
- Charles: Charles Proxy | статья
🦷 Облачные платформы для кросс-браузерного тестирования:
Browserstack | CrossBrowser Testing | Browser Ling | Lambdatest | Sauce Labs | TestingBot | Comparium | Browseemall | Multibrowser | Digital.ai | Ranorex | TestComplete
#rdclr_QA #product #read
Хабр
Чек-лист тестирования WEB приложений
Привет! После публикации статьи « Чек-лист тестирования мобильных приложений », поступило большое количество сообщений про такой же чек-лист, только для WEB приложений. Чтобы ответить на этот вопрос...
❤2
Типы мобильных приложений и как их тестировать
Мобильное приложение — это программное обеспечение, которое специально разрабатывается на основе функционала современных гаджетов. Оно может использоваться совершенно по-разному: сейчас речь идёт не только об играх, музыкальных проигрывателях, но еще и о магазинах, онлайн-помощниках и прочих полезных сервисах. Это многофункциональный клиентоориентированный сервис, который можно загрузить на смартфон, используя для этого встроенный маркетплейс.
🌂 Чаще всего приложения для мобильных телефонов загружают на таких площадках, как Google Play или AppStore. Разработчики создают приложение либо под конкретную платформу, либо сразу для нескольких. Наиболее популярные операционные системы, для которых выпускаются новинки — это iOS, Android, Windows Phone.
🧚🏿♂️ Нативные приложения — это приложение, разработанное специально для одной платформы и на родном (с англ. native — родной) для определённой платформы языке программирования. Для Android этим языком является Java, тогда как для iOS — objective-С или Swift.
💃 Мобильные веб-приложения оптимизированы для легкого и удобного использования на мобильных устройствах. Запуская такие мобильные веб-приложения, пользователь выполняет все те действия, которые он выполняет при переходе на любой веб-сайт.
🧜🏿 Гибридные приложения представляют собой сочетание веб и нативных приложений. В особенности, имеется в виду их кроссплатформенность и доступ к функционалу смартфона.
🥵 Как тестировать мобильные приложения? 🥶
Любое приложение на Android, Windows Phone или iOS делится на важные блоки: front- и back-end. В первый входят элементы, которые использует пользователь, а второй является скрытой частью, с которой работают исключительно программисты, применяя для этого серверный софт. Таким образом эта система работает в совокупности, но с чётким разделением функционала и задач. Как тестировать?
1. Тестирование на различных платформах, версиях ОС, моделях устройств.
2. Использование эмуляторов или реальных устройств.
3. Работа с разными видами интернет-подключений (Wi-Fi, 4G, 3G, отсутствие связи).
4. Переход в фоновый режим при поступлении звонков и sms, срабатывании будильника.
5. Процесс переустановки и обновления приложения до новой версии.
#rdclr_QA
Мобильное приложение — это программное обеспечение, которое специально разрабатывается на основе функционала современных гаджетов. Оно может использоваться совершенно по-разному: сейчас речь идёт не только об играх, музыкальных проигрывателях, но еще и о магазинах, онлайн-помощниках и прочих полезных сервисах. Это многофункциональный клиентоориентированный сервис, который можно загрузить на смартфон, используя для этого встроенный маркетплейс.
🌂 Чаще всего приложения для мобильных телефонов загружают на таких площадках, как Google Play или AppStore. Разработчики создают приложение либо под конкретную платформу, либо сразу для нескольких. Наиболее популярные операционные системы, для которых выпускаются новинки — это iOS, Android, Windows Phone.
🧚🏿♂️ Нативные приложения — это приложение, разработанное специально для одной платформы и на родном (с англ. native — родной) для определённой платформы языке программирования. Для Android этим языком является Java, тогда как для iOS — objective-С или Swift.
💃 Мобильные веб-приложения оптимизированы для легкого и удобного использования на мобильных устройствах. Запуская такие мобильные веб-приложения, пользователь выполняет все те действия, которые он выполняет при переходе на любой веб-сайт.
🧜🏿 Гибридные приложения представляют собой сочетание веб и нативных приложений. В особенности, имеется в виду их кроссплатформенность и доступ к функционалу смартфона.
🥵 Как тестировать мобильные приложения? 🥶
Любое приложение на Android, Windows Phone или iOS делится на важные блоки: front- и back-end. В первый входят элементы, которые использует пользователь, а второй является скрытой частью, с которой работают исключительно программисты, применяя для этого серверный софт. Таким образом эта система работает в совокупности, но с чётким разделением функционала и задач. Как тестировать?
1. Тестирование на различных платформах, версиях ОС, моделях устройств.
2. Использование эмуляторов или реальных устройств.
3. Работа с разными видами интернет-подключений (Wi-Fi, 4G, 3G, отсутствие связи).
4. Переход в фоновый режим при поступлении звонков и sms, срабатывании будильника.
5. Процесс переустановки и обновления приложения до новой версии.
#rdclr_QA
👍3
Бибилиотека: все, что нужно для тестирования мобильных приложений 📚
📝 Теория, книги, статьи:
Чек-лист тестирования мобильных приложений
Push-уведомления
UI-элементы и жесты в мобильных приложениях
🖇 Guidelines:
iOS Interface Guidelines
Android Components
💻 IDE:
Android Studio
Xcode
🧩 Android specific:
Android Debug Bridge (adb)
Android developer options
Exerciser Monkey
Apkanalyzer
⚖️ Аналитика:
Firebase Crashlytics
⚙️ Симуляторы и эмуляторы Android:
Genymotion
BrowserStack App Live
🛠 Симуляторы и эмуляторы iOS:
Xcode Simulator
🍪 Фермы устройств:
Firebase Test Lab
Microsoft App Center
Samsung Remote Test Lab
AWS Device Farm
HUAWEI DIGIX Lab Test Services
🚜 Распределение платформ и устройств:
Мобильные ОС
Worldwide Mobile Vendor
🎮 Инструменты прокси трафика:
Fiddler
Charles Proxy
Mitmproxy
#read #rdclr_QA
📝 Теория, книги, статьи:
Чек-лист тестирования мобильных приложений
Push-уведомления
UI-элементы и жесты в мобильных приложениях
🖇 Guidelines:
iOS Interface Guidelines
Android Components
💻 IDE:
Android Studio
Xcode
🧩 Android specific:
Android Debug Bridge (adb)
Android developer options
Exerciser Monkey
Apkanalyzer
⚖️ Аналитика:
Firebase Crashlytics
⚙️ Симуляторы и эмуляторы Android:
Genymotion
BrowserStack App Live
🛠 Симуляторы и эмуляторы iOS:
Xcode Simulator
🍪 Фермы устройств:
Firebase Test Lab
Microsoft App Center
Samsung Remote Test Lab
AWS Device Farm
HUAWEI DIGIX Lab Test Services
🚜 Распределение платформ и устройств:
Мобильные ОС
Worldwide Mobile Vendor
🎮 Инструменты прокси трафика:
Fiddler
Charles Proxy
Mitmproxy
#read #rdclr_QA
Хабр
Чек-лист тестирования мобильных приложений
У многих начинающих специалистов в области тестирования возникает вопрос: «А как же протестировать мобильное приложение. С чего начать, какие проверки стоит осуществить?» Данный вопрос актуален, когда...
👍6
Android Debug Bridge (adb)
Android Debug Bridge (adb) — инструмент командной строки, который позволяет взаимодействовать с устройством. Команда adb упрощает выполнение различных действий с устройством, которую можно использовать для выполнения различных команд на устройстве.
Это клиент-серверная программа, состоящая из трех компонентов:
🌵 Клиент, отправляющий команды.
Клиент работает на вашей машине разработки. Вы можете вызвать клиента из терминала командной строки, введя команду adb.
🍀 Демон, запускающий команды на устройстве.
Демон работает в фоновом режиме на каждом устройстве.
🌳 Сервер, который управляет обменом данными между клиентом и демоном. Сервер работает как фоновый процесс на вашей машине разработки.
Установка ADB
adb входит в пакет Android SDK Platform-Tools. Скачать этот пакет можно с помощью SDK Manager , который устанавливает его в android_sdk/platform-tools/. Или, если вам нужен автономный пакет Android SDK Platform-Tools, вы можете скачать его с официального сайта.
Основные команды:
$ adb devices — просмотр списка устройств;
$ adb get-state — состояние устройства;
$ adb reboot — перезагрузка устройства;
$ adb install -f /path/some_name.apk — можно выполнить установку приложения во внутреннюю память;
$ adb shell pm list packages — список установленных приложений;
$ adb logcat — просмотр журналов системы и приложений.
Еще можно почитать про команды для ADB :)
#rdclr_QA #read
Android Debug Bridge (adb) — инструмент командной строки, который позволяет взаимодействовать с устройством. Команда adb упрощает выполнение различных действий с устройством, которую можно использовать для выполнения различных команд на устройстве.
Это клиент-серверная программа, состоящая из трех компонентов:
🌵 Клиент, отправляющий команды.
Клиент работает на вашей машине разработки. Вы можете вызвать клиента из терминала командной строки, введя команду adb.
🍀 Демон, запускающий команды на устройстве.
Демон работает в фоновом режиме на каждом устройстве.
🌳 Сервер, который управляет обменом данными между клиентом и демоном. Сервер работает как фоновый процесс на вашей машине разработки.
Установка ADB
adb входит в пакет Android SDK Platform-Tools. Скачать этот пакет можно с помощью SDK Manager , который устанавливает его в android_sdk/platform-tools/. Или, если вам нужен автономный пакет Android SDK Platform-Tools, вы можете скачать его с официального сайта.
Основные команды:
$ adb devices — просмотр списка устройств;
$ adb get-state — состояние устройства;
$ adb reboot — перезагрузка устройства;
$ adb install -f /path/some_name.apk — можно выполнить установку приложения во внутреннюю память;
$ adb shell pm list packages — список установленных приложений;
$ adb logcat — просмотр журналов системы и приложений.
Еще можно почитать про команды для ADB :)
#rdclr_QA #read
👍3
Куда развиваться тестировщику?
В любой профессии может быть множество разных ролей. Так и в тестировании: ручной тестировщик может совмещать роли проджект-менеджера или тест-аналитика. Например, работать над постановкой задач и курировать младших специалистов.
В тестировании можно условно выделить три направления:
🚙 ручное — продукт тестируют вручную;
🚕 автоматизированное — повторяющиеся тесты проводят автоматически, чтобы не тратить время на одни и те же проверки;
🚑 нагрузочное — специальными инструментами и скриптами проверяют, выдержит ли приложение высокую нагрузку. Например, при большом количестве пользователей или атаке ботов.
😎 Также выделяют уровни специалистов. В каждой компании — по-разному, но чаще всего уровни делят так:
Младший специалист, или джуниор (англ. junior)
Джуниор спрашивает, как сделать задачу: чаще всего он ещё не может сделать её или быстро подстроиться к новым условиям, вводным данным и окружению.
Специалист, или миддл (англ. middle)
Миддл спрашивает, какую задачу нужно сделать: он уже умеет выполнять несложные задачи самостоятельно — ему нужно только задать направление.
Старший специалист, или синьор (англ. senior)
Синьор спрашивает, зачем делать эту задачу: он может оценить полезность изменений, заметить потенциальные риски и спроектировать план задачи.
Ведущий специалист, или лид (англ. lead)
У ведущего специалиста уровень и экспертиза выше синьора. Как правило, он ведёт проекты либо руководит подразделением, либо принимает ключевые решения по технической части. Бывает и то, и другое одновременно — именно такую роль чаще всего играет QA Lead, он же руководитель отдела тестирования.
Сейчас компании все чаще выделяют такие позиции, как strong junior и strong middle, а в матрице скиллов конкретизируют требования к специалисту под каждый уровень. Также следует помнить, что в каждой компании свои требования и в компании «А» ты можешь быть junior, а в компании «В» middle.
В любом случае, я желаю удачи тебе в дальнейшем развитии, карьерного роста и вдохновения от дела, которым ты занимаешься! 🥂
#rdclr_QA
В любой профессии может быть множество разных ролей. Так и в тестировании: ручной тестировщик может совмещать роли проджект-менеджера или тест-аналитика. Например, работать над постановкой задач и курировать младших специалистов.
В тестировании можно условно выделить три направления:
🚙 ручное — продукт тестируют вручную;
🚕 автоматизированное — повторяющиеся тесты проводят автоматически, чтобы не тратить время на одни и те же проверки;
🚑 нагрузочное — специальными инструментами и скриптами проверяют, выдержит ли приложение высокую нагрузку. Например, при большом количестве пользователей или атаке ботов.
😎 Также выделяют уровни специалистов. В каждой компании — по-разному, но чаще всего уровни делят так:
Младший специалист, или джуниор (англ. junior)
Джуниор спрашивает, как сделать задачу: чаще всего он ещё не может сделать её или быстро подстроиться к новым условиям, вводным данным и окружению.
Специалист, или миддл (англ. middle)
Миддл спрашивает, какую задачу нужно сделать: он уже умеет выполнять несложные задачи самостоятельно — ему нужно только задать направление.
Старший специалист, или синьор (англ. senior)
Синьор спрашивает, зачем делать эту задачу: он может оценить полезность изменений, заметить потенциальные риски и спроектировать план задачи.
Ведущий специалист, или лид (англ. lead)
У ведущего специалиста уровень и экспертиза выше синьора. Как правило, он ведёт проекты либо руководит подразделением, либо принимает ключевые решения по технической части. Бывает и то, и другое одновременно — именно такую роль чаще всего играет QA Lead, он же руководитель отдела тестирования.
Сейчас компании все чаще выделяют такие позиции, как strong junior и strong middle, а в матрице скиллов конкретизируют требования к специалисту под каждый уровень. Также следует помнить, что в каждой компании свои требования и в компании «А» ты можешь быть junior, а в компании «В» middle.
В любом случае, я желаю удачи тебе в дальнейшем развитии, карьерного роста и вдохновения от дела, которым ты занимаешься! 🥂
#rdclr_QA
👍5
Разработчики из Воронежа, приходите знакомиться с нами в офлайне! 🀄
26 апреля собираемся на новый митап из серии RDCLR.HOME — о «Карте развития PHP-разработчика» расскажет специалист Red Collar Иван Марков.
Ждём в гости тех, кто только начинает изучение PHP, или уже освоил базы и хочет вырасти до уровня Middle/Senior.
— Поговорим про экосистему PHP.
— Расскажем, какие навыки увеличат вашу востребованность на рынке.
— Проанализируем понятие «хороший код».
— Пройдемся по карте навыков PHP.
Митап по традиции пройдет в нашем офисе в бизнес-парке «Текстильщики» по адресу: ул. Текстильщиков, 5б, 3 подъезд, 3 этаж.
Вход свободный, но количество мест ограничено. Успейте зарегистрироваться по ссылке: https://forms.gle/W66uESCgUEFBLzeF6
Подробнее о том, что такое RDCLR.HOME, читайте тут: https://vk.com/rdclr.home
26 апреля собираемся на новый митап из серии RDCLR.HOME — о «Карте развития PHP-разработчика» расскажет специалист Red Collar Иван Марков.
Ждём в гости тех, кто только начинает изучение PHP, или уже освоил базы и хочет вырасти до уровня Middle/Senior.
— Поговорим про экосистему PHP.
— Расскажем, какие навыки увеличат вашу востребованность на рынке.
— Проанализируем понятие «хороший код».
— Пройдемся по карте навыков PHP.
Митап по традиции пройдет в нашем офисе в бизнес-парке «Текстильщики» по адресу: ул. Текстильщиков, 5б, 3 подъезд, 3 этаж.
Вход свободный, но количество мест ограничено. Успейте зарегистрироваться по ссылке: https://forms.gle/W66uESCgUEFBLzeF6
Подробнее о том, что такое RDCLR.HOME, читайте тут: https://vk.com/rdclr.home
👍2
«Быть тим-лидом: ожидания и реальность» — первый материал от Red Collar на Хабре собрал больше 7 тысяч просмотров за неделю. 🦾 👾
Наш Java-разработчик Макс рассказал о том, как специалисту (вы)расти в тим-лида, научиться ловить баланс качества и сроков, прогнозировать риски и не стать по пути «мелким тираном».
🔹 Прочитать материал будет ценно не только разработчикам, но и руководителям любых направлений — Макс отдельно выделил вопросы грамотной коммуникации, актуальные для всех.
Читайте по ссылке: https://lnkd.in/ezdfPxtQ 🤝
Наш Java-разработчик Макс рассказал о том, как специалисту (вы)расти в тим-лида, научиться ловить баланс качества и сроков, прогнозировать риски и не стать по пути «мелким тираном».
🔹 Прочитать материал будет ценно не только разработчикам, но и руководителям любых направлений — Макс отдельно выделил вопросы грамотной коммуникации, актуальные для всех.
Читайте по ссылке: https://lnkd.in/ezdfPxtQ 🤝
lnkd.in
LinkedIn
This link will take you to a page that’s not on LinkedIn
👍5
Привет, меня зовут Павел, я backend-разработчик Red Collar! Пишу на Java/Kotlin. 🦾
На этой неделе буду автором на канале и расскажу вам:
- о принципах SOLID
- о Spring Data JDBC и её подводных камнях
- о Keycloak
Стартуем прямо сейчас!
На этой неделе буду автором на канале и расскажу вам:
- о принципах SOLID
- о Spring Data JDBC и её подводных камнях
- о Keycloak
Стартуем прямо сейчас!
❤14