API – сердце большинства современных приложений. Если оно работает некорректно, приложение может сломаться в самый неподходящий момент. Современные системы напоминают паутину: API связывают микросервисы, облака хранят тонны данных, а пользователи ждут, что всё будет работать даже во время апокалипсиса. Но как проверить то, что нельзя увидеть или пощупать? И как грамотно протестировать API, чтобы избежать неприятных сюрпризов?
Для того чтобы провести качественное тестирование ПО, тестировщики создают тест-кейсы. Каждый тест-кейс — это подробное описание действий и ожидаемого результата, который служит как руководящий документ для проведения тестирования определенного функционала продукта.
Если провести сравнение между тест-кейсом и тестовым сценарием, то последний является более объемным и охватывает большую функциональность при проведении тестирования. Но в этой статье мы разберем именно тест-кейс.
Современные мобильные приложения стали более сложными и отличаются особой многофункциональностью. Все мы помним программы на Symbian OS от Нокии, можно сказать, что это были своего рода MVP версии современных приложений. Сегодня для такого ПО устанавливаются более жесткие требования по всем критериям, от интерфейса и функциональности до реализации ожиданий пользователя после установки. Отсюда вытекает закономерный вывод — приложения требуют тщательного и детального тестирования. И это требование устанавливает сам рынок онлайн продуктов – плохое приложение = потере денег.
Итак, в этой статье мы разберем что такое мобильное тестирование и с какими сложностями оно сталкивается.
История знает множество примеров, когда пропущенный дефект в коде становился причиной миллионных убытков и тянул компанию на дно. Как тестирование защищает кошельки и репутацию бизнеса, почему тестировать силами разработки невыгодно и стоит ли QA своих вложений? Читайте в статье…
Реальность такова, что не во всех компаниях есть QA-команда. Поэтому, если вы чувствуете дефицит экспертизы в тестировании, это не повод начинать мониторить hh.ru. Восполнить этот пробел можно как прибегнув к собственным силам и ресурсам, так и найдя готовое решение в виде аутсорсинга на стороне. В продолжении статьи вас ждут советы, как это лучше сделать…
Вы знали, что команда Amazon Web Services еще в 2015-м выпускала 50 миллионов релизов в год? Это чаще, чем один в секунду! Как у них так получалось? Парни знали как и когда внедрять автотесты. Теперь попробуем разобраться и мы.
Если вы разрабатываете ПО для нужд медицины и здравоохранения, то вероятно знаете − ничто так не волнует ваших заказчиков, как состояние здоровья их пациентов. А что, если бы вы могли не только расширить функциональность и качество продукта, но и сэкономить бюджет на разработку медицинского ПО за счёт услуги QA аутсорсинга? Давайте взвесим преимущества.
Успех компаний, занимающихся розничной торговлей, во многом зависит от используемого программного обеспечения. Пока дизайнеры только исследуют поведение пользователей с помощью A/B-тестов, маркетологи уже внедряют новые инструменты, внося изменения в конфигурацию ритейл-приложений. Как же избежать проблем в будущем, если функциональность приложений и количество интегрируемых модулей неуклонно растут день за днем. Давайте разберёмся.
Перенос стадии тестирования на ранние либо поздние этапы жизненного цикла разработки может способствовать скорейшему достижению поставленных целей или существенно повлиять на улучшение самого процесса разработки. Как же понять, когда стоит вносить изменения в привычный порядок циклов разработки программного обеспечения? Пусть ответом на этот вопрос станут ваши циклы тестирования. Что мы имеем в виду? Хорошим наглядным примером станет вождение автомобиля с механической коробкой передач.
Вооружившись автоматизацией вместо автоматов, собрав лучших специалистов вместо наемников, разработав хитроумные планы, которым позавидует сам «Крёстный отец», мы отправились на борьбу с похищением времени и сил у наших клиентов.
