Всем привет!👋
Давно ничего не публиковал. Был загружен на работе и разработкой своего проекта.
Сегодня у меня первый день после двухнедельного отпуска. Поэтому я отдохнул и немного вдохновился новыми идеями =)
С некоторых пор на консультациях, да и в личку, меня всё чаще спрашивают про тестирование в блокчейн-проектах.
Про особенности, про инструменты и т.д.
Кто-то просто любопытствует, а кто-то хочет попробовать себя в новой сфере.
Я подумал: почему бы не объяснить это всем. Не зря же я канал свой завел. 🥸
Постараюсь это сделать всё простым языком, с прицелом на нашу работу в QA. Хочу сделать серию постов, где мы разберём блокчейн для тестировщиков — без сложных терминов и с примерами из практики.
Дальше будет первый пост из серии.
Погнали! 🚀
Давно ничего не публиковал. Был загружен на работе и разработкой своего проекта.
Сегодня у меня первый день после двухнедельного отпуска. Поэтому я отдохнул и немного вдохновился новыми идеями =)
С некоторых пор на консультациях, да и в личку, меня всё чаще спрашивают про тестирование в блокчейн-проектах.
Про особенности, про инструменты и т.д.
Кто-то просто любопытствует, а кто-то хочет попробовать себя в новой сфере.
Я подумал: почему бы не объяснить это всем. Не зря же я канал свой завел. 🥸
Постараюсь это сделать всё простым языком, с прицелом на нашу работу в QA. Хочу сделать серию постов, где мы разберём блокчейн для тестировщиков — без сложных терминов и с примерами из практики.
Дальше будет первый пост из серии.
Погнали! 🚀
👍4⚡1🔥1
Блокчейн для тестировщика: разбираемся с основ без заумных слов
#QAвБлокчейн #Web3QA #BlockchainTesting
Что такое блокчейн (blockchain)?
Ты же знаешь, что такое база данных? Это структурированные данные, которые хранятся на сервере или кластере серверов под контролем одной компании.
А теперь представь одну общую базу данных, которая хранится на тысячах компьютеров по всему миру и синхронизирована между всеми участниками сети. Данные записываются в блоки, которые связаны между собой, как звенья цепи. Ключевая особенность: эти данные нельзя подделать или удалить. Это система, где каждая транзакция зафиксирована навсегда и защищена от изменений. Поэтому тестировать блокчейн нужно с максимальной точностью.
Чем это отличается от классических систем?
Если ты работал в классических(назовем их так) проектах, ты привык: словил баг на продакшне — откатил релиз, поправил базу, задеплоил заново. В блокчейне так не работает:
- Транзакции (например, перевод денег) после записи в блокчейн остаются там навсегда.
- Программы, которые управляют этими транзакциями (они называются смарт-контракты(smart contracts)), тоже неизменяемы после релиза. Баг в коде? Придётся деплоить новый контракт.
Что это значит для тестировщика?
1. Тесты — дело серьёзное. Ошибка в смарт-контракте может стоить миллионы. Тестировать нужно с дотошностью хирурга.
2. Прозрачность. В публичных блокчейнах все действия видны всем. Это значит, что твои тесты должны учитывать, что данные в публичных блокчейнах открыты для просмотра всем участникам сети.
3. Особенности среды. Транзакции в блокчейне зависят от сети, поэтому тестировать их нужно в специальных тестовых окружениях (testnets), чтобы не тратить реальные деньги.
В следующих постах разберём, как тестировать блокчейн, что за термины вроде "ноды" или "газ", и как подготовиться к переходу в эту сферу. Не пугайтесь новых слов — постепенно всё объясню просто и понятно 😎
Может ты уже сталкивался с блокчейном? или только присматриваешься? Пиши в комментариях, есть ли у тебя интерес к этому направлению.
Оставляй реакцию под постом, чтобы я видел интересны ли вам такая информация.🔥
#QAвБлокчейн #Web3QA #BlockchainTesting
Что такое блокчейн (blockchain)?
Ты же знаешь, что такое база данных? Это структурированные данные, которые хранятся на сервере или кластере серверов под контролем одной компании.
А теперь представь одну общую базу данных, которая хранится на тысячах компьютеров по всему миру и синхронизирована между всеми участниками сети. Данные записываются в блоки, которые связаны между собой, как звенья цепи. Ключевая особенность: эти данные нельзя подделать или удалить. Это система, где каждая транзакция зафиксирована навсегда и защищена от изменений. Поэтому тестировать блокчейн нужно с максимальной точностью.
Чем это отличается от классических систем?
Если ты работал в классических(назовем их так) проектах, ты привык: словил баг на продакшне — откатил релиз, поправил базу, задеплоил заново. В блокчейне так не работает:
- Транзакции (например, перевод денег) после записи в блокчейн остаются там навсегда.
- Программы, которые управляют этими транзакциями (они называются смарт-контракты(smart contracts)), тоже неизменяемы после релиза. Баг в коде? Придётся деплоить новый контракт.
Что это значит для тестировщика?
1. Тесты — дело серьёзное. Ошибка в смарт-контракте может стоить миллионы. Тестировать нужно с дотошностью хирурга.
2. Прозрачность. В публичных блокчейнах все действия видны всем. Это значит, что твои тесты должны учитывать, что данные в публичных блокчейнах открыты для просмотра всем участникам сети.
3. Особенности среды. Транзакции в блокчейне зависят от сети, поэтому тестировать их нужно в специальных тестовых окружениях (testnets), чтобы не тратить реальные деньги.
В следующих постах разберём, как тестировать блокчейн, что за термины вроде "ноды" или "газ", и как подготовиться к переходу в эту сферу. Не пугайтесь новых слов — постепенно всё объясню просто и понятно 😎
Может ты уже сталкивался с блокчейном? или только присматриваешься? Пиши в комментариях, есть ли у тебя интерес к этому направлению.
Оставляй реакцию под постом, чтобы я видел интересны ли вам такая информация.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11❤3⚡1
🔍 Web1 → Web2 → Web3: эволюция интернета и задачи для QA
#QAвБлокчейн #Web3QA #BlockchainTesting
Вы наверняка видели слово Web3 — в статьях, вакансиях или просто в ленте.
А вот Web1 и Web2 встречаются куда реже.
Но логично же — если есть третья версия, значит, были и первые две.
Давайте вспомним, как всё начиналось, и что это значит для нас, QA.
📟 Web1 (1990-е) — эпоха «только читалки».
• Сайты на голом HTML, без интерактива. Кстати, вот первый в мире веб-сайт
• Пользователь → только читает контент.
• Доступных CMS не было: я в то время учился делать первые веб-сайты в блокноте, ну может Dreamweaver попробовал слегка =).
👴🏻 Ставьте реакцию, кто такой же старый как и я =))
Работа QA веб-приложений в этот период: проверка загрузки страниц, ссылок, картинок. Просто… но скучно.
🌐 Web2 (2000-е – сейчас) — интернет, где можно кликать и общаться.
• Соцсети, маркетплейсы, банки, блоги — интерактив на каждом шагу.
• Данные — у корпораций (X, Instagram, Google, FB).
• Мой пост в Telegram? Или ваш в Instagram? На самом деле — не наш. Платформа может удалить или использовать для рекламы. Мы с вами просто "арендуем место".
Тут, конечно, QA отрываются по полной: тесты UX/UI, API, безопасность — всё, чем живёт современный веб.
⛓️ Web3 — интернет, где вы реально владеете своими данными.
• Всё на блокчейне, всё децентрализовано.
• Доступ через криптокошельки (MetaMask, Phantom и др.).
• Пост или картинка — это NFT: хотите — продайте, хотите — перенесите. Никто не удалит без вашего ключа.
• Примеры платформ: Mirror (для авторов), Lens Protocol (соцсети).
Что касается QA:
✅ Аудит смарт-контрактов (ошибка = миллионные убытки).
✅ Проверка транзакций (газ, скорость, сбои).
✅ Совместимость dApps с кошельками и сетями.
✅ Защита от атак (в т.ч. reentrancy).
💡 Итог: чем дальше эволюция интернета, тем веселее (и ответственнее) жизнь QA.
А в Web3 — ошибок прощают ещё меньше.
Так что, если хотите в эту сферу — готовьтесь тестировать так, чтобы было не стыдно показать в блокчейн.
#QAвБлокчейн #Web3QA #BlockchainTesting
Вы наверняка видели слово Web3 — в статьях, вакансиях или просто в ленте.
А вот Web1 и Web2 встречаются куда реже.
Но логично же — если есть третья версия, значит, были и первые две.
Давайте вспомним, как всё начиналось, и что это значит для нас, QA.
📟 Web1 (1990-е) — эпоха «только читалки».
• Сайты на голом HTML, без интерактива. Кстати, вот первый в мире веб-сайт
• Пользователь → только читает контент.
• Доступных CMS не было: я в то время учился делать первые веб-сайты в блокноте, ну может Dreamweaver попробовал слегка =).
👴🏻 Ставьте реакцию, кто такой же старый как и я =))
Работа QA веб-приложений в этот период: проверка загрузки страниц, ссылок, картинок. Просто… но скучно.
🌐 Web2 (2000-е – сейчас) — интернет, где можно кликать и общаться.
• Соцсети, маркетплейсы, банки, блоги — интерактив на каждом шагу.
• Данные — у корпораций (X, Instagram, Google, FB).
• Мой пост в Telegram? Или ваш в Instagram? На самом деле — не наш. Платформа может удалить или использовать для рекламы. Мы с вами просто "арендуем место".
Тут, конечно, QA отрываются по полной: тесты UX/UI, API, безопасность — всё, чем живёт современный веб.
⛓️ Web3 — интернет, где вы реально владеете своими данными.
• Всё на блокчейне, всё децентрализовано.
• Доступ через криптокошельки (MetaMask, Phantom и др.).
• Пост или картинка — это NFT: хотите — продайте, хотите — перенесите. Никто не удалит без вашего ключа.
• Примеры платформ: Mirror (для авторов), Lens Protocol (соцсети).
Что касается QA:
✅ Аудит смарт-контрактов (ошибка = миллионные убытки).
✅ Проверка транзакций (газ, скорость, сбои).
✅ Совместимость dApps с кошельками и сетями.
✅ Защита от атак (в т.ч. reentrancy).
💡 Итог: чем дальше эволюция интернета, тем веселее (и ответственнее) жизнь QA.
А в Web3 — ошибок прощают ещё меньше.
Так что, если хотите в эту сферу — готовьтесь тестировать так, чтобы было не стыдно показать в блокчейн.
⚡3❤3🔥2
Как работает блокчейн: простыми словами для QA
#QAвБлокчейн #Web3QA #BlockchainTesting
Когда слышишь «блокчейн», в голове сразу: что-то сложное, про биткоины, NFT, программирование.
На самом деле принцип очень логичный, и понять его проще, чем кажется.
📦 Блоки
Представь, что данные (например, список транзакций) собираются в «коробку» — это и есть блок.
Когда блок заполняется — он «закрывается» и присоединяется к предыдущему. Так образуется цепочка блоков (chain).
🔗 Хэш-связь
У каждого блока есть свой «отпечаток» — хэш.
Если кто-то попробует поменять хоть байт в старом блоке, его хэш изменится, и цепочка «сломается». Так блокчейн защищает данные от подделки.
👥 Децентрализация
Копии этой цепочки есть на тысячах компьютеров (ноды) по всему миру. Все ноды синхронизируются и приходят к согласию (консенсусу) о том, какой блок следующий.
⚙️ Как добавляется блок
➡️ Кто-то создаёт транзакцию (например, перевод токенов).
➡️ Она попадает в «очередь» неподтверждённых операций.
➡️ Участники сети проверяют транзакцию и формируют блок.
➡️ После достижения консенсуса блок добавляется в цепочку, и таким образом запись о транзакции запечатывается в блокчейне навсегда.
🐞 Где бывают баги
- В смарт-контрактах (ошибки логики, уязвимости).
- В интеграции dApp с блокчейном.
- В неправильной обработке данных - кошельками или приложениями.
- В расчёте комиссии (газа).
💡 Что важно для QA
Тестировать нужно не только основную функциональность, но и то, как система реагирует на ошибки и нестандартные сценарии.
В блокчейн-проектах особенно важно убедиться, что некорректные действия не приводят к сбоям или потере данных.
После релиза код смарт-контракта не поменяешь — лучше поймать баги до деплоя.
P.S.: Если ты встретил незнакомые слова - не переживай. В следующем посте я объясню терминологию 🥸
#QAвБлокчейн #Web3QA #BlockchainTesting
Когда слышишь «блокчейн», в голове сразу: что-то сложное, про биткоины, NFT, программирование.
На самом деле принцип очень логичный, и понять его проще, чем кажется.
📦 Блоки
Представь, что данные (например, список транзакций) собираются в «коробку» — это и есть блок.
Когда блок заполняется — он «закрывается» и присоединяется к предыдущему. Так образуется цепочка блоков (chain).
🔗 Хэш-связь
У каждого блока есть свой «отпечаток» — хэш.
Если кто-то попробует поменять хоть байт в старом блоке, его хэш изменится, и цепочка «сломается». Так блокчейн защищает данные от подделки.
👥 Децентрализация
Копии этой цепочки есть на тысячах компьютеров (ноды) по всему миру. Все ноды синхронизируются и приходят к согласию (консенсусу) о том, какой блок следующий.
⚙️ Как добавляется блок
➡️ Кто-то создаёт транзакцию (например, перевод токенов).
➡️ Она попадает в «очередь» неподтверждённых операций.
➡️ Участники сети проверяют транзакцию и формируют блок.
➡️ После достижения консенсуса блок добавляется в цепочку, и таким образом запись о транзакции запечатывается в блокчейне навсегда.
🐞 Где бывают баги
- В смарт-контрактах (ошибки логики, уязвимости).
- В интеграции dApp с блокчейном.
- В неправильной обработке данных - кошельками или приложениями.
- В расчёте комиссии (газа).
💡 Что важно для QA
Тестировать нужно не только основную функциональность, но и то, как система реагирует на ошибки и нестандартные сценарии.
В блокчейн-проектах особенно важно убедиться, что некорректные действия не приводят к сбоям или потере данных.
После релиза код смарт-контракта не поменяешь — лучше поймать баги до деплоя.
P.S.: Если ты встретил незнакомые слова - не переживай. В следующем посте я объясню терминологию 🥸
🔥6❤1⚡1
Из скрипта в сервис: веб-инструмент для команды.
Часть 1 — Как Postman избавил меня от рутины
#карьера #инициатива #postman
Это история о том, как набор скриптов, которые я делал «для себя», постепенно вырос в идею полноценного веб-инструмента для всей компании.
За несколько месяцев я прошёл путь:
1️⃣ Postman-коллекции, которые экономили пару часов рутинной работы,
2️⃣ автотесты на Playwright, превращённые в генератор тестовых данных,
3️⃣ и, наконец, MVP веб-сервиса, который может ускорить всех.
Делюсь в трёх частях — не только чтобы рассказать, но и чтобы услышать опыт коллег: как у вас решают такие задачи, что работает, а что нет.
Начнём пожалуй с начала...
В тестирование я пришел в 2013 году...хотя нет. Не с самого начала буду вещать, иначе получится не 3 части, а 33.
В октябре прошлого года, я пришёл в компанию Teez (новый маркетплейс в Казахстане), занимаюсь ручным тестированием и автоматизацией.
Как в целом и на любом другом проекте, часто возникает ситуация: под новую фичу нужно создать заказы в нужном состоянии. Ну или для регресса подготовить данные. Или аналитик, попросил, или кто-то из смежной команды. Думаю вам знакома такая ситуация.
И это не просто «накидать» пару записей в БД — у нас несколько систем:
B2B — для продавцов,
WMS — склад,
B2C — витрина,
ПВЗ — пункты выдачи.
Много взаимосвязей.
Один заказ руками создавать — 15–30 минут. А если таких заказов 10? Пара часов только на подготовку тестовых данных уходит.
Я люблю Postman, поэтому как пришел на проект, разобрался в системе, быстро накидал себе коллекции со скриптами, которые помогали с рутиной. И процессы, которые приходилось выполнять по 20 минут, делал за 3 минуты.
Условно:
ввёл номер заказа → нажал Send → и заказ уже в нужном статусе.
Поделился с коллегами из тестирования, написал инструкцию, провёл демо — многие сказали «вау круто», но сложилось впечатление, что многие остались в Swagger. И не особо моими коллекциями пользовались.
Мне Postman привычен, много лет с ним работаю, со времен когда он был просто плагином в Chrome. Если ты его настроил под проект — это совсем другой уровень удобства.
И вот тут я впервые задумался:
🔹 Как сделать так, чтобы даже те, кто не фанат Postman, могли легко пользоваться готовыми скриптами?
В следующей части расскажу, к какому решению я в тот момент пришел.
💬 А вы используете Postman для подготовки тестовых данных?
📌 Используете Постман(аналогичные инструменты) или обходитесь Swagger?
Часть 1 — Как Postman избавил меня от рутины
#карьера #инициатива #postman
Это история о том, как набор скриптов, которые я делал «для себя», постепенно вырос в идею полноценного веб-инструмента для всей компании.
За несколько месяцев я прошёл путь:
1️⃣ Postman-коллекции, которые экономили пару часов рутинной работы,
2️⃣ автотесты на Playwright, превращённые в генератор тестовых данных,
3️⃣ и, наконец, MVP веб-сервиса, который может ускорить всех.
Делюсь в трёх частях — не только чтобы рассказать, но и чтобы услышать опыт коллег: как у вас решают такие задачи, что работает, а что нет.
Начнём пожалуй с начала...
В тестирование я пришел в 2013 году...хотя нет. Не с самого начала буду вещать, иначе получится не 3 части, а 33.
В октябре прошлого года, я пришёл в компанию Teez (новый маркетплейс в Казахстане), занимаюсь ручным тестированием и автоматизацией.
Как в целом и на любом другом проекте, часто возникает ситуация: под новую фичу нужно создать заказы в нужном состоянии. Ну или для регресса подготовить данные. Или аналитик, попросил, или кто-то из смежной команды. Думаю вам знакома такая ситуация.
И это не просто «накидать» пару записей в БД — у нас несколько систем:
B2B — для продавцов,
WMS — склад,
B2C — витрина,
ПВЗ — пункты выдачи.
Много взаимосвязей.
Один заказ руками создавать — 15–30 минут. А если таких заказов 10? Пара часов только на подготовку тестовых данных уходит.
Я люблю Postman, поэтому как пришел на проект, разобрался в системе, быстро накидал себе коллекции со скриптами, которые помогали с рутиной. И процессы, которые приходилось выполнять по 20 минут, делал за 3 минуты.
Условно:
ввёл номер заказа → нажал Send → и заказ уже в нужном статусе.
Поделился с коллегами из тестирования, написал инструкцию, провёл демо — многие сказали «вау круто», но сложилось впечатление, что многие остались в Swagger. И не особо моими коллекциями пользовались.
Мне Postman привычен, много лет с ним работаю, со времен когда он был просто плагином в Chrome. Если ты его настроил под проект — это совсем другой уровень удобства.
И вот тут я впервые задумался:
🔹 Как сделать так, чтобы даже те, кто не фанат Postman, могли легко пользоваться готовыми скриптами?
В следующей части расскажу, к какому решению я в тот момент пришел.
💬 А вы используете Postman для подготовки тестовых данных?
📌 Используете Постман(аналогичные инструменты) или обходитесь Swagger?
🔥13
🔹 Из скрипта в сервис: веб-инструмент для команды 🔹
Часть 2 — Когда Postman уже не хватало
#карьера #инициатива #postman
В первой части я писал, как Postman помог мне ускорить рутину.
Но со временем захотелось инструмент мощнее.
⚙️ В декабре в компании появился лид по автоматизации, и я подключился к фреймворку на Playwright.
Первый же e2e-тест подсказал идею: а что если собрать в нём утилиту для генерации данных?
Я сделал тест с настройками:
- сколько заказов создать,
- какие товары добавить,
- какие этапы пройти (создание → оплата → отбор → упаковка → отгрузка).
Запускаешь — и за пару минут получаешь заказы в нужных статусах.
Для меня это было удобнее и быстрее, чем Postman.
Но для коллег порог входа оказался выше: репа, окружение, VS Code.
Кто-то честно сказал: «Проще руками».
Нет. Не потому что знаний или опыта не хватит. С этим у ребят всё норм.
Просто тестовые данные "нужны еще вчера".
Потратить полчаса сейчас, чтобы руками сделать всё - быстрей, чем ты час будешь разбираться, как у себя всё настроить.
Точно такая же история мне кажется была и с Postman.
И вот тогда я понял: инструмент должен быть простым.
Чтобы открыл веб-страницу, ввёл данные — и готово.
💡 Я не разработчик, только учусь писать автотесты. И начал думать как на мой тест натянуть веб интерфейс? 🤔
Мне очень хотелось сделать полезный и удобный инструмент для всех.
И я сделал.
На прошлой неделе, в пятницу, показал MVP руководству.
И… получил зелёный свет 🚀
В финальной части расскажу, что именно сделал и как прошло демо.
💬 А у вас бывало, что ваши скрипты, которые вы делали себе в помощь, превращались в полноценные «утилиты для всех»?
Часть 2 — Когда Postman уже не хватало
#карьера #инициатива #postman
В первой части я писал, как Postman помог мне ускорить рутину.
Но со временем захотелось инструмент мощнее.
⚙️ В декабре в компании появился лид по автоматизации, и я подключился к фреймворку на Playwright.
Первый же e2e-тест подсказал идею: а что если собрать в нём утилиту для генерации данных?
Я сделал тест с настройками:
- сколько заказов создать,
- какие товары добавить,
- какие этапы пройти (создание → оплата → отбор → упаковка → отгрузка).
Запускаешь — и за пару минут получаешь заказы в нужных статусах.
Для меня это было удобнее и быстрее, чем Postman.
Но для коллег порог входа оказался выше: репа, окружение, VS Code.
Кто-то честно сказал: «Проще руками».
Нет. Не потому что знаний или опыта не хватит. С этим у ребят всё норм.
Просто тестовые данные "нужны еще вчера".
Потратить полчаса сейчас, чтобы руками сделать всё - быстрей, чем ты час будешь разбираться, как у себя всё настроить.
Точно такая же история мне кажется была и с Postman.
И вот тогда я понял: инструмент должен быть простым.
Чтобы открыл веб-страницу, ввёл данные — и готово.
💡 Я не разработчик, только учусь писать автотесты. И начал думать как на мой тест натянуть веб интерфейс? 🤔
Мне очень хотелось сделать полезный и удобный инструмент для всех.
И я сделал.
На прошлой неделе, в пятницу, показал MVP руководству.
И… получил зелёный свет 🚀
В финальной части расскажу, что именно сделал и как прошло демо.
💬 А у вас бывало, что ваши скрипты, которые вы делали себе в помощь, превращались в полноценные «утилиты для всех»?
🔥6❤3
🔹 Из скрипта в сервис: веб-инструмент для команды 🔹
Часть 3 - Что получилось в итоге
#карьера #инициатива #postman
В прошлых частях я рассказывал, как Postman помог ускорить рутину, а Playwright-тест подсказал идею для утилиты.
Сегодня - финал: что получилось в итоге 👇
💻 Что я сделал:
Сначала хотел натянуть веб-интерфейс прямо на Playwright-тест, но быстро понял: это не прям чтобы замечательная идея.
Поэтому пошёл другим путём - сделал обёртку над API. Систем несколько, начал с одной и постепенно буду подключать остальные.
Так как у меня уже была основа, тесты, функции, которые были написаны для фреймворка, для автотестов. Я их и переиспользовал.
Переписал свой тест именно как апи.
Сейчас инструмент умеет:
Обрабатывать заказы по этапам (отбор → сортировка → упаковка → отгрузка)
- Автоматически проходить промежуточные статусы
- Переключаться между двумя тестовыми стендами
- Логировать все операции в реальном времени
Технически это:
Backend на Node.js + Express
Frontend на Vue 3 + Tailwind CSS
Что это даёт?
Главное - никакой возни с установкой или окружением.
Зашёл по ссылке — и сразу работаешь. Проблема была в том, что без согласования мне навряд ли кто-то бы выделил место и поддомен в корпоративной среде.
Поэтому надо было идти к руководству.
Но не с пустыми же руками? Поэтому реализовал MVP с базовой функциональностью, которая уже сейчас сильно поможет.
Стукнул в Slack. Поделился идеей.
Сказали: "Сможешь показать? Ставь встречу"
🎯 Как прошло демо:
В пятницу показал MVP руководству. Создал заказ, прогнал все этапы - заняло 5 секунд.
Для сравнения: вручную это занимает 15–20 минут у опытного тестировщика. И делать это приходится часто.
Инструмент понравился, потенциал есть.
Поэтому тут же в пятницу оформил заявку в DevOps на деплой 🚀
После этого коллеги смогут им пользоваться. 😊
✨ Что я понял:
Простота важнее мощности - если сложно запустить, не будут использовать
Автоматизация должна быть доступной, а не только для тех, кто умеет кодить
MVP не обязан быть идеальным, главное - решать конкретную боль команды
📌 Планы на будущее:
Добавить создание заказов с нуля
Подключить новые системы и API
Сделать аналитику и статистику использования
Мораль: даже если ты не разработчик, но видишь проблему и можешь её автоматизировать - реально создать инструмент, который будет полезен всей команде. Сделай это!
А у вас бывало, что маленький скрипт со временем превращался в мини-сервис? Делитесь историями 👇
Часть 3 - Что получилось в итоге
#карьера #инициатива #postman
В прошлых частях я рассказывал, как Postman помог ускорить рутину, а Playwright-тест подсказал идею для утилиты.
Сегодня - финал: что получилось в итоге 👇
💻 Что я сделал:
Сначала хотел натянуть веб-интерфейс прямо на Playwright-тест, но быстро понял: это не прям чтобы замечательная идея.
Поэтому пошёл другим путём - сделал обёртку над API. Систем несколько, начал с одной и постепенно буду подключать остальные.
Так как у меня уже была основа, тесты, функции, которые были написаны для фреймворка, для автотестов. Я их и переиспользовал.
Переписал свой тест именно как апи.
Сейчас инструмент умеет:
Обрабатывать заказы по этапам (отбор → сортировка → упаковка → отгрузка)
- Автоматически проходить промежуточные статусы
- Переключаться между двумя тестовыми стендами
- Логировать все операции в реальном времени
Технически это:
Backend на Node.js + Express
Frontend на Vue 3 + Tailwind CSS
Что это даёт?
Главное - никакой возни с установкой или окружением.
Зашёл по ссылке — и сразу работаешь. Проблема была в том, что без согласования мне навряд ли кто-то бы выделил место и поддомен в корпоративной среде.
Поэтому надо было идти к руководству.
Но не с пустыми же руками? Поэтому реализовал MVP с базовой функциональностью, которая уже сейчас сильно поможет.
Стукнул в Slack. Поделился идеей.
Сказали: "Сможешь показать? Ставь встречу"
🎯 Как прошло демо:
В пятницу показал MVP руководству. Создал заказ, прогнал все этапы - заняло 5 секунд.
Для сравнения: вручную это занимает 15–20 минут у опытного тестировщика. И делать это приходится часто.
Инструмент понравился, потенциал есть.
Поэтому тут же в пятницу оформил заявку в DevOps на деплой 🚀
После этого коллеги смогут им пользоваться. 😊
✨ Что я понял:
Простота важнее мощности - если сложно запустить, не будут использовать
Автоматизация должна быть доступной, а не только для тех, кто умеет кодить
MVP не обязан быть идеальным, главное - решать конкретную боль команды
📌 Планы на будущее:
Добавить создание заказов с нуля
Подключить новые системы и API
Сделать аналитику и статистику использования
Мораль: даже если ты не разработчик, но видишь проблему и можешь её автоматизировать - реально создать инструмент, который будет полезен всей команде. Сделай это!
А у вас бывало, что маленький скрипт со временем превращался в мини-сервис? Делитесь историями 👇
🔥5⚡1