Всем привет! Это разработческий канал от сотрудников Red Collar.
Каждую неделю один из сотрудников компании рассказывает о своих задачах, сложностях, решениях, делится полезными ссылками и мыслями на тему разработки.
Стремимся применять современные языки и новые подходы в разработке, ценим качественную работу, любим сложные задачи и открыты к критике, если вы тоже — мы на одной волне. :)
В компании занимаемся двумя направлениями:
- Разработкой сложных продуктов, сервисов для сотен тысяч пользователей для ведущих финтех-, телеком-, IT-, HoReCa- и логистических компаний.
- Созданием эстетичных корпоративных и промосайтов, которые становятся лучшими в своей сфере и берут самые сложные международные награды.
По тегам можно найти темы:
#rdclr_frontend — #Vanilla_JS #JavaScript #React #WebGL
#rdclr_backend — #Java #Python #PHP #NN
#rdclr_DevOps
#rdclr_QA
#product (мысли, применимые к сервисно-продуктовым историям)
#aesthetic (про эстетичность интерфейсов) #teamlead — про роль, практики и рост в тим-лида
#optimization (про оптимизацию кода для скорости и плавности работы проекта) и #library (набор инструментов для упрощения жизни разработчика)
#read (полезные ссылки для изучения нового материала)
#meme (на посмеяться) и #news (новости)
Чтобы совместить два тега — введите оба в поисковую строку канала.
Каждую неделю один из сотрудников компании рассказывает о своих задачах, сложностях, решениях, делится полезными ссылками и мыслями на тему разработки.
Стремимся применять современные языки и новые подходы в разработке, ценим качественную работу, любим сложные задачи и открыты к критике, если вы тоже — мы на одной волне. :)
В компании занимаемся двумя направлениями:
- Разработкой сложных продуктов, сервисов для сотен тысяч пользователей для ведущих финтех-, телеком-, IT-, HoReCa- и логистических компаний.
- Созданием эстетичных корпоративных и промосайтов, которые становятся лучшими в своей сфере и берут самые сложные международные награды.
По тегам можно найти темы:
#rdclr_frontend — #Vanilla_JS #JavaScript #React #WebGL
#rdclr_backend — #Java #Python #PHP #NN
#rdclr_DevOps
#rdclr_QA
#product (мысли, применимые к сервисно-продуктовым историям)
#aesthetic (про эстетичность интерфейсов) #teamlead — про роль, практики и рост в тим-лида
#optimization (про оптимизацию кода для скорости и плавности работы проекта) и #library (набор инструментов для упрощения жизни разработчика)
#read (полезные ссылки для изучения нового материала)
#meme (на посмеяться) и #news (новости)
Чтобы совместить два тега — введите оба в поисковую строку канала.
Цикл Деминга-Шухарта — универсальный подход к ведению проекта и его непрерывному улучшению.
Цикл Деминга-Шухарта, или Цикл PDCA — известная модель непрерывного улучшения процессов, получившая название цикла Шухарта-Деминга или цикла PDCA, применение которой в самых различных областях деятельности позволяет эффективно управлять этой деятельностью на системной основе. Цикл состоит из 4 этапов.
Планирование (Plan) — разберитесь, почему что-то не получается, в чём проблема. На этом этапе необходимо сформулировать цель, а также выяснить, к какому результату стремитесь и какие методы помогут в его достижении. Для этого составляется так называемые action план или план действий.
|
Реализация (Do) — работайте согласно новому плану и не нарушайте его условия.
|
Проверка (Check) — этот этап продразумевает проверку полученных результатов и их исследования. Необходимо понять куда мы движемся. Процесс становится лучше или хуже, и в чем причины этого.
|
Действие (Action) — здесь необходимо исправить ошибки. Если нужно, то внести изменения в требования и сам процесс.
Цикл Деминга не имеет конца, это постоянный цикл улучшения процесса разработки ПО.
#rdclr_QA #product
Цикл Деминга-Шухарта, или Цикл PDCA — известная модель непрерывного улучшения процессов, получившая название цикла Шухарта-Деминга или цикла PDCA, применение которой в самых различных областях деятельности позволяет эффективно управлять этой деятельностью на системной основе. Цикл состоит из 4 этапов.
Планирование (Plan) — разберитесь, почему что-то не получается, в чём проблема. На этом этапе необходимо сформулировать цель, а также выяснить, к какому результату стремитесь и какие методы помогут в его достижении. Для этого составляется так называемые action план или план действий.
|
Реализация (Do) — работайте согласно новому плану и не нарушайте его условия.
|
Проверка (Check) — этот этап продразумевает проверку полученных результатов и их исследования. Необходимо понять куда мы движемся. Процесс становится лучше или хуже, и в чем причины этого.
|
Действие (Action) — здесь необходимо исправить ошибки. Если нужно, то внести изменения в требования и сам процесс.
Цикл Деминга не имеет конца, это постоянный цикл улучшения процесса разработки ПО.
#rdclr_QA #product
Разберем принципы менеджмента Э. Деминга — первые 7
Хороший QA — это никогда не тестировщик на уровне ловли багов, а инженер и менеджер, который видит картину проекта целиком, предупреждает ошибки работы кода, глубоко погружается в каждую задачу и помогает команде неустанно улучшать качество продукта.
Упомянутые пункты ниже не охватывают всей философии Деминга, хотя и служат важной ее частью. Они служат для понимания того, что существуют лучшие пути организации процессов.
🎯 1. Постоянство цели.
Будьте неизменно тверды и постоянны в достижении поставленной цели. Распределяйте ресурсы таким образом, чтобы обеспечить долговременные цели и потребности, а не сиюминутную прибыль.
♟ 2. Новая философия качества.
Примите ее. Она должна быть абсолютной: недопустимость задержек, дефектов, ошибок и брака в работе.
💎 3. Изменение отношения к контролю.
Исключите потребность в массовом контроле, как способе достижения приемлемого уровня качества. Достигайте высокого результата путем встраивания качества в производимое ПО и процессы, сделав качество неотъемлемой их характеристикой.
🪃 4. Покончите с практикой оценки и выбора поставщиков лишь на основе цены на их продукцию.
Вместо этого наряду с ценой требуйте серьезных подтверждений качества продукта. Этот пункт напрямую связан с предыдущим. Мы можем покончить с потребностью проверки во входном контроле, только если будем верить, что поставщик придерживается таких же высоких стандартов качества, что и мы.
🚀 5. Улучшайте каждый процесс.
Сегодня и всегда улучшайте все процессы анализа, планирования, разработки, тестирования, поддержки. Выискивайте проблемы, чтобы совершенствовать все этапы разработки ПО, повышайте качество и производительность и, таким образом, постоянно уменьшайте издержки.
🎱 6. Учите всех, в том числе и менеджмент.
Введите в практику современные подходы к подготовке и переподготовки всех сотрудников, чтобы лучше использовать возможности каждого из них. Чтобы успевать за всеми изменениями, постоянно требуются новые навыки и умения.
🤝 7. Новые методы руководства. Руководитель — учитель, а не надзиратель.
Если руководитель тратит свое время на жесткий контроль подчиненных, это прямо свидетельствует о низких стандартах качества. Менеджмент будет сам себя вводить в заблуждение, что недобросовестное отношение рабочих к делу — причина низкого качества. Необходимо создать такую среду, в которой люди буду заинтересованы в своей работе. Однако часто можно видеть противоположную картину. Условия принуждают человека выполнять свое дело плохо, и он тогда теряет интерес к работе, что приводит к более низком качеству.
#rdclr_QA #product
Хороший QA — это никогда не тестировщик на уровне ловли багов, а инженер и менеджер, который видит картину проекта целиком, предупреждает ошибки работы кода, глубоко погружается в каждую задачу и помогает команде неустанно улучшать качество продукта.
Упомянутые пункты ниже не охватывают всей философии Деминга, хотя и служат важной ее частью. Они служат для понимания того, что существуют лучшие пути организации процессов.
🎯 1. Постоянство цели.
Будьте неизменно тверды и постоянны в достижении поставленной цели. Распределяйте ресурсы таким образом, чтобы обеспечить долговременные цели и потребности, а не сиюминутную прибыль.
♟ 2. Новая философия качества.
Примите ее. Она должна быть абсолютной: недопустимость задержек, дефектов, ошибок и брака в работе.
💎 3. Изменение отношения к контролю.
Исключите потребность в массовом контроле, как способе достижения приемлемого уровня качества. Достигайте высокого результата путем встраивания качества в производимое ПО и процессы, сделав качество неотъемлемой их характеристикой.
🪃 4. Покончите с практикой оценки и выбора поставщиков лишь на основе цены на их продукцию.
Вместо этого наряду с ценой требуйте серьезных подтверждений качества продукта. Этот пункт напрямую связан с предыдущим. Мы можем покончить с потребностью проверки во входном контроле, только если будем верить, что поставщик придерживается таких же высоких стандартов качества, что и мы.
🚀 5. Улучшайте каждый процесс.
Сегодня и всегда улучшайте все процессы анализа, планирования, разработки, тестирования, поддержки. Выискивайте проблемы, чтобы совершенствовать все этапы разработки ПО, повышайте качество и производительность и, таким образом, постоянно уменьшайте издержки.
🎱 6. Учите всех, в том числе и менеджмент.
Введите в практику современные подходы к подготовке и переподготовки всех сотрудников, чтобы лучше использовать возможности каждого из них. Чтобы успевать за всеми изменениями, постоянно требуются новые навыки и умения.
🤝 7. Новые методы руководства. Руководитель — учитель, а не надзиратель.
Если руководитель тратит свое время на жесткий контроль подчиненных, это прямо свидетельствует о низких стандартах качества. Менеджмент будет сам себя вводить в заблуждение, что недобросовестное отношение рабочих к делу — причина низкого качества. Необходимо создать такую среду, в которой люди буду заинтересованы в своей работе. Однако часто можно видеть противоположную картину. Условия принуждают человека выполнять свое дело плохо, и он тогда теряет интерес к работе, что приводит к более низком качеству.
#rdclr_QA #product
Принципы менеджмента Э. Деминга, продолжение цикла, 8-14.
В целом, рекомендую к прочтению его полную книгу «Выход из кризиса». Она поможет в освоении новой философии менеджмента через отказ от традиционных методов. Но для скорости продолжаю (и заканчиваю) выжимку принципов, которые вынес из ее.
🖤 8. Доверие (отказ от управления, основанного на страхе).
Для улучшения процессов важно рассматривать любые идеи. Однако часто взаимодействие построено таким образом, что сотрудник испытывает страх перед руководителем, особенно если в команде активно используется система штрафов. Например, член команды может предложить какие-либо меры по улучшению и ускорению процессов, так как он работает над техническими задачами каждый день, в отличие от руководителя. Не следует отвергать его предложения, ведь они могут сократить издержки и принести огромную пользу для команды.
🔓 9. Разрушайте барьеры между подразделениями.
Люди из различных подразделений — аналитики, разработчики, тестировщики, менеджеры должны работать в командах, чтобы устранять проблемы, которые возникают в процессе разработки ПО.
🔦 10. Откажитесь пот пустых призывов, требующих бездефектной работы, но не сообщающих о методах её достижения.
Такие призывы вызывают лишь брезгливое отношение; основная масса проблем низкого качества и производительности связана с системой, и поэтому их решения находятся за пределами рядовых сотрудников.
🧮 11. Откажитесь от количественных оценок работы.
Если система, в которой вы работаете, стабильна, нет нужны определять цель повышения производительности и качества в цифрах — все равно вы получите только то, что может дать сама система. Если система нестабильна, то снова нет смысла определять цель в цифрах, поскольку нет возможности узнать, что выдаст система — о ее возможностях нельзя сказать. А значит, запланированная цель, скорее всего, не будет достигнута. Управление, которое основано на количественных показателя, — это попытка управлять, не зная, что нужно сделать.
👨🏻💻 12. Устраните барьеры, которые не позволяют людям гордиться своей квалификацией.
Это предполагает, помимо всего прочего, отказ от ежегодных аттестаций и методов управления целями. И снова обязанности менеджеров должны быть перенесены с достижений чисто количественных показателей — на качественные.
🧠 13. Поощряйте стремление к образованию и самосовершенствование сотрудников. Вызовите у сотрудника интерес к самосовершенствованию. Например, нельзя игнорировать стремление сотрудника посетить какие-то конференции. Обмен опытом пойдет на пользу не только сотруднику, но и компании.
🦾 14. Вовлеченность высшего руководства и его действия. Четко установите обязанности высшего руководства в сфере качества. Создайте структуру, которая будет ежедневно давать импульс для продвижения рассмотренным выше тринадцати принципам, и действуйте, чтобы осуществить преобразование. Поддержки здесь недостаточно, нужны конкретные действия.
#rdclr_QA #product
В целом, рекомендую к прочтению его полную книгу «Выход из кризиса». Она поможет в освоении новой философии менеджмента через отказ от традиционных методов. Но для скорости продолжаю (и заканчиваю) выжимку принципов, которые вынес из ее.
🖤 8. Доверие (отказ от управления, основанного на страхе).
Для улучшения процессов важно рассматривать любые идеи. Однако часто взаимодействие построено таким образом, что сотрудник испытывает страх перед руководителем, особенно если в команде активно используется система штрафов. Например, член команды может предложить какие-либо меры по улучшению и ускорению процессов, так как он работает над техническими задачами каждый день, в отличие от руководителя. Не следует отвергать его предложения, ведь они могут сократить издержки и принести огромную пользу для команды.
🔓 9. Разрушайте барьеры между подразделениями.
Люди из различных подразделений — аналитики, разработчики, тестировщики, менеджеры должны работать в командах, чтобы устранять проблемы, которые возникают в процессе разработки ПО.
🔦 10. Откажитесь пот пустых призывов, требующих бездефектной работы, но не сообщающих о методах её достижения.
Такие призывы вызывают лишь брезгливое отношение; основная масса проблем низкого качества и производительности связана с системой, и поэтому их решения находятся за пределами рядовых сотрудников.
🧮 11. Откажитесь от количественных оценок работы.
Если система, в которой вы работаете, стабильна, нет нужны определять цель повышения производительности и качества в цифрах — все равно вы получите только то, что может дать сама система. Если система нестабильна, то снова нет смысла определять цель в цифрах, поскольку нет возможности узнать, что выдаст система — о ее возможностях нельзя сказать. А значит, запланированная цель, скорее всего, не будет достигнута. Управление, которое основано на количественных показателя, — это попытка управлять, не зная, что нужно сделать.
👨🏻💻 12. Устраните барьеры, которые не позволяют людям гордиться своей квалификацией.
Это предполагает, помимо всего прочего, отказ от ежегодных аттестаций и методов управления целями. И снова обязанности менеджеров должны быть перенесены с достижений чисто количественных показателей — на качественные.
🧠 13. Поощряйте стремление к образованию и самосовершенствование сотрудников. Вызовите у сотрудника интерес к самосовершенствованию. Например, нельзя игнорировать стремление сотрудника посетить какие-то конференции. Обмен опытом пойдет на пользу не только сотруднику, но и компании.
🦾 14. Вовлеченность высшего руководства и его действия. Четко установите обязанности высшего руководства в сфере качества. Создайте структуру, которая будет ежедневно давать импульс для продвижения рассмотренным выше тринадцати принципам, и действуйте, чтобы осуществить преобразование. Поддержки здесь недостаточно, нужны конкретные действия.
#rdclr_QA #product
«5 почему». Поиск причин проблемы.
Метод «5 почему» заключается в том, чтобы докопаться до сути проблемы. Нужно задать вопрос, начав со слова «почему», и получить ответ, после чего переформулировать полученный ответ в новый вопрос, добавив к нему «почему».
🧶 Пример:
1. Почему мы не отправили новостную рассылку?
— Потому что релиз не был сделан вовремя.
2. Почему релиз не был сделан вовремя?
— Потому что разработчики все еще работают над новыми фичами.
3. Почему они все еще работают над новыми фичами?
— Один из новых разработчиков не знает регламентов.
4. Почему новый разработчик не знает регламентов?
— Он не был обучен должным образом.
5. Почему он не был обучен должным образом?
— Потому что его руководитель считает, что новых сотрудников не нужно тщательно обучать, и они должны учиться во время работы.
Можно заметить, что первоначальная причина проблемы оказалось совершенно отличной от той, которая предполагалась изначально. Кроме того, очевидно, что проблема носит не технический характер, а процессуальный. Это типично, потому что мы часто сосредотачиваемся на продуктовой части проблемы, пренебрегая человеческим фактором.
Таким образом, метод «5 почему» направлен на глубокое изучение определенной проблемы до тех пор, пока не будет найдена настоящая причина.
Главная особенность и преимущества метода — простота. Пять — это среднее число, достаточное для получения ответа. Но у вас может быть и три, и двадцать вопросов.
#rdclr_QA #product
Метод «5 почему» заключается в том, чтобы докопаться до сути проблемы. Нужно задать вопрос, начав со слова «почему», и получить ответ, после чего переформулировать полученный ответ в новый вопрос, добавив к нему «почему».
🧶 Пример:
1. Почему мы не отправили новостную рассылку?
— Потому что релиз не был сделан вовремя.
2. Почему релиз не был сделан вовремя?
— Потому что разработчики все еще работают над новыми фичами.
3. Почему они все еще работают над новыми фичами?
— Один из новых разработчиков не знает регламентов.
4. Почему новый разработчик не знает регламентов?
— Он не был обучен должным образом.
5. Почему он не был обучен должным образом?
— Потому что его руководитель считает, что новых сотрудников не нужно тщательно обучать, и они должны учиться во время работы.
Можно заметить, что первоначальная причина проблемы оказалось совершенно отличной от той, которая предполагалась изначально. Кроме того, очевидно, что проблема носит не технический характер, а процессуальный. Это типично, потому что мы часто сосредотачиваемся на продуктовой части проблемы, пренебрегая человеческим фактором.
Таким образом, метод «5 почему» направлен на глубокое изучение определенной проблемы до тех пор, пока не будет найдена настоящая причина.
Главная особенность и преимущества метода — простота. Пять — это среднее число, достаточное для получения ответа. Но у вас может быть и три, и двадцать вопросов.
#rdclr_QA #product
Разбираем софт для командной разработки
Любой большой проект — это не только идея и код, который эту идею реализует. Проект — это команда, а команда — это постоянное общение и софт, помогающий быть на одной волне 🏄♂️
🧬Система контроля версий. Де-факто индустриальный стандарт — это Git, но можно встретить компании и проекты, которые используют Mercurial, SVN и более экзотические штуки. Чистый гит не очень удобен, поэтому фактически в разработке используют готовые системы управления репозиториями: gitlab, github, bitbucket.
📌 Вторая необходимая составляющая — трекер задач. Это место, где описываются и распределяются задачи, планируются спринты, отслеживается прогресс. Самое популярное решение здесь Jira, но есть и другие, например, youtrack или trello.
🗒 База знаний проекта — проектная вики, где документируются принятые решения, идеи, юзкейсы, архитектурные диаграммы. Из примеров — confluence, outline и, как ни странно, система README файлов.
🛠 CI/CD движки, собирающие из вашего кода докер образы, библиотеки, пакеты и разворачивающие их на окружениях. Jenkins, Teamcity, Gitlab pipelines, Bitbucket pipelines.
🎁 Хранилища артефактов. Npm, maven репозитории, регистры Docker образов. Из того, что первое приходит в голову — это Artefactory, Verdaccio, Nexus.
💣 Многие вендоры предлагают коробочные решения, объединяющие все или часть нужного функционала. Как правило, такие решения имеют очень хорошие интеграции: по каждой задаче можно увидеть все изменения кода, тесты, собранные артефакты, связанные документы. Это очень удобно для навигации и аналитики. Примеры — Atlassian Suite (Jira, Confluence, Bitbucket), Azure DevOps. Недавно появился еще один игрок — Jetbrains Space, который мы используем с лета в пилотном режиме на части проектов.
#rdclr_frontend #rdclr_backend #rdclr_QA
Любой большой проект — это не только идея и код, который эту идею реализует. Проект — это команда, а команда — это постоянное общение и софт, помогающий быть на одной волне 🏄♂️
🧬Система контроля версий. Де-факто индустриальный стандарт — это Git, но можно встретить компании и проекты, которые используют Mercurial, SVN и более экзотические штуки. Чистый гит не очень удобен, поэтому фактически в разработке используют готовые системы управления репозиториями: gitlab, github, bitbucket.
📌 Вторая необходимая составляющая — трекер задач. Это место, где описываются и распределяются задачи, планируются спринты, отслеживается прогресс. Самое популярное решение здесь Jira, но есть и другие, например, youtrack или trello.
🗒 База знаний проекта — проектная вики, где документируются принятые решения, идеи, юзкейсы, архитектурные диаграммы. Из примеров — confluence, outline и, как ни странно, система README файлов.
🛠 CI/CD движки, собирающие из вашего кода докер образы, библиотеки, пакеты и разворачивающие их на окружениях. Jenkins, Teamcity, Gitlab pipelines, Bitbucket pipelines.
🎁 Хранилища артефактов. Npm, maven репозитории, регистры Docker образов. Из того, что первое приходит в голову — это Artefactory, Verdaccio, Nexus.
💣 Многие вендоры предлагают коробочные решения, объединяющие все или часть нужного функционала. Как правило, такие решения имеют очень хорошие интеграции: по каждой задаче можно увидеть все изменения кода, тесты, собранные артефакты, связанные документы. Это очень удобно для навигации и аналитики. Примеры — Atlassian Suite (Jira, Confluence, Bitbucket), Azure DevOps. Недавно появился еще один игрок — Jetbrains Space, который мы используем с лета в пилотном режиме на части проектов.
#rdclr_frontend #rdclr_backend #rdclr_QA
📌 Эвристики и мнемоники в тестировании: что это и как применять — первая тема
С самого детства все мы запоминали цвета радуги с помощью фразы «Каждый охотник желает знать, где сидит фазан». Как оказалось, это самая известная нам мнемоника. В тестировании они также применяются. Так что это такое: эвристика и мнемоника?
Простыми словами, мнемоника — полезный инструмент, который помогает запомнить различные схемы разнообразных моделей тестирования, которые в будущем можно использовать на практике. А эвристика — специальный алгоритм, помогающий эффективно ориентироваться в пространстве при решении какой-то определенной задачи. Существует разнообразное количество инструментов и технологий мнемоники, которые помогают не упустить важные моменты при тестировании. Рассмотрим некоторые.
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
Тестирование 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
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