Мы - команда разработчиков из 3 разработчиков, 1 дизайнер, мастер разработки и владелец продукта. Однако в нашей команде нет официального тестера. Проблема, которая всегда с нами, заключается в том, что тестирование приложения, прохождение этих тестов и устранение ошибок было определено как один из критериев, чтобы считать PBI (Product Backlog Item) выполненным.
Но проблема в том, что независимо от того, сколько мы (3 разработчика и 1 дизайнер) пытаемся протестировать приложение и реализовали варианты использования, все же некоторые ошибки не видны и разрушают нашу презентацию ( закон Мерфи ) для заинтересованных сторон.
В качестве средства защиты мы рекомендовали компании нанять нового тестера. Кто-то, кто будет работать, будет тестировать и только тестировать. Официальный профессиональный тестер.
Однако проблема в том, что Scrum Master и заинтересованные стороны считают, что разработчик (или дизайнер) также должен быть тестером.
Они правы? Должны ли мы разработчики (также дизайнеры) быть тестерами?
Ответы:
Ex ante: Кажется, есть много путаницы в том, что считается проверкой того, что нет. Конечно, каждый разработчик должен тестировать свой код по мере его создания, он / она должен проверить, работает ли он. Она / он не может передать это тестеру, пока он / она не подумает, что это сделано и достаточно хорошо. Но разработчики не все видят. Они могут не распознавать ошибки. Эти ошибки могут быть обнаружены только позже в цикле разработки, когда проводится тщательное тестирование. Вопрос в том, должны ли разработчики проводить такого рода тестирование или нет, и, по моему скромному мнению, на это нужно смотреть с точки зрения руководителя проекта:
Разработчики могут быть тестерами, но они не должны быть тестерами . Разработчики склонны непреднамеренно / неосознанно избегать использования приложения таким образом, чтобы это могло его сломать. Это потому, что они написали это и в основном проверяют, как это должно быть использовано.
Хороший тестер, с другой стороны, пытается замучить приложение. Его / ее основное намерение состоит в том, чтобы сломать это. Они часто используют приложение так, как его не могли бы представить разработчики. Они ближе к пользователям, чем разработчикам, и часто у них другой подход к тестированию рабочего процесса.
Кроме того, использование разработчиков в качестве тестировщиков увеличивает затраты на разработку и не приносит такой же выгоды для качества продукта, как наличие специального тестировщика. Я бы не позволил разработчикам перепроверить свои работы, если бы я смог сделать это лучше с помощью тестера за дешевизну. Только если бы обратная связь между разработчиками и тестировщиками стала слишком дорогой, разработчики могли бы перепроверять код друг друга, но, по моему опыту, это редко бывает, и это сильно зависит от процесса.
Это не означает, что разработчик должен быть неаккуратным и оставить все тестеру. Программное обеспечение должно быть подкреплено модульными тестами, а технические ошибки должны быть сведены к минимуму перед передачей программного обеспечения тестеру. Тем не менее, иногда у вас есть исправления, проблемы или другие ошибки, которые не мог предвидеть ни один разработчик, это нормально. Также интеграционное тестирование должно проводиться в основном разработчиками. Основная задача тестера - убедиться, что требования выполнены.
В такой небольшой команде (а также в зависимости от размера приложения) я также вижу тестировщика в гибридной роли, пишущего юнит-тесты и тесты пользовательского интерфейса. Вы обязательно должны нанять один .
Но более важными, чем тестер, являются регулярные зависания / ветки. Не представляйте ничего, что не было должным образом проверено. Когда вы добавили функцию или что-то изменили, все, что ее окружает, должно быть проверено снова. Вы получите плохую репутацию, только если ваша компания этого не сделает. Не выпускайте что-то нестабильное Когда клиент хочет получить программное обеспечение к определенной дате, тогда прекратите разработку достаточно рано и протестируйте его должным образом, чтобы у вас было достаточно времени для исправления ошибок. Часто лучше отклонять запросы функций в последнюю минуту, чем плохо их реализовывать или выпускать без надлежащего тестирования.
источник
Разработчики могут быть тестерами - кода других разработчиков.
Но тестирование вашего собственного кода не является хорошим шагом - разработчики, как правило, имеют умственные блоки в своем собственном коде, и поэтому испытывают трудности при разработке всеобъемлющих или подходящих тестов.
Всегда найдутся разработчики, которые думают, что они делают это хорошо, но обычно они этого не делают (и я уверен, что у меня много слепых зон).
Если вы ДЕЙСТВИТЕЛЬНО НЕ МОЖЕТЕ нанять тестера, тогда попросите разработчиков провести перекрестное тестирование работы друг друга - то есть, если А пишет код и выполняет модульные тесты, то заставляет Б просмотреть эти модульные тесты и посмотреть, можно ли добавить другие вещи. , И получить B, чтобы попытаться проверить код (как пользователь) и сообщить о дефектах.
Это не идеально, но лучше, чем один разработчик, пытающийся сделать все.
Иногда ваши коллеги могут быть действительно хороши в взломе вашего программного обеспечения, потому что они получают от этого удовольствие и не очень заботятся - потому что это не ИХ код.
источник
Должен ли журналист правильно писать? Я имею в виду, это работа корректоров и редакторов, чтобы найти все грамматические ошибки.
Тем не менее, журналисты сами проводят некоторую проверку орфографии. Тем не менее, корректор - это отдельная и важная профессия.
То же самое касается разработчиков и тестировщиков, за исключением того, что QA является еще более важной частью разработки. Даже если вы хороший разработчик, у вас просто нет времени тщательно тестировать все тесты, чтобы охватить все среды, браузеры и операционные системы, которые поддерживает ваш продукт.
Если кто-то, помимо развития, постоянно выполняет эту работу, это просто означает простой факт - он является тестером с частичной занятостью.
источник
Подумайте о выполнении «контролируемого бега» для спринта или двух, отслеживая разработку и тестирование отдельно. В конце такого прогона проанализируйте собранные данные, чтобы выяснить, сколько усилий вы тратите на тестирование.
Если вы обнаружите, что тестирование требует больших усилий, передайте эти данные руководству - это будет убедительным подтверждением вашего запроса (гораздо более убедительным, чем у вас сейчас).
В противном случае (если вы обнаружите, что ваше тестирование занимает мало времени), подумайте о том, чтобы приложить дополнительные усилия, чтобы сделать его лучше (или узнать, как это сделать). Обсудите эти дополнительные усилия с вашим руководством, потому что они могут предпочесть нанять тестера. :)
Должен признать, что управление вашей компанией выглядит довольно отстойно для меня. Я имею в виду - хорошо, может быть действительно трудно определить, сколько тестеров будет лучше для проекта, хорошо.
Но иметь хотя бы одного тестера - это просто безопасная ставка - действительно забавно, что они не решаются попробовать, одновременно утверждая, что они разборчивы / проворны .
источник
Ну, у нас было два кросс-теста разработчиков после того, как первый внес некоторые изменения в экран ввода. Это было, когда наш обычный тестер был в декретном отпуске.
Он в основном изменил экран списка счетов-фактур, который пользователи использовали для выбора счетов-фактур, прежде чем увеличивать их, чтобы выполнить некоторое редактирование с помощью кнопки «Редактировать». Первоначальный список был отброшен и вставлен новый вид сетки, с фильтрацией, группировкой, сортировкой и всеми видами интересных функций.
Тестирование прошло успешно, и на следующий день они отправили изменения клиенту. Спустя две недели клиент звонит и говорит: «Нам действительно нравится новая вещь, которую вы вставили, мы можем видеть всю информацию сейчас. Но ... э-э ... куда нам идти, чтобы редактировать счета сейчас? ??»
Оказывается, разработчик снял флажок (для выбора) и кнопку редактирования, и поскольку разработчики всегда дважды щелкали, чтобы выбрать элемент, ни один из них не находил ничего плохого в этом ......
Разработчики и пользователи живут в разных мирах, перекрестное тестирование лучше, чем тестирование разработчиком своей собственной работы, но это не совсем то же самое.
источник
Как уже отмечали другие разработчики, разработчики могут проводить перекрестное тестирование кода друг друга (модульное или функциональное тестирование), и, возможно, ваш scrum master и владелец продукта могут помочь с интеграционным тестированием, но для пользовательского тестирования вы должны убедиться, что вы получаете множество отзывов от клиентов - это означает частые развертывания, с которыми они могут работать, как это делают реальные пользователи, и действительно открытый канал связи .
источник
Вы должны проектировать с точки зрения тестируемости, но если у вас нет выделенного тестера, то некоторые вещи будут просто проскальзывать сквозь трещины, потому что не хватает часов в день для разработки, внедрения и тестирования программного обеспечения.
источник
Тестирование программного обеспечения - это профессиональная работа на полную ставку. Чтобы стать хорошим тестером, нужны хороший мозг, талант и большой опыт. Смешно предполагать, что разработчик программного обеспечения, каким бы умным он ни был, может приблизиться к профессиональному тестировщику, когда тестирование - это лишь небольшая часть его повседневной работы.
Кроме того, возникает проблема, заключающаяся в том, что подсознательно разработчик программного обеспечения не хочет находить ошибки.
источник
Я бы согласился с их мнением, что разработчики / дизайнеры должны тестировать свой код, с оговоркой, что дизайнер / разработчик, который сделал часть кода, не является единственным набором «глаз» на этот код перед тем, как принять на себя обязательство жить. Хотя это не собирается захватывать все, это по крайней мере поможет избежать слепоты, которая проникает при тестировании и повторном тестировании вашего собственного кода при разработке.
Из упоминания варианта использования я предполагаю, что вы также используете инструменты покрытия кода? Если нет, это может помочь увидеть, какой код не может быть протестирован, и может появиться неожиданные ошибки при определенных условиях.
При этом, если есть достаточно работы или ваша организация имеет приличный размер, я бы согласился, что нужен профессиональный специалист по контролю качества, помог бы немного сфокусировать роли каждого, и они также могли бы увидеть, есть ли какие-то закономерности относительно того, что упускается, и что более важно, как это исправить.
источник