Доброго времени суток!
Я как аналитик иногда занимаюсь функциональным тестированием полного билда системы. То есть по сути - системным тестированием.
У меня такой вопрос, должен ли аналитик участвовать в интеграционном тестировании или юнит-тестировании? И каковы должны быть функции аналитика в этом процессе.
Спасибо.

Отличная тема.

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

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

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

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

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


Это - идеальная картина. Реально может быть всякая комбинация, в зависимости от конкретной области. Классическая (водопадная) модель больше рассматривает продуктовый вариант. SCRUM дает некоторую комбинацию: с одной стороны, члены команд проверяют работу друг друга, выделенной роли тестировщика нет но деятельность - есть, а вот Product Owner является аналитиком, формулируя требования, и он же принимает результат.

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

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

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

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

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

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

А при помощи какого продукта автоматизируете?
Я пока не в курсе что у меня в компании и как, знаю только, что автотесты существуют, а налитики всё проверяют руками. Юнит-тестов вроде как нету.. При том, видимо, преобладает "ручное" тестирование.

А при помощи какого продукта автоматизируете?

Используем TestComplete. Мы используем 7. На 8 там драконовские условия по лицензированию, имхо

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

Что вы называете интеграционным и юнит-тестированием, я не знаю

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

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

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

Т.е. аналитик занимается приемычным тестированием по сути, проводит мини опытную эксплуатацию.

Это конечно мое личное мнение и наблюдение.