Сегодня вторник, а значит, мы с бизнес-аналитиком Юлией Чугуновой разбираем архитектуру данных – от бизнес-сущностей до связей в БД (базе данных). Учимся переводить требования в структуру таблиц, разбираем, как избежать «костылей» в базе и почему ошибки в данных дороже багов. И главное – учимся строить реляционные модели, которые не развалятся при масштабировании.
Мы собрали короткий, понятный и практичный гайд о том, с чего начинается тестирование и тест-анализ, какие ошибки совершают даже опытные команды и как QA помогает сэкономить десятки часов и сотни тысяч. Всё – на примерах, с реальными кейсами и без демагогии. Забирайте по кнопке ниже.
В 2025 искушенные пользователи безжалостно уходят после первой же ошибки, поэтому в заказной разработке доверие клиента – самая хрупкая и ценная валюта. E2E-тестирование помогает ее не просто сохранить, но и приумножить. Оно ловит те коварные проблемы, что рождаются на стыках миров – вашего кода и легаси-системы клиента, нового фича-бренча и старой базы данных, идеального стейджинга и непредсказуемого продакшена.
Каждый день я работаю с самыми разными документами: BRD, пользовательскими сценариями, SRS, UML-диаграммами. В этой серии статей я не собираюсь выдавать сухой чек-лист или заумные определения. Я хочу предложить живой, понятный путеводитель – карту, по которой сможет пройти каждый: будь то начинающий аналитик, тестировщик, проджект-менеджер или просто человек, столкнувшийся с навязчивым ощущением «что-то идет не так».
API – сердце большинства современных приложений. Если оно работает некорректно, приложение может сломаться в самый неподходящий момент. Современные системы напоминают паутину: API связывают микросервисы, облака хранят тонны данных, а пользователи ждут, что всё будет работать даже во время апокалипсиса. Но как проверить то, что нельзя увидеть или пощупать? И как грамотно протестировать API, чтобы избежать неприятных сюрпризов?
Для того чтобы провести качественное тестирование ПО, тестировщики создают тест-кейсы. Каждый тест-кейс — это подробное описание действий и ожидаемого результата, который служит как руководящий документ для проведения тестирования определенного функционала продукта.
Если провести сравнение между тест-кейсом и тестовым сценарием, то последний является более объемным и охватывает большую функциональность при проведении тестирования. Но в этой статье мы разберем именно тест-кейс.
Современные мобильные приложения стали более сложными и отличаются особой многофункциональностью. Все мы помним программы на Symbian OS от Нокии, можно сказать, что это были своего рода MVP версии современных приложений. Сегодня для такого ПО устанавливаются более жесткие требования по всем критериям, от интерфейса и функциональности до реализации ожиданий пользователя после установки. Отсюда вытекает закономерный вывод — приложения требуют тщательного и детального тестирования. И это требование устанавливает сам рынок онлайн продуктов – плохое приложение = потере денег.
Итак, в этой статье мы разберем что такое мобильное тестирование и с какими сложностями оно сталкивается.
История знает множество примеров, когда пропущенный дефект в коде становился причиной миллионных убытков и тянул компанию на дно. Как тестирование защищает кошельки и репутацию бизнеса, почему тестировать силами разработки невыгодно и стоит ли QA своих вложений? Читайте в статье…
Реальность такова, что не во всех компаниях есть QA-команда. Поэтому, если вы чувствуете дефицит экспертизы в тестировании, это не повод начинать мониторить hh.ru. Восполнить этот пробел можно как прибегнув к собственным силам и ресурсам, так и найдя готовое решение в виде аутсорсинга на стороне. В продолжении статьи вас ждут советы, как это лучше сделать…
Вы знали, что команда Amazon Web Services еще в 2015-м выпускала 50 миллионов релизов в год? Это чаще, чем один в секунду! Как у них так получалось? Парни знали как и когда внедрять автотесты. Теперь попробуем разобраться и мы.
