Тестировщик -> Разработчик
Пока работал ручным тестировщиком часто задавался вопросом:
«Почему разработчик сам не может за собой проверить свою реализацию? Это же так просто, накидать у себя в голове пару ТК. Этому учат на любых курсах по тестированию.»
И я нашел ответ. Да, он банальный, но в этом и его тайна. Не может, потому что думают они по другому.
Первая причина эта разница в мышлениях очень хороша видна на примере автотестирования(АТ) и разработки. В обоих направлениях нужны минимум знания языка программирования, ООП, архитектуры и логики. НО автотестировщик будет писать свой код так чтобы он проверял последовательность действий и сравнивал ожидание с фактом, а разработчик будет писать код так чтобы он был максимально стабильный.
Представим, что код - это поезд. Так у разработчика на пути следования поезда из точки А в точку Б будет много ответвлений, чтобы объехать опасные участки если на них что то возникнет.
А у АТ этот поезд будет иметь только одну ветку и он не может повернуть, и обойти проблему. Ему надо ехать строго прямо.
Вот и получается что пока разработчик будет думать о стабильности, любой из АТ в первую очередь будет проверять ожидание с реальностью. И бывает сложно переключить мышление с одного на другое, особенно в рамках своей же доработки.
Вторая причина, всплывает на интеграции двух систем. Разработчик может не знать как создать те или иные тестовые данные для проверки своего кода. Да, он предусмотрит поведения для разных ситуаций о которых ему расскажут. Но проверить из разряда "А что если?" он не всегда сможет.
Безусловно есть разработчики кто умеют и то и другое, но все мы люди и перепроверить стоит.
Разработчик->Тестировщик
Бывает что сделали когда какую то мелочь: переменную поправили, мелкий функционал, который особо не влияет и т.п.
С такими изменения разработчик приходит к тестировщику и просит быстро проверить.
А тестировщик отказывается сделать это прямо сейчас или говорит: "Это долго проверять". Почему же так бывает?
Вспоминаем про интеграции. Часто бывает, что ломается не там где правили/дорабатывали код. И задача тестирования проверить все возможные варианты.
Второй вариант вы не один разработчик у него. Так заведено, что разработчиков больше чем тестеров в команде, очень наглядно это видно в фиче-командах. И вы могли не один прийти с такой "мелкой" задачей. Это создает очередь на тестирование. И тестер вынужден выбирать уже по приоритету.
Заключение
Надеюсь хоть немного, но смог объяснить позицию обоих направлений. Да, ситуации бывают разные, команды бывают разные, подходы разные. И в целом это прописные истины, но часто на таких истинах портились отношения с коллегами.
А какие у вас были ситуации? Что вы бы ответили на этот вопрос?