🚀 Как разрабатывают API в Slack
На днях вышла бомбическая статья в инженерном блоге компании Slack:
https://slack.engineering/how-we-design-our-apis-at-slack/
После прочтения захотелось выделить главные мысли:
1⃣ Создавайте API методы, которые решают одну проблему, а не несколько одновременно (старайтесь возвращать ограниченное количество объектов, разбейте на пагинацию)
2⃣ Упростите работу с API
Например, добавьте возможность отправить запрос прямо с браузера, добавьте сниппеты кода.
Всегда спрашивайте себя, что важно для вашей платформы, которую вы делаете.
3⃣ Создайте правила именования методов, переменных и т.д.
4⃣ Возвращайте понятные и подробные сообщения об ошибках (например, со ссылками на документацию и т.д.)
5⃣ Делайте эндпоинты перформансными и масштабируемыми
— пагинация больших коллекций
— не вкладывайте одни большие коллекции в другие
— добавьте ограничение на частоту запросов
Если API работает «достаточно хорошо» для вас — это не значит, что этого достаточно для остальных. Часть удовольствия от использования API заключается в том, что мы никогда не знаем, как другой разработчик собирается его использовать. И всё же вам всё ещё предстоит предвидеть множество возможностей, о которых вы можете не знать.
6⃣ Избегайте ломающих совместимость изменений
Или другими словами — то, что работало вчера, должно работать и сегодня.
Процесс проектирования API:
1) написать API спецификацию
2) провести внутреннее ревью API в специальном канале
3) собрать ранние отзывы от партнёров
4) провести бета-тестирование
#новости #статьи
На днях вышла бомбическая статья в инженерном блоге компании Slack:
https://slack.engineering/how-we-design-our-apis-at-slack/
После прочтения захотелось выделить главные мысли:
1⃣ Создавайте API методы, которые решают одну проблему, а не несколько одновременно (старайтесь возвращать ограниченное количество объектов, разбейте на пагинацию)
2⃣ Упростите работу с API
Например, добавьте возможность отправить запрос прямо с браузера, добавьте сниппеты кода.
Всегда спрашивайте себя, что важно для вашей платформы, которую вы делаете.
3⃣ Создайте правила именования методов, переменных и т.д.
4⃣ Возвращайте понятные и подробные сообщения об ошибках (например, со ссылками на документацию и т.д.)
5⃣ Делайте эндпоинты перформансными и масштабируемыми
— пагинация больших коллекций
— не вкладывайте одни большие коллекции в другие
— добавьте ограничение на частоту запросов
Если API работает «достаточно хорошо» для вас — это не значит, что этого достаточно для остальных. Часть удовольствия от использования API заключается в том, что мы никогда не знаем, как другой разработчик собирается его использовать. И всё же вам всё ещё предстоит предвидеть множество возможностей, о которых вы можете не знать.
6⃣ Избегайте ломающих совместимость изменений
Или другими словами — то, что работало вчера, должно работать и сегодня.
Процесс проектирования API:
1) написать API спецификацию
2) провести внутреннее ревью API в специальном канале
3) собрать ранние отзывы от партнёров
4) провести бета-тестирование
#новости #статьи
Engineering at Slack
How We Design Our APIs at Slack - Engineering at Slack
More than five years ago, we launched the Slack Platform, giving developers an easy way to build apps in Slack and publish them in our App Directory. Today, millions of users bring their work into Slack, and those apps built by over 885,000 active developers…
Как автоматизируют в Твиттере
Небольшое интервью с Kalisha Campbell, Software Engineer из Твиттера:
https://medium.com/@MHendersog/how-twitter-does-automated-testing-e27bce0b947e
В статье поднимается несколько интересных тем. Например, что не все правильно понимают концепцию Accessibility. Приложение должно быть доступным не только для людей с ограниченными возможностями, но и также для людей, которые пользуются разными браузерами. В статье рекомендуют тестировать в Safari и в Firefox 👀
Ещё одним интересным моментом я бы отметил, что они предпочитают тулы, которые не требуют написания кода, например, Postman и Endtest.
Несколько пунктов, как проверить, что с вашими автотестами всё хорошо:
— автотесты запускаются где-то на удалённом сервере или в облаке
— используется параллельный запуск тестов
— полная регрессия занимает меньше 15 минут
— есть интеграция с CI/CD
— тесты запускаются автоматически
— результаты генерируются автоматически
#статьи #автоматизация
Небольшое интервью с Kalisha Campbell, Software Engineer из Твиттера:
https://medium.com/@MHendersog/how-twitter-does-automated-testing-e27bce0b947e
В статье поднимается несколько интересных тем. Например, что не все правильно понимают концепцию Accessibility. Приложение должно быть доступным не только для людей с ограниченными возможностями, но и также для людей, которые пользуются разными браузерами. В статье рекомендуют тестировать в Safari и в Firefox 👀
Ещё одним интересным моментом я бы отметил, что они предпочитают тулы, которые не требуют написания кода, например, Postman и Endtest.
Несколько пунктов, как проверить, что с вашими автотестами всё хорошо:
— автотесты запускаются где-то на удалённом сервере или в облаке
— используется параллельный запуск тестов
— полная регрессия занимает меньше 15 минут
— есть интеграция с CI/CD
— тесты запускаются автоматически
— результаты генерируются автоматически
#статьи #автоматизация
📘 Предотвращаем появление багов на ранних этапах
https://telegra.ph/Predotvrashchenie-bagov-na-rannih-ehtapah-12-06
#статьи #qa
https://telegra.ph/Predotvrashchenie-bagov-na-rannih-ehtapah-12-06
#статьи #qa
Telegraph
Предотвращаем появление багов на ранних этапах
Сегодня рассмотрим способы по предотвращению появления багов на ранних стадиях. Во время ревью фичи Если у фичи есть дизайн, то можно посмотреть его как можно раньше, чтобы подготовить вопросы/предложения. Список вспомогательных вопросов: — как будут обрабатываться…
Test as Text Approach в IntelliJ IDEA
Недавно IntelliJ IDEA добавила нативную поддержку для подхода "test cases as code":
https://blog.jetbrains.com/qa/2021/08/test-as-text-approach-in-intellij-idea/
Данный подход позволяет держать тест-кейсы в репозитории, рядом с кодом приложения.
В релизе 2021.3 добавили поддержку многоуровневого запуска тестов, а также возможность использования общих шагов. К слову, в этом же релизе добавили возможность добавления таблицы в Markdown.
Кажется, что почти всё сделано и готово к использованию. Было бы здорово иметь интеграции не только с TestRail, а также с Zephyr Squad, Zephyr Scale, Xray.
На ютреке JetBrains уже есть эти задачи, думаю скоро реализуют👍
#ide #intellijidea #idea
Недавно IntelliJ IDEA добавила нативную поддержку для подхода "test cases as code":
https://blog.jetbrains.com/qa/2021/08/test-as-text-approach-in-intellij-idea/
Данный подход позволяет держать тест-кейсы в репозитории, рядом с кодом приложения.
В релизе 2021.3 добавили поддержку многоуровневого запуска тестов, а также возможность использования общих шагов. К слову, в этом же релизе добавили возможность добавления таблицы в Markdown.
Кажется, что почти всё сделано и готово к использованию. Было бы здорово иметь интеграции не только с TestRail, а также с Zephyr Squad, Zephyr Scale, Xray.
На ютреке JetBrains уже есть эти задачи, думаю скоро реализуют👍
#ide #intellijidea #idea
The JetBrains Blog
Test as Text Approach in IntelliJ IDEA | The Quality Assurance Blog
In this article, we’ll give an overview of how IntelliJ IDEA can help Agile teams manage test cases and keep them synchronized with automated tests and feature branches. The approach that we follow co
#истории #opencv #хакатон
Как однажды я в CV 👁🗨 хакатоне участвовал
Весной я с коллегой (кстати, он тоже не разработчик) решили поучаствовать в хакатоне по компьютерному зрению iVision 2021. У меня опыта в этой сфере не было, поэтому я готовился изучать что-то новое на предстоящем мероприятии 💫
В нашей категории была дана задача на распознавание свободных парковочных мест 🚗 Организаторы дали видеопотоки нескольких камер и нужно было показывать свободные места в live-режиме 🖥
На втором этапе, на который мы прошли и это было уже достижение, мы дорабатывали раннее созданное нечто 😂 Теперь надо было стать фронтенд-разработчиком и создать веб-приложение в виде карты 🗺, на которой можно наглядно увидеть свободные места, а также бота 🤖 для Telegram, оповещающего о наличии свободного места на конкретной парковке.
Начали думать и искать хотя бы какие-то зацепки, что и как делать. Что-то находилось, но оно не совсем то и не работало в нашем случае 👀 Посмотрели как работает пример с Хабра — работал он откровенно криво и долго.
Затем попробовали библиотеку ImageAI, которая давала уже хоть какие-то результаты по распознаванию автомобилей, но даже она с какой-то большой погрешностью еле-еле могла различить автомобиль 🚗 на некоторых камерах из-за угла наклона. Количество автомобилей сложно было даже глазами посчитать, особенно вдалеке.
Исходя из этого было решено дообучать модель под наши условия 🚴♂️
Следующий этап выборки и разметки данных занимал от 6 до 12 часов и проделывался дважды из-за размеров картинок, влияющих на скорость обработки.
Получилась на время работающая модель с плюс-минус хорошим результатом 🎯
И ещё это дело куда-то задеплоить надо было, тут пришлось стать девопсом 🧙♂️
Я перепробовал 3 сервиса для деплоя: Heroku, Google App Engine и DigitalOcean.
С Heroku было сложно разобраться из-за внутреннего движка и непонятных ошибок, хотя там есть отдельный план для AI/ML приложений, но он платный разумеется.
Google App Engine отказался обрабатывать долгие запросы, такое он увы не поддерживает 🤷♂️
Спасибо DigitalOcean, что не тупил и всё поднял с первого раза 👌 Но ресурсов это съедало много.
Но вскоре нас поджидал главный подвох 🗿
На финальном этапе наша модель поплыла 🚣♀️, потому что растаял мартовский снег, а дело было в апреле уже.
По сути цель задания осталась та же, просто надо было всё красиво оформить в виде веб-странички с картой, на которой видны парковки и свободные места. А с помощью телеграм бота оповещать 📣 о наличии свободного места на определённой парковке.
Надо было что-то быстро создать, поэтому всё было написано в HTML файле, юзая jQuery, и даже ни капли не стыдно, зато что-то работало и удалось разобраться с Google Maps 📈
Telegram бот на Python вполне свои функции выполнял: подписался на парковку, получил уведомление, побежал парковать машину 👍
Только вот с точностью была проблема, модель подвела 🤔
Но несмотря на сложности, это был интересный челлендж 🙌 Мне понравилось пробовать разные решения с их плюсами и минусами, тестировать работу сервиса и получать наглядный результат. Разбивать задачи на подзадачи 🧩 Демонстрировать ход решения в Jupyter Notebook 📝 Вспоминать Python и JavaScript 😊
Извлёк некоторые уроки для себя на будущее, что надо больше изучать и понимать работу алгоритмов, в каких случаях лучше применять. И улучшать работу с фронтенд фреймворками 📚
Как однажды я в CV 👁🗨 хакатоне участвовал
Весной я с коллегой (кстати, он тоже не разработчик) решили поучаствовать в хакатоне по компьютерному зрению iVision 2021. У меня опыта в этой сфере не было, поэтому я готовился изучать что-то новое на предстоящем мероприятии 💫
В нашей категории была дана задача на распознавание свободных парковочных мест 🚗 Организаторы дали видеопотоки нескольких камер и нужно было показывать свободные места в live-режиме 🖥
На втором этапе, на который мы прошли и это было уже достижение, мы дорабатывали раннее созданное нечто 😂 Теперь надо было стать фронтенд-разработчиком и создать веб-приложение в виде карты 🗺, на которой можно наглядно увидеть свободные места, а также бота 🤖 для Telegram, оповещающего о наличии свободного места на конкретной парковке.
Начали думать и искать хотя бы какие-то зацепки, что и как делать. Что-то находилось, но оно не совсем то и не работало в нашем случае 👀 Посмотрели как работает пример с Хабра — работал он откровенно криво и долго.
Затем попробовали библиотеку ImageAI, которая давала уже хоть какие-то результаты по распознаванию автомобилей, но даже она с какой-то большой погрешностью еле-еле могла различить автомобиль 🚗 на некоторых камерах из-за угла наклона. Количество автомобилей сложно было даже глазами посчитать, особенно вдалеке.
Исходя из этого было решено дообучать модель под наши условия 🚴♂️
Следующий этап выборки и разметки данных занимал от 6 до 12 часов и проделывался дважды из-за размеров картинок, влияющих на скорость обработки.
Получилась на время работающая модель с плюс-минус хорошим результатом 🎯
И ещё это дело куда-то задеплоить надо было, тут пришлось стать девопсом 🧙♂️
Я перепробовал 3 сервиса для деплоя: Heroku, Google App Engine и DigitalOcean.
С Heroku было сложно разобраться из-за внутреннего движка и непонятных ошибок, хотя там есть отдельный план для AI/ML приложений, но он платный разумеется.
Google App Engine отказался обрабатывать долгие запросы, такое он увы не поддерживает 🤷♂️
Спасибо DigitalOcean, что не тупил и всё поднял с первого раза 👌 Но ресурсов это съедало много.
Но вскоре нас поджидал главный подвох 🗿
На финальном этапе наша модель поплыла 🚣♀️, потому что растаял мартовский снег, а дело было в апреле уже.
По сути цель задания осталась та же, просто надо было всё красиво оформить в виде веб-странички с картой, на которой видны парковки и свободные места. А с помощью телеграм бота оповещать 📣 о наличии свободного места на определённой парковке.
Надо было что-то быстро создать, поэтому всё было написано в HTML файле, юзая jQuery, и даже ни капли не стыдно, зато что-то работало и удалось разобраться с Google Maps 📈
Telegram бот на Python вполне свои функции выполнял: подписался на парковку, получил уведомление, побежал парковать машину 👍
Только вот с точностью была проблема, модель подвела 🤔
Но несмотря на сложности, это был интересный челлендж 🙌 Мне понравилось пробовать разные решения с их плюсами и минусами, тестировать работу сервиса и получать наглядный результат. Разбивать задачи на подзадачи 🧩 Демонстрировать ход решения в Jupyter Notebook 📝 Вспоминать Python и JavaScript 😊
Извлёк некоторые уроки для себя на будущее, что надо больше изучать и понимать работу алгоритмов, в каких случаях лучше применять. И улучшать работу с фронтенд фреймворками 📚
📊 Google Testing Blog: Now You're Thinking With Functions
#новости
В новой небольшой статье от Google автор демонстрирует преимущества функций высшего порядка (это такая функция, которая принимает функцию как аргумент или возвращает функцию в виде выходного значения) в JavaScript'е, например:
* уменьшение дублирования кода
* более простой и короткий код
* понятное назначение кода для других
https://testing.googleblog.com/2022/02/code-health-now-youre-thinking-with.html
#новости
В новой небольшой статье от Google автор демонстрирует преимущества функций высшего порядка (это такая функция, которая принимает функцию как аргумент или возвращает функцию в виде выходного значения) в JavaScript'е, например:
* уменьшение дублирования кода
* более простой и короткий код
* понятное назначение кода для других
https://testing.googleblog.com/2022/02/code-health-now-youre-thinking-with.html
Google Testing Blog
Code Health: Now You're Thinking With Functions
This is another post in our Code Health series. A version of this post originally appeared in Google bathrooms worldwide as a Google Testin...
#автоматизация #автотесты
🚀 Готовим приложение для автоматизации тестирования
Прежде чем приступить к автоматизации тестирования необходимо проанализировать приложение. Чем больше приложение готово, тем меньше проблем будет при разработке автотестов, анализе результатов и т.д.
Ниже перечислены основные пункты, на которые стоит обратить внимание:
0) Готовность приложения
Бывает так, что автоматизируют слишком рано, и в итоге потом нужно всё переписывать. Готовы ли основные фичи? Не поменяется ли логика через неделю? Не поменяется ли вёрстка?
1) Доступность документации
Swagger, Storybook и другие.
Для API тестирования, для создания тестовых данных потребуется документация.
На основе неё можно даже генерировать тесты.
2) Расставляем data-* атрибуты
Для уменьшения количества падающих тестов в случае изменений на фронте, а также для более удобного нахождения элементов в DOM, необходимы надёжные локаторы. Менее подвержены изменениям именно data-* атрибуты у элемента, например, data-test="element".
3) По возможности отключаем все анимации и капчу на время теста
Есть анимация и тест опять "моргнул"? Хорошей практикой является полное отключение подобных анимаций, которые мешают кликам проходить.
4) Параллельный запуск
Рано или поздно придёт время уменьшать время прогона путём параллелизации тестов. Сможет ли приложение поддерживать несколько потоков одновременно? Запустите тесты в парочку потоков и проверьте, не падает ли приложение, не происходит ли ранее не обнаруженных замедлений.
5) Third-party зависимости
Для некоторых случаев автоматизации требуется замокать third-party зависимости, на которые мы никак не можем повлиять, например, стороннее API.
6) Логи
Как вы будете анализировать и разбирать результаты прогона автотестов? У приложения должны быть понятные и доступные логи, в идеале в одном месте и чтоб их можно было подцепить к нужному тесту.
7) Время ответа приложения
На глобальном уровне обычно выставляется таймаут для всех ожиданий в тесте. Какой он будет — решать вам. Время ответа не должно будет превышать заданный таймаут, иначе тесты будут постоянно падать, а вы постоянно разбираться. Надо выяснить в чём именно причина долгих ответов и решить этот вопрос.
🚀 Готовим приложение для автоматизации тестирования
Прежде чем приступить к автоматизации тестирования необходимо проанализировать приложение. Чем больше приложение готово, тем меньше проблем будет при разработке автотестов, анализе результатов и т.д.
Ниже перечислены основные пункты, на которые стоит обратить внимание:
0) Готовность приложения
Бывает так, что автоматизируют слишком рано, и в итоге потом нужно всё переписывать. Готовы ли основные фичи? Не поменяется ли логика через неделю? Не поменяется ли вёрстка?
1) Доступность документации
Swagger, Storybook и другие.
Для API тестирования, для создания тестовых данных потребуется документация.
На основе неё можно даже генерировать тесты.
2) Расставляем data-* атрибуты
Для уменьшения количества падающих тестов в случае изменений на фронте, а также для более удобного нахождения элементов в DOM, необходимы надёжные локаторы. Менее подвержены изменениям именно data-* атрибуты у элемента, например, data-test="element".
3) По возможности отключаем все анимации и капчу на время теста
Есть анимация и тест опять "моргнул"? Хорошей практикой является полное отключение подобных анимаций, которые мешают кликам проходить.
4) Параллельный запуск
Рано или поздно придёт время уменьшать время прогона путём параллелизации тестов. Сможет ли приложение поддерживать несколько потоков одновременно? Запустите тесты в парочку потоков и проверьте, не падает ли приложение, не происходит ли ранее не обнаруженных замедлений.
5) Third-party зависимости
Для некоторых случаев автоматизации требуется замокать third-party зависимости, на которые мы никак не можем повлиять, например, стороннее API.
6) Логи
Как вы будете анализировать и разбирать результаты прогона автотестов? У приложения должны быть понятные и доступные логи, в идеале в одном месте и чтоб их можно было подцепить к нужному тесту.
7) Время ответа приложения
На глобальном уровне обычно выставляется таймаут для всех ожиданий в тесте. Какой он будет — решать вам. Время ответа не должно будет превышать заданный таймаут, иначе тесты будут постоянно падать, а вы постоянно разбираться. Надо выяснить в чём именно причина долгих ответов и решить этот вопрос.
#конференции
Вот и прошла первая конференция)
https://vk.com/natlexconf
Спасибо тем, кто пришёл❤️
Выкладываю саму презентацию и полезные ссылки:
https://www.rstqb.org/ru/istqb-downloads.html https://www.selenium.dev/history/
https://developer.chrome.com/blog/webdriver-bidi/
https://w3c.github.io/webdriver-bidi
https://testguild.com/testops/
https://cleverics.ru/digital/2020/07/sdvig-testirovaniya-vpravo-vozniknovenie-testops/
https://habr.com/ru/company/oleg-bunin/blog/593333/
https://habr.com/ru/post/358950/
https://t.me/qa_relia/24
https://selenide.org/
https://medium.com/@Mayursuryanarayan/testops-ed3afa323d99
Вот и прошла первая конференция)
https://vk.com/natlexconf
Спасибо тем, кто пришёл❤️
Выкладываю саму презентацию и полезные ссылки:
https://www.rstqb.org/ru/istqb-downloads.html https://www.selenium.dev/history/
https://developer.chrome.com/blog/webdriver-bidi/
https://w3c.github.io/webdriver-bidi
https://testguild.com/testops/
https://cleverics.ru/digital/2020/07/sdvig-testirovaniya-vpravo-vozniknovenie-testops/
https://habr.com/ru/company/oleg-bunin/blog/593333/
https://habr.com/ru/post/358950/
https://t.me/qa_relia/24
https://selenide.org/
https://medium.com/@Mayursuryanarayan/testops-ed3afa323d99
ВКонтакте
NATLEX CONF
Конференция NATLEX CONF в Петрозаводске Когда: 29 апреля (пятница) 18:00 Где: Питер Инн, 6-ой этаж, пл. Гагарина, 1 Стоимость: бесплатно Для кого: Конференция будет интересна front-end, back-end разработчикам, тестировщикам, менеджерам проектов, Scrum-мастерам…
#qa #roadmap
🗺 Полезные роадмапы для QA
Собрал вместе накопившиеся ссылки на роадмапы, которые будут полезны всем, особенно если возникают вопросы, что изучать и т.п.
🔹Роадмапа для Software Quality Assurance Engineer и Quality Automation Engineer:
https://github.com/fityanos/awesome-quality-assurance-roadmap
🔹Роадмапа для SDET (Software Development Engineer in Test):
https://github.com/testleaf-software/roadmap.testleaf.in
🔹База знаний и роадмапа для технического лида, подходит и для QA тоже:
https://github.com/tlbootcamp/tlroadmap
🔹Роадмапа QA от Mail:
https://miro.com/app/board/o9J_lXUgVuQ=/
🔹Роадмапа Quality Engineer:
https://link.medium.com/WQ2cxeOaMpb
🔹Роадмапа тестировщика:
https://drive.google.com/file/d/1gl9YKwnaokcJnMMOcpfxoB9Hi4Ce_EfR/view
🗺 Полезные роадмапы для QA
Собрал вместе накопившиеся ссылки на роадмапы, которые будут полезны всем, особенно если возникают вопросы, что изучать и т.п.
🔹Роадмапа для Software Quality Assurance Engineer и Quality Automation Engineer:
https://github.com/fityanos/awesome-quality-assurance-roadmap
🔹Роадмапа для SDET (Software Development Engineer in Test):
https://github.com/testleaf-software/roadmap.testleaf.in
🔹База знаний и роадмапа для технического лида, подходит и для QA тоже:
https://github.com/tlbootcamp/tlroadmap
🔹Роадмапа QA от Mail:
https://miro.com/app/board/o9J_lXUgVuQ=/
🔹Роадмапа Quality Engineer:
https://link.medium.com/WQ2cxeOaMpb
🔹Роадмапа тестировщика:
https://drive.google.com/file/d/1gl9YKwnaokcJnMMOcpfxoB9Hi4Ce_EfR/view
#статьи
✅ Как правильно (не) использовать тестировщиков
https://habr.com/ru/company/jugru/blog/661623/
Недавно наткнулся на текстовую статью от создателя Allure Report’а, смотрел этот доклад в записи.
Главные поинты:
- Автотесты пишутся на нативных языках в том же репозитории.
- Тесты запускаются при сборке.
- Автоматизация выше документации: нам не нужны ручные описания, они быстро устаревают.
- Команды межфункциональны: люди умеют и код писать, и фреймворк подправить, разработка интересуется тестированием и так далее.
- Инфраструктура общая: тестировщики тоже несут ответственность за тестовое окружение.
Да, в целом это круто, если есть такая команда и всё работает как часы.
Скорее всего основной проблемой будет написание нативных тестов в одном репозитории, а также запуск автотестов на каждый PR (MR). Это не делается по щелчку пальцев, это требует усилий всей команды.
Если вы используете Allure Report / Allure TestOps, то по сути вы уже получаете live-документацию. С этим особо нет проблем.
Командное развитие - в принципе одно из важных направлений, тут нужно с самого начала прививать хорошие практики, проходить обучение, просто учиться у коллег или у других людей.
❓И вопрос ко всем, слышали ли вообще про данный подход? Или может быть вы уже стараетесь приблизиться к идеальной команде?😊
✅ Как правильно (не) использовать тестировщиков
https://habr.com/ru/company/jugru/blog/661623/
Недавно наткнулся на текстовую статью от создателя Allure Report’а, смотрел этот доклад в записи.
Главные поинты:
- Автотесты пишутся на нативных языках в том же репозитории.
- Тесты запускаются при сборке.
- Автоматизация выше документации: нам не нужны ручные описания, они быстро устаревают.
- Команды межфункциональны: люди умеют и код писать, и фреймворк подправить, разработка интересуется тестированием и так далее.
- Инфраструктура общая: тестировщики тоже несут ответственность за тестовое окружение.
Да, в целом это круто, если есть такая команда и всё работает как часы.
Скорее всего основной проблемой будет написание нативных тестов в одном репозитории, а также запуск автотестов на каждый PR (MR). Это не делается по щелчку пальцев, это требует усилий всей команды.
Если вы используете Allure Report / Allure TestOps, то по сути вы уже получаете live-документацию. С этим особо нет проблем.
Командное развитие - в принципе одно из важных направлений, тут нужно с самого начала прививать хорошие практики, проходить обучение, просто учиться у коллег или у других людей.
❓И вопрос ко всем, слышали ли вообще про данный подход? Или может быть вы уже стараетесь приблизиться к идеальной команде?😊
Хабр
Как правильно (не) использовать тестировщиков
Как быть, когда вокруг вроде бы девопсы, аджайлы и скрамы, но разработка и тестирование по-прежнему не живут в одном пайплайне душа в душу? Из-за того, что необходимо преодолевать эту стену и находить...
⏳Динамические среды для E2E тестов
#автоматизация
При встраивании автотестов в пайплайн часто возникает вопрос, а на каком конкретном инстансе (стенде, сайте, контуре и т.п.) будут запускаться наши автотесты. Как вариант использовать статические инстансы, но в этом подходе есть свои минусы, например, проблемы с тестовыми данными, перформансом и т.д.
Дабы избежать проблем с этим и были придуманы эфемерные или динамические среды. В итоге при реализации данного подхода мы получаем более стабильную среду для запуска тестов, распараллеливание на несколько сред, экономию средств и т.п.
Реализация зависит уже от самого приложения. Если ваше приложение уже как-то деплоится в облаке, используя подход "инфраструктура как код", то в принципе больших проблем быть не должно.
Про проблемы статичных сред: https://pipelinedriven.org/article/the-four-biggest-issues-with-having-static-environments
Более подробно про данный подход:
https://ephemeralenvironments.io/
https://pipelinedriven.org/article/ephemeral-environment-why-what-how-and-where
#автоматизация
При встраивании автотестов в пайплайн часто возникает вопрос, а на каком конкретном инстансе (стенде, сайте, контуре и т.п.) будут запускаться наши автотесты. Как вариант использовать статические инстансы, но в этом подходе есть свои минусы, например, проблемы с тестовыми данными, перформансом и т.д.
Дабы избежать проблем с этим и были придуманы эфемерные или динамические среды. В итоге при реализации данного подхода мы получаем более стабильную среду для запуска тестов, распараллеливание на несколько сред, экономию средств и т.п.
Реализация зависит уже от самого приложения. Если ваше приложение уже как-то деплоится в облаке, используя подход "инфраструктура как код", то в принципе больших проблем быть не должно.
Про проблемы статичных сред: https://pipelinedriven.org/article/the-four-biggest-issues-with-having-static-environments
Более подробно про данный подход:
https://ephemeralenvironments.io/
https://pipelinedriven.org/article/ephemeral-environment-why-what-how-and-where
#статьи #баги
🏔Ошибки, которые могут привести к блокерам
По мотивам моего комментария к статье "ТОП-10 ошибок тестировщиков, что приводят к блокерам".
▫️Не тестировать во всех версиях
Если изменению подвергаются сразу несколько версий продукта, то следует протестировать несколько версий, дабы избежать багов.
Как можно избежать этого? Необходимо создавать чек-лист для тестирования; создавать отдельный таск на тестирование.
▫️Протестировать не во всех местах
Бывает так, что тестируемая функциональность используется в нескольких местах, но тестируется не во всех местах, а только в части из них.
Необходимо иметь карту функциональности или таблицу, по которой можно понять в каких местах ещё используется данная функциональность. Также тут можно задаться вопросом, а почему вообще одинаковая функциональность ведёт себя по-разному в разных местах?
▫️Слепо верить ТЗ и другим источникам
Тестировщик поверил тех. заданию/описанию и протестировал как там указано. В итоге фича реализована неверно, баг не пофикшен.
Как можно побороть? Перепроверка требований, уточнение вопросами типа "а как это должно работать на практике?", тестировать глубже требований и вскрывать их влияние на всю систему, проводить ранее тестирование требований.
▫️Тестировать без открытой консоли (не всегда ошибки явно всплывают)
При тестировании не замечать ошибок, которые всплывают в консоли. В итоге возникает неработающая функциональность, тормозящие страницы, фризы.
Ваша система по сбору логов уже трещит по швам, постоянные рандомные ошибки у клиентов
Что можно тут сделать? Включить автооткрытие консоли, настроить мониторинги на ошибки в консоли и следить за ними, назначая на ответственных.
▫️Незнание ценностей и приоритетов пользователей, из-за чего можно пропустить серьезные баги, хотя казалось бы
Здесь может помочь изучение продукта и изучение работы пользователей. Думайте как пользователь, изучите основные модели поведения под разными ролями и т.д.
▫️Проверить один раз. А второй раз уже не работает;) Не забывать про стабильность.
Последний пункт на сегодня ;) Тут скорее больше исходя из опыта, да и остальные пункты тоже. Бывают такие штуки, которые отрабатывают 1-2 раза, но впоследствии работать не будут.
🏔Ошибки, которые могут привести к блокерам
По мотивам моего комментария к статье "ТОП-10 ошибок тестировщиков, что приводят к блокерам".
▫️Не тестировать во всех версиях
Если изменению подвергаются сразу несколько версий продукта, то следует протестировать несколько версий, дабы избежать багов.
Как можно избежать этого? Необходимо создавать чек-лист для тестирования; создавать отдельный таск на тестирование.
▫️Протестировать не во всех местах
Бывает так, что тестируемая функциональность используется в нескольких местах, но тестируется не во всех местах, а только в части из них.
Необходимо иметь карту функциональности или таблицу, по которой можно понять в каких местах ещё используется данная функциональность. Также тут можно задаться вопросом, а почему вообще одинаковая функциональность ведёт себя по-разному в разных местах?
▫️Слепо верить ТЗ и другим источникам
Тестировщик поверил тех. заданию/описанию и протестировал как там указано. В итоге фича реализована неверно, баг не пофикшен.
Как можно побороть? Перепроверка требований, уточнение вопросами типа "а как это должно работать на практике?", тестировать глубже требований и вскрывать их влияние на всю систему, проводить ранее тестирование требований.
▫️Тестировать без открытой консоли (не всегда ошибки явно всплывают)
При тестировании не замечать ошибок, которые всплывают в консоли. В итоге возникает неработающая функциональность, тормозящие страницы, фризы.
Ваша система по сбору логов уже трещит по швам, постоянные рандомные ошибки у клиентов
Что можно тут сделать? Включить автооткрытие консоли, настроить мониторинги на ошибки в консоли и следить за ними, назначая на ответственных.
▫️Незнание ценностей и приоритетов пользователей, из-за чего можно пропустить серьезные баги, хотя казалось бы
Здесь может помочь изучение продукта и изучение работы пользователей. Думайте как пользователь, изучите основные модели поведения под разными ролями и т.д.
▫️Проверить один раз. А второй раз уже не работает;) Не забывать про стабильность.
Последний пункт на сегодня ;) Тут скорее больше исходя из опыта, да и остальные пункты тоже. Бывают такие штуки, которые отрабатывают 1-2 раза, но впоследствии работать не будут.
#истории #tms
Про TMS-ки
В жизни почти каждого тестировщика рано или поздно появляется Test Management System (TMS) a.k.a. ТМСка или гуглдрайв или просто “место для хранения тестов”.
Так вот, бедные эти ТМСки. В ручках тестировщиков они становятся бесконечным объектом нахождения багов. В принципе для тестировщика это уже становится обычным делом - находить баги везде, где только можно.
Но вот ТМСкам повезло не по-детски. То есть у них там есть свой процесс тестирования, а потом ещё и куча тестирощиков пользуются этим. Но от этого не легче, особенно когда в ТМСке куча багов. К такой ТМСке относится, например, Зефир (кстати, никогда не понимал, почему он так называется). Периодически там всплывают разного рода баги (неожиданно), бесячие и надоедливые. К примеру, нельзя было нормально растянуть список папок в дереве справа. Не знаю, сколько они фиксили эту проблему, но как будто бы всё равно натыкаешься на это ;) Я уж не говорю про документацию по API, просто шик.
Хочу уже попробовать "тест-кейс как код", может что и улучшится
Про TMS-ки
В жизни почти каждого тестировщика рано или поздно появляется Test Management System (TMS) a.k.a. ТМСка или гуглдрайв или просто “место для хранения тестов”.
Так вот, бедные эти ТМСки. В ручках тестировщиков они становятся бесконечным объектом нахождения багов. В принципе для тестировщика это уже становится обычным делом - находить баги везде, где только можно.
Но вот ТМСкам повезло не по-детски. То есть у них там есть свой процесс тестирования, а потом ещё и куча тестирощиков пользуются этим. Но от этого не легче, особенно когда в ТМСке куча багов. К такой ТМСке относится, например, Зефир (кстати, никогда не понимал, почему он так называется). Периодически там всплывают разного рода баги (неожиданно), бесячие и надоедливые. К примеру, нельзя было нормально растянуть список папок в дереве справа. Не знаю, сколько они фиксили эту проблему, но как будто бы всё равно натыкаешься на это ;) Я уж не говорю про документацию по API, просто шик.
Хочу уже попробовать "тест-кейс как код", может что и улучшится
#каналы #топ
10 полезных каналов про тестирование
🔹 Канал по тестированию
https://t.me/protestinginfo
Здесь вы можете пройти различные опросы, почитать познавательную теорию, очень советую
🔹 Тестировщик с нуля, канал Артёма Русова
https://t.me/qachanell
В канале есть полезные статьи, а также ссылки на другие полезные чатики
🔹Серьёзный тестировщик
https://t.me/serious_tester
Пожалуй самый большой канал по тестированию в русскоязычном сегменте. В выборку попадают довольно интересные статьи
🔹 QAread
https://t.me/QAreadRU
https://t.me/QARead
Здесь несколько экспертов по тестированию высказывают свою оценку выбранным статьям, есть русскоязычная и англоязычная версия
🔹 Заметки тестировщика
https://t.me/qanote
В канале можно найти различные истории, полезные ссылки, интересный канал
🔹Протестировал
https://t.me/sqaunderhood
Годный канал от тестировщика из Tarantool. Порой есть специфические кейсы, но интересно почитать даже их
🔹 Тестирование и жизнь
https://t.me/testing_and_life
Здесь мне нравится в целом особой взгляд на работу тестировщика, какие-то менеджерские темы и темы про софт-скиллс
🔹 Тестировщики нужны
https://t.me/qa_chillout
Интересный канал от тим лида из VK. По бОльшей части встречается контент по мобильному тестированию
🔹 Short QA Ideas
https://t.me/short_QA
Есть некоторые интересные темы, можно почитать
🔹 Yet another QA
https://t.me/yetanotherqa
10 полезных каналов про тестирование
🔹 Канал по тестированию
https://t.me/protestinginfo
Здесь вы можете пройти различные опросы, почитать познавательную теорию, очень советую
🔹 Тестировщик с нуля, канал Артёма Русова
https://t.me/qachanell
В канале есть полезные статьи, а также ссылки на другие полезные чатики
🔹Серьёзный тестировщик
https://t.me/serious_tester
Пожалуй самый большой канал по тестированию в русскоязычном сегменте. В выборку попадают довольно интересные статьи
🔹 QAread
https://t.me/QAreadRU
https://t.me/QARead
Здесь несколько экспертов по тестированию высказывают свою оценку выбранным статьям, есть русскоязычная и англоязычная версия
🔹 Заметки тестировщика
https://t.me/qanote
В канале можно найти различные истории, полезные ссылки, интересный канал
🔹Протестировал
https://t.me/sqaunderhood
Годный канал от тестировщика из Tarantool. Порой есть специфические кейсы, но интересно почитать даже их
🔹 Тестирование и жизнь
https://t.me/testing_and_life
Здесь мне нравится в целом особой взгляд на работу тестировщика, какие-то менеджерские темы и темы про софт-скиллс
🔹 Тестировщики нужны
https://t.me/qa_chillout
Интересный канал от тим лида из VK. По бОльшей части встречается контент по мобильному тестированию
🔹 Short QA Ideas
https://t.me/short_QA
Есть некоторые интересные темы, можно почитать
🔹 Yet another QA
https://t.me/yetanotherqa
#конференции #статьи@qa_relia
Всем привет!)
Вот статьи, которые я упоминал в своём докладике на Podlodka QA Crew в «Открытом микрофоне»:
https://telegra.ph/Kak-QA-mozhet-vesti-komandu-k-uspehu-02-18-2
https://habr.com/ru/post/654959/
Всем привет!)
Вот статьи, которые я упоминал в своём докладике на Podlodka QA Crew в «Открытом микрофоне»:
https://telegra.ph/Kak-QA-mozhet-vesti-komandu-k-uspehu-02-18-2
https://habr.com/ru/post/654959/
Telegraph
Как QA может вести команду к успеху
Часто QA находится один в команде, которая может состоять из большого числа разработчиков. И порой нужно принимать какие-то решения, влияющие на тот или иной результат. В зависимости от культуры отношения к тестированию в команде в целом тоже зависит результат.…
#конференции #выступление #podlodka
Podlodka QA Crew #8 «Расширенные навыки для QA»
Очень рад, что посетил именно этот сезон 🔥 Теперь очень жду апреля, чтобы поучаствовать снова!
Мой мини-докладик на «Открытом микрофоне»:
https://youtube.com/watch?v=apuxrVuwrUw&t=1720s
Podlodka QA Crew #8 «Расширенные навыки для QA»
Очень рад, что посетил именно этот сезон 🔥 Теперь очень жду апреля, чтобы поучаствовать снова!
Мой мини-докладик на «Открытом микрофоне»:
https://youtube.com/watch?v=apuxrVuwrUw&t=1720s
YouTube
Открытый микрофон
Сессия, где спикерами становятся не заранее отобранные Программным комитетом эксперты, а участники сезона. В этот раз поговорим о навыках выступлений, менторстве, написании статей и т.д.
Спикеры:
1) "Публичные выступления для непубличных людей" / Ольга Артемьева…
Спикеры:
1) "Публичные выступления для непубличных людей" / Ольга Артемьева…