Вопрос должен быть почему при тест-дизайне ...
как у вас все идеально ) если честно, пока что не встречал тест-дизайнеров
Любой тестировщик пишуший тесты выполняет работу тест-аналитика.
Я не очень согласен с этим. Например взять функциональные фронт энд тесты:
Мануальщик может знать гораздо больше фишечек и подводных камней, чем автоматизатор, то есть логично было бы написать тест по его тест-кейсам(то есть он и выступает в качестве тест - дизайнера)
Или я ошибаюсь ?
Слово "пишет" слишком многозначно. Любой тестировщик придумывающий тесты выполняет работу тест-аналитика. В вашем случает автоматизатор реализует тесты придуманные кем-то другим.
Мануальщик, автоматизатор - пофиг. Есть роль - тест-аналитик. Если нет человека выполняющего обязанности роли - будут проблемы с тест-дизайном.
Сорри, подумал , что "пишет" подруземается "автоматизирует") Теперь более понятно, спасибо! Но согласитесь все-таки, что сверка данных с БД как то очень не очевидный кейс, мне и в голову не пришло, на момент, так сказать "проектирования", что программер может перепутать ключи(с одинаковыми типами данных)=) У меня написано много тестов по другим проектам, где о данной проблеме даже и речи не идет. Видимо, на этапе внедрения нового проекта , все таки, этот кейс должен быть обязательным (возможно, разовым и мануальным?)... но теперь тогда вопрос в другом : как тестировать?
Брать хранимку, которую использует метод и тупо сверять данные ?
А если ДБА накосячил в хранимке , кто за ним проверит ?