Слой API любого приложения - один из важнейших программных компонентов системы. Это канал, который соединяет клиента с сервером (или один микросервис с другим), управляет бизнес-процессами и представляет сервисы, которые приносят пользу пользователям.
Общедоступный API, ориентированный на клиента, который делают открытым для конечных пользователей, сам по себе становится продуктом. Если он сломается, это подвергнет риску не только одно приложение, но и целую цепочку бизнес-процессов, построенных вокруг него.
Знаменитая пирамида тестов Майка Кона помещает тесты API на сервисный уровень (интеграционный), что предполагает, что около 20% или более всех наших тестов должны быть сосредоточены на уровне API (точный процент зависит от наших потребностей).
Автор: Саймон Найт (Simon Knight) Оригинал статьи Перевод: Ольга Алифанова
Не утомляйте и не путайте ваших заказчиков длинными тест-планами. Вместо них воспользуйтесь этими вариантами – они легче, проще, и удобопонятнее.
По моему опыту планирования тестирования в различных условиях, командах и организациях, ценность этого планирования не состоит в документе как таковом – она заключается в мыслях, рассматриваемых видах деятельности, ресурсах, потенциальных рисках и предположениях о проблемах.
Глубокие размышления об этих факторах и их фиксация в любой форме – вот в чем задача этого упражнения.
За пятнадцать лет работы в тестировании я наблюдаю, как отрасль из простой и незрелой, ориентированной на начинающих айтишников, становится профессиональным направлением. Раньше тест-менеджер должен был распределять задачи между тестировщиками и следить, чтобы они тестировали разные области, не повторяя одно и то же - такая вот “высокоинтеллектуальная управленческая задача”. Со временем в тестировании появилась узкая специализация, и теперь тестировщики решают разные задачи. Кто-то занимается тест-анализами и тест-дизайном, кто-то автоматизирует тесты, кто-то проводит ручное тестирование как по готовым скриптам, так и в свободном поиске, используя множество инструментов исследовательского тестирования. Соответственно, роль тест-менеджера также поменялась. Теперь он не просто распределяет задачи, а организует процесс, выделяет необходимые задачи для решения, объединяет людей с абсолютно разной квалификацией и целями, чтобы на выходе получить прекрасный результат. И тут, внимание, вопрос: а что же такое прекрасный результат в тестировании?
Автор: Джеспер Оттосен (Jesper Ottosen) Оригинал статьи Перевод: Ольга Алифанова
В классических тест-техниках и подходах тестирование – редкий ресурс. Из-за временных и финансовых ограничений всегда требовалось учитывать риски, чтобы свести концы с концами. Теперь у нас есть инструменты и подходы, увеличивающие доходность тестирования за счет большего количества тестов и их частого и более раннего прогона.
Автор: Виктор Славчев (Viktor Slavchev) Оригинал статьи Перевод: Ольга Алифанова
Хотите, я расскажу вам рождественскую сказку? Кто-то, возможно, скажет, что Рождество давно прошло, но знаете, что не пройдет никогда? Глупости, которые делают люди и называют это рабочим процессом. Не слышали, как разработчики (а может, и тестировщики) говорят "Надо поправить CI-билд, чтобы все тесты прошли"? Или что-то вроде "Мой CI-билд снова упал, как быть с этими плавающими, нестабильными тестами?" Знакомо звучит? Мне кажется, разработчики убеждены, что цель билда – быть вечно зеленым. Я называю это "вечнозеленым CI-билдом" (и поэтому это рождественская сказка), или, чтоб покороче, Эвергринчем. Эвергринч – это на самом деле монстр, который хочет украсть ваше качество и убить ваш проект. Это жуткая рождественская сказка.
Автор: Роберт Сабурин (Robert Sabourin) Оригинал статьи Перевод: Ольга Алифанова
Что делать, если в вашем тестовом проекте поджимает время? Когда код запаздывает? Когда дедлайны приближаются? Играете ли вы в "если бы только"? "Если бы только у нас было больше автотестов", или "если бы только наши тесты были устойчивее, чтобы нам не пришлось прогонять такое количество тестов для выявления багов". Проблема с этой игрой в том, что если вы начали в нее играть – уже поздно что-то менять.
Доводилось ли вам самостоятельно разрабатывать стратегию тестирования? Не доводилось — не беда! Агеева Нина, автор курса «Погружение в тестирование. Jedi Point» подробно расскажет, что такое стратегия и с чем ее «едят»: от подготовительных этапов и сбора информации до полезных мнемоник и эвристик, помогающих написать стратегию тестирования.
Привет, меня зовут Лилия, я QA TeamLead в финансовом маркетплейсе Одобрим.ру.
У нашей команды нет разделения на разработку и поддержку, и мы работаем по Kanban. Данная методология позволяет нам совмещать поддержку (т.е. задачи, которые появляются неожиданно и которые нужно выполнить срочно) и задачи из бэклога, которые запланированы заранее.
Процесс тестирования является частью процесса разработки. Он должен быть эффективен для того, чтобы не задерживать выпуск готового функционала в продуктивную среду. Для этого мы стремимся его постоянно совершенствовать.
Наш текущий QA-процесс мы прорабатывали порядка двух лет и он продолжает активно развиваться. Он может казаться очевидным, но когда мы начали внедрять его в новой команде, которая полностью состояла из новых разработчиков, то поняли, что сразу внедрить его сложно. Многие привыкли работать иначе и для переключения им требуется сделать единовременно много изменений — это сложно. Однако внедрять такой процесс частями тоже нельзя, потому что это может негативно сказаться на качестве.
Что делать? Нужна предварительная подготовка по каждому из блоков процесса разработки: декомпозиция задачи, оценка и планирование, непосредственно разработка, исследовательское тестирование, релиз. Подготовка заключается не в простом выбрасывании старых частей из процесса, а в их адекватной замене, которая даёт прирост в качестве.
В статье расскажу подробно о нашем процессе тестирования на каждом этапе создания новой фичи и о внедрённых изменениях, которые повысили качество и скорость разработки.
Доброго времени суток всем! Меня зовут Денис, я руководитель службы тестирования в «БАРС Груп».
Прочитав очень много интересных статей и почерпнув оттуда много полезной информации, захотелось что-то дать взамен. Тогда я начал анализировать темы: одни были уже озвучены, другие слишком просты («как войти в IT?»). P.S. ничьи чувства задеть не хотелось :)
