Нередко можно слышать от тестировщиков, что они перестают понимать, что они делают, и со временем уходят из профессии или переходят в продакшен, на повышение, становятся менеджерами разрабатываемого продукта. В этом случае, если они раньше выполняли тесты по разработанным тест-планам, что можно делать и не вникая, почему план составлен именно так, то теперь им нужно представлять продукт заказчику, и неважно, как он внутри работает, сколько раз его переделывали и как это отразилось на самом продукте. Наверно, в этом и состоит смысл набирать в тестирование людей с гуманитарным образованием, владеющих развитыми речевыми навыками и обладающих образным интеллектом, чтобы потом работать с заказчиком, объяснять ему понятным языком все необходимые вопросы, связанные с разработкой продукта.
Но можно пойти и другим путем, вникать в рабочий процесс, читать литературу по архитектуре приложений, вникать в проблемы разработки и тестирования. Тогда процесс тестирования станет осмысленным и будет понятно, почему одно и то же приходится тестировать бесчисленное количество раз, от чего это зависит, какие проблемы Вы таким образом решаете. Если во все это вникнуть, то станет намного интереснее работать и возможен быстрый рост до уровня сеньор тестировщика. Хотя такие люди иногда и в разработку уходят, если имеют соответствующие навыки.
В настоящее время, в клиент-серверной архитектуре существует два основных направления. Одно из них традиционное, создание монолитных приложений. При этом подходе группа разработки делится на три категории: разработчики интерфейса, разработчики серверной части и разработчики системы управления базой данных.
Тестировщики, соответственно, так же по-отдельности тестируют разные части приложения: отдельно тестируется интерфейс UI, серверная часть приложения back-end, и отдельно тестируется база данных на соответствие типам данных полей таблиц и требованиям к размеру полей.
База данных в этом случае, как правило, является реляционной, состоящей из связанных таблиц при помощи вторичных ключей. В этом случае надо еще тестировать связи на соответствие техзаданию и производить проверку соответствия значений полей связанных между собой таблиц.
В монолитном приложении серверное программное обеспечение обрабатывает HTTP запросы, в соответствии с бизнес-логикой приложения, запрашивает и обновляет данные таблиц, хранящиеся на сервере, затем отправляет данные клиентской части приложения для заполнения HTML страниц браузера. Любое изменение в системе приводит к повторной сборке и развертыванию новой версии серверной части приложения. И, соответственно, повторяется весь процесс тестирования серверной части и интерфейса, если в интерфейс тоже вносились изменения.
Если вносятся изменения в структуру базы данных, то это влечет за собой проверки целостности данных, проверки работы специальных утилит, которые преобразуют данные у клиента в соответствии с новой структурой данных на сервере.
Для тестирования приложения можно его запустить на компьютере разработчика или на тестовом окружении, используя стандартный процесс развертывания, а по окончании тестирования выложить приложение в продакшен, для проведения пользовательского тестирования.
Для преодоления трудностей, связанных с разработкой и тестированием монолитных приложений, был создан новый архитектурный стиль микросервисов. Этот подход мы рассмотрим в следующий раз.
Если материал был полезен, ставьте лайк. В закрепленном сообщении видео и другие материалы для подписчиков.