Модульное тестирование - разработка или тестирование?

У меня была дискуссия с менеджером по тестированию о роли модульного и интеграционного тестирования. Она попросила, чтобы разработчики сообщили, что у них есть проверенный модуль и интеграция и как. Я считаю, что модульное и интеграционное тестирование являются частью процесса разработки, а не процесса тестирования. Помимо семантики, я имею в виду, что модульные и интеграционные тесты не должны включаться в отчеты о тестировании, а тестировщики систем не должны беспокоиться о них. Мои рассуждения основаны на двух вещах.

1. Модульные и интеграционные тесты планируются и выполняются всегда на основе интерфейса и контракта. Независимо от того, используете ли вы формализованные контракты, вы все равно проверяете, что, например, должен делать метод, то есть контракт.

   В интеграционном тестировании вы тестируете интерфейс между двумя отдельными модулями. Интерфейс и контракт определяют время прохождения теста. Но вы всегда тестируете ограниченную часть всей системы. Тестирование систем, с другой стороны, планируется и выполняется в соответствии с системными спецификациями. Спецификация определяет, когда тест пройден.

2. Я не вижу смысла в том, чтобы сообщать тестерам (систем) о широте и глубине модульных и интеграционных тестов. Предположим, я пишу отчет, в котором перечисляется, какие виды модульных тестов выполняются для определенного класса бизнес-уровня. Что он / она должен от этого отнять?

   Судить о том, что следует и не следует проверять на основании этого, является ложным выводом, поскольку система все еще может функционировать не так, как того требуют спецификации, даже если все модульные и интеграционные тесты пройдены.

Это может показаться бесполезным академическим обсуждением, но если вы работаете в строго формальной среде, как я, это действительно важно для определения того, как мы делаем вещи. В любом случае, я совершенно не прав?

Написание автоматических тестов - работа разработчика; тесты являются частью кодовой базы и должны рассматриваться как таковые - они должны подвергаться тем же проверкам кода, стандартам кодирования, дисциплине контроля исходного кода и т. д., что и остальная часть проекта.

Запуск указанных тестов выполняется по двум причинам: во-первых, как инструмент для руководства разработчиками. Вы запускаете тесты, чтобы убедиться, что только что написанный код выполняет то, что он должен, вы используете их в качестве дополнительной документации и убедитесь, что изменения не нарушают какой-либо существующей функциональности. Если вы делаете настоящий TDD, тесты также являются авторитетным источником технических спецификаций. Вторая причина использовать тесты во время QA и развертывания. Запуск всех автоматизированных тестов должен быть одним из первых шагов в каждом раунде тестирования; Проведение автоматических тестов обходится дешево (практически не требуется рабочей силы), и нет смысла переходить на ручное тестирование, если автоматизированные тесты дают сбой.

Это означает, что обязанности должны быть такими:

• Разработчики пишут автоматизированные тесты
• Разработчики запускают индивидуальные автоматизированные тесты по мере необходимости, как часть их рабочего процесса разработки
• QA запускает все автоматизированные тесты как один из первых этапов тестирования

Если у вас есть сервер сборки, тогда задача QA (в отношении автоматических тестов) сводится к тому, чтобы «открыть отчет сервера сборки и убедиться, что все в порядке».

Я думаю, что наиболее важным для вас было бы уточнить, зачем ей нужен этот отчет.

Там могут быть разные объяснения (как предложено в нескольких ответах), которые требуют очень разных стратегий.

• если она - разумный человек, просто желающий получить информацию, чтобы помочь работе ее команды тестирования, имеет смысл прийти к общему пониманию и выработать какое-то решение, которое подойдет вам обоим. Вы можете обсудить с ней природу модульных тестов и принципиальную разницу между модулем и функциональными / системными / приемочными тестами. Надеюсь, вы сможете понять, что они работают на самых разных уровнях, и ни один не может заменить другой.
• если она ненормальная или бюрократка, требующая отчета только ради него, вы можете сгенерировать что-то, чтобы удовлетворить ее прихоти с наименьшими усилиями (например, то, что предложил @Doc :-).
• если она участвует в какой-то сильной игре, вы можете спросить, имеет ли она право требовать отчеты от разработчиков. По моему опыту, разработчики обычно не должны отчитываться перед отделом контроля качества.

Я думаю, что роль QA и Development, а также взаимодействие могут сильно различаться между организациями. Но в целом, в моей команде я говорю присоединяющимся участникам, чтобы они притворялись, будто нет команды QA, в том смысле, что они ответственны за изменения, которые они продвигают в производство. В свою очередь, наша команда QA не особо задумывается о тестировании разработчиков и проводит значительную часть тестирования системы как функционального целого.

По этой причине, наша команда QA не особо заботится о том, что является тестированием, а что нет, прежде чем начать тестирование.

Я думаю, что для команды QA полезно понять, что делают и не охватывают модульные тесты, на высоком уровне, чтобы мы могли коллективно работать над выявлением пробелов и областей, которые могут нуждаться в большей строгости. Так что, может быть, ваш коллега после резюме высокого уровня, в отличие от кровавых подробностей.

Она настаивала на том, чтобы разработчики сообщали, что у них есть, и как они тестировали модуль и интеграцию.

Она действительно пытается спорить о том, действительно ли этот вид тестирования находится в сфере «разработки», или она просто пытается выяснить, насколько хорошо ваш код охватывается модульным тестированием? Просто взглянув на информацию, которую вы предоставили, кажется, что она просто хочет знать, какие части кода описаны и на чем ей следует сосредоточить усилия своей команды.

Я работал в команде по тестированию сразу после школы, прежде чем перейти к роли разработчика, и я понимаю, насколько это может быть полезно для нее и ее команды.

Я не вижу, что это имеет большое значение.

Если вы не предоставляете их для QA / Testing, и они не проводят надлежащие тесты, и они не работают в производственном процессе, это их вина в том, что они пропустили его через QA без проверки того, что он работает, как указано.

Если вы предоставляете их для QA / Testing, и они не проводят надлежащие тесты ... тот же результат, как если бы вы их не предоставили.

Однако, если вы предоставите их, они также могут сравнить их со спецификацией и / или предложить, какие тесты могут быть ошибочными или нуждаются в изменении, потому что они нашли ошибку.

На самом деле, я не вижу большого недостатка в их предоставлении. Это все еще на QA / тестировании, чтобы проверить против спецификации. Если они идут ленивым путем и полагаются на то, что ваше тестирование достаточно хорошее, потому что все они прошли, это они потерпели неудачу на своей работе. Пока у них все еще есть спецификация, результаты модульных / интеграционных тестов просто бесполезны и не должны причинить вам вред так или иначе. Это причина, по которой у нас есть dev и QA. Несколько проверок, которые приложение выполняет, как указано.

Разработчики делают ошибки, QA делает ошибки, в идеале, они не делают ошибку в одном и том же предмете ... и если они делают ... это потенциально аналитик, который бросил мяч, написав неясную спецификацию.

Ответственность за модульное тестирование несут разработчики, чтобы понять, как фрагменты кода работают самостоятельно. Некоторые могут воспринимать это как форму документации и, таким образом, имеют определенную ценность, хотя могут возникнуть издержки, если модульные тесты регулярно меняются.

Другое значение при прохождении тестов состоит в том, что это позволяет избежать дублирования тестов, которые могут быть избыточными с точки зрения обеспечения основных функциональных возможностей.

Существует также пользовательское приемочное тестирование, которое отделено от всего этого, поскольку конечный пользователь может иметь собственное понимание того, как должна функционировать система.

Если в вашей компании есть определенная методология, обеспечивающая качество ее продуктов (если они соответствуют SOX или пытаются повысить уровень CMMI, вероятно, так и есть), то продукты должны быть в состоянии противостоять аудиту, чтобы показать, что процесс последовало

Часто определенный процесс включает в себя модульное тестирование (что хорошо). К сожалению, это также означает, что вы должны задокументировать свои модульные тесты и доказать, что они были выполнены, чтобы выдержать аудит. Так что это означает, что вам нужен способ сообщить о своих модульных тестах.

Вам поможет такой инструмент, как Sonar - он сообщит об уровне покрытия кода и результатах ваших юнит-тестов.

Это действительно зависит от компании, но от моего опыта работы системным тестером в традиционном подходе, а также тестером, работающим в гибкой команде на модели компакт-дисков, знание того, что было проверено модулем и интеграцией, чрезвычайно полезно.

Ответственность за качество лежит на команде - и разработчики, и тестировщики, и менеджмент продуктов, и совместная работа - лучший способ обеспечить это.

Таким образом, менеджер по тестированию хочет знать, что было проверено модулем и интеграцией, и это немного больше дополнительной работы для разработчиков, но это экономит общую работу для проекта! Предоставляя информацию менеджеру по тестированию, они могут сосредоточить усилия своей команды тестировщиков на том, что является критическим и важным. Как упоминалось ранее, если область кода не подверглась модульному тестированию, команда может сосредоточить свои усилия на ней по сравнению с областью, которая подверглась серьезным испытаниям - зачем дублировать усилия? Вы все работаете над достижением одной и той же конечной цели - более качественное и своевременное программное обеспечение

Я думаю, что было бы полезно обеспечить этот тип вещи. Охват модульных тестов должен быть тем, что известно при разработке и тестировании, чтобы они могли это учитывать.

Очевидно, что вы должны протестировать важные для бизнеса вещи, несмотря ни на что. Вы должны тщательно тестировать часто используемую функциональность независимо от того, имеет ли она большой охват модульных тестов. Не мешало бы им сообщить, какие другие места охвачены юнит-тестами. Код уже проверяет крайние случаи в этом маленьком элементе управления? Такие вещи полезно знать со всех сторон бизнеса.

Стоит упомянуть подход, обсуждаемый в книге «Как Google тестирует программное обеспечение»: тестирование и контроль качества - это ответственность каждого, а стандарты строгие.

Реальная роль , что традиционно называется отдел «Testing», на самом деле производительность труда разработчиков; т.е. автоматизация, позволяющая организации достичь требуемого уровня строгости с экономической точки зрения.