Тестирование без ресурса QA

Возможно ли провести достаточное тестирование программного приложения только с разработчиками и BA без ресурсов QA?

Здесь есть две точки зрения:

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


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

Оба эти убеждения являются крайними.


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

На моей первой работе у меня не было контроля качества. Я должен был убедиться, что мой собственный код достаточно качественный, прежде чем выпускать его, и этот аспект напугал меня настолько, что я научился писать качественный код (что в основном означает, что вы тщательно тестируете свой собственный код, выполняя свой собственный QA).

Достаточно ли тестирования для разработчиков?

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

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


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

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

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

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


Почему нам все еще нужен контроль качества?

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

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

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

В идеальном мире тестеры не должны находить никаких дефектов, или хотя бы мелкие недочеты. Когда есть «команда QA», задача которой заключается в поиске дефектов, у разработчиков возникает соблазн просто полагаться на тестировщиков в поиске всех дефектов, в то время как разработчики сосредоточены на разработке и кодировании.


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

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