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

Мы на пальцах рассмотрим что такое шардирование, как оно помогает в масштабировании и даже рассмотрим тот самый этап «роста».

Тестирование, принцип TDD, юнит-тестирование и прочее.

1. Мы делаем сайт, показываем заказчику, он высылает список неточностей и дополнительных пожеланий, мы их бодро правим и сайт отдаем заказчику, т.е. выкладываем на его сервер. На его сервер никто не ходит, заказчик понимает, что чуда не произошло и перестает платить за хостинг/домен. Сайт умирает. Нужны ли там тесты?
2. Мы делаем сайт, показываем заказчику, он высылает список правок, мы их бодро правим, запускаем сайт. Через полгода на сайте 300 уников в день и эта цифра растет изо дня в день. Заказчик постоянно просит новые фичи, старый код начинает разрастаться, и со временем его всё сложнее поддерживать.

Создание фреймворка автоматизации тестирования — это масштабная задача, и ваш проект теперь обладает эффективной инфраструктурой тестирования. Регулярный запуск тестов, анализ отчетов Allure, а также поддержание стиля и качества кода с использованием форматтеров и линтеров обеспечивают надежность и стабильность вашего проекта.

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

Меня зовут Саша, я работаю в команде тестирования Ozon Fintech и расскажу про разнообразный спектр вариантов НТ: как именно мы его применяем и какие инструменты используем. Статья будет полезна тем, кто уже что-то слышал про НТ и хочет добавить его в свой проект, но пока страшновато. Давайте разбираться!

Регрессионное тестирование играет важнейшую роль в разработке продукта и считается непростой задачей. С этим трудно не согласиться, когда вы тестируете то, что уже было протестировано, а потом тестируете это снова. Термин «регрессия» ассоциируется у членов команды с большими усилиями. Мы знаем, насколько головоломным и вместе с тем незаменимым может быть регрессионное тестирование для процесса релиза и спрашиваем «Приведет ли невыполненное регрессионное тестирование к неудовлетворительному результату?» и «Нужно ли проводить регрессионное тестирование, если программа без ошибок – это недостижимая цель?» Что ж, ответом будет «Да! Регрессионное тестирование нужно проводить регулярно».

Что подразумевается под регрессионным тестированием?

На этот вопрос можно ответить одной фразой: «Исправляя одну ошибку, вы привносите в приложение несколько новых ошибок». Регрессионное тестирование – это то, что позволяет обеспечить исправление ошибки без побочных эффектов.
Во время тестирования выявляются некоторые ошибки, при этом разработчики проекта проводят быструю отладку. Тестировщики и разработчики проводят регрессионное тестирование, чтобы исправление ошибок не привело к нарушению функционала приложения.

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

Что такое тест-кейс?

Зачем нужны тест-кейсы?

Всем привет! Меня зовут Миша, я работаю на позиции ручного тестировщика, или Manual QA - кому как удобно. В связи с тем, что в моей работе преобладает ручное тестирование -  я часто сталкиваюсь с консолью разработчика в браузере (думаю как и 99.9% web-тестировщиков). 

В интернете огромное количество источников, в которых можно найти информацию про DevTools, как для разработчиков, так и для тестировщиков. Конечно, наполнение таких статей очень сильно разнится в зависимости от ее направленности. Изучив большое количество подобного материала и поняв, что нас (тестировщиков) обделяют информацией, решил залезть в первоисточник для изучения инструментов разработчика в полном объеме. Пройдясь по всем пунктам огромного меню, выписал для себя порядка 20 пунктов, которые были бы интересны (читай полезны) для тестировщиков. Сразу скажу, что в статье я не буду рассказывать, как пользоваться тем или иным инструментом, так как это подробно описано в статьях, которые будут прикреплены к каждому из пунктов. Цель моего повествования - скорее вычленить из огромного списка возможностей DevTools, именно те, которые были бы полезны для QA-специалистов. Не претендую на объективность и полную раскрытость темы, но постараюсь это сделать.

Привет, хабровчане. Сегодня я хочу осветить и обсудить тему локализации (L10N) и интернационализации (I18N). В интернете и, в том числе и на Хабре уже есть полезные и интересные статьи, но часто они дают более-менее общую информацию о подходах, без углубленной информации о том, что и как можно проверить. Я бы хотел с вами поделиться своим опытом, просуммировать кое что из статей, которые вы можете найти в интернете, а также постараюсь описать большой checklist с самыми распространёнными кейсами как для локализации, так и для интернационализации. В чеклистах я буду стараться упоминать только те проверки, которые вы можете сделать сами, без (глубоких) знаний языка новой для вас локали.

"Бывает, что комментарии интереснее самой статьи, верно?" Было написано автором ровно год назад, когда в поисках интересного по теме QA он устал пробираться через "нативные" материалы и создал рецензируемый QA-журнал для трейни/джунов/мидлов.В честь первого юбилея публикуется дайджест журнала.

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

Всем привет! Меня зовут Серёга Леонов, я инфраструктурный инженер в Тинькофф. Недавно наша команда внедрила и приспособила уже привычный всем инструмент Zabbix под что-то новое — мониторинг и сбор инвентарных данных на всех компьютерах компании. Расскажу, как мы это сделали и какую пользу это принесло отделам, работающим с внутренними пользователями.

API (Application Programming Interface, программный интерфейс приложения), является жизненно важным компонентом в современном ландшафте разработки программного обеспечения, обеспечивая строительные блоки для взаимодействия приложений друг с другом. В этой статье рассмотрим пять основных типов API: REST, SOAP, WebSocket, gRPC и GraphQL, чтобы получить более четкое представление об их функциях, особенностях и идеальных сценариях использования.

Я посмотрела, как тестируют поиск начинающие тестировщики, и решила написать этот чит-лист проверок. Это такая серебряная пуля, которую можно применить на любом проекте, лишь немного варьируя под себя, под свой проект.

Поиск — он же есть практически в каждой системе. Поэтому здорово, когда есть шпаргалка «какие вопросы задать аналитику» и «какие проверки провести». Именно это мы в статье и обсудим. Сначала я дам чек-лист, а потом разберу каждый пункт отдельно.

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

Жизнь QA станет проще, если использовать чек-листы из статьи.