Всем привет!
Нужно ли Бизнес-аналитику разбираться в качестве (QA) или функциональном тестировании (QC)? Вопрос очень спорный. В реальном мире БА разные и выполняющие разные задачи в разных условиях. Но можно выделить общие тренды из личной практики:
1. БА может выступать в качестве ProductOwner и в этом случаи принимает фичи по DoD (Definition of Done), которые сам и обозначил.
2. Является согласующим тест-кейсов и плотно взаимодействует с группой качества/тестирования.
3. Выполняет роль Функционального тестировщика.
4. Полезно для саморазвития и возможности подменить коллегу (история про кросс-функциональную команду).
Или случаи, когда БА занимается вопросами бизнес или системной архитектуры:
1. Выступает методологом построения модели качества.
2. Выступает методологом построения процесса разработки.
3. Смешная третья опция.
Подборка материалов для проверки знаний и приобретения новых

Отличный чек-лист для проверки фичей:
https://drive.google.com/file/d/1Zp_EJhhpFBGwx-b38cURVQNc8vFpY3VQ/view

ISO:
- ISO/IEC 12207:2008, 15288:2015 Systems and software engineering — Software life cycle processes.
- ISO 9001:2015 Системы менеджмента качества.
- ISO/IEC 9126 Software engineering — Product quality was an international standard for the evaluation of software quality.
А как там в Agile?
https://www.qasymphony.com/blog/agile-methodology-guide-agile-testing/
https://wellbehaved.readthedocs.io/Gherkin.html
Полезная литература:
https://www.livelib.ru/book/1000012101-dzen-i-iskusstvo-uhoda-za-mototsiklom-robert-pirsig
https://proklondike.net/books/upravlenie/kluchevie_processu_testurovanuja.html
https://www.amazon.co.uk/Hands-Mobile-App-Testing-Involved/dp/0134191714/ref=la_B00W1LQONI_1_1?s=books&ie=UTF8&qid=1499593121&sr=1-1
https://leanpub.com/testmobileapps
Самая крутая надстройка для тестирования, что встречал за последнее время:
https://www.gurock.com/testrail/

Решил немного подсобрать материалов по тестированию, в объеме знаний бизнес-аналитика.

Смешная третья опция?
Типа хочет помотать нервы QA и поучить их работать?:)

ага. У меня был случай, когда пришел молодой и "амбициозный" руководитель и когда спринт застрял был выпущен приказ: все бросили все и стали тестировщиками. Кто не умеет научим, кто не хочет заставим.

Если что, я был единственным, кто продолжил быть аналитиком)

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

Хм.. А вот я считаю, что без хороших навыков функционально  тестирования нормальные требования писать затруднительно. А навыки как известно закрепляется только практикой :)

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

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

Точно. Забыл про 3 линяю написать

Исправил

Ты еще не писал и не ранал интеграционные тесты...

Кто тесты не ранил, то жизни не виталик.

Бог миловал!

Вот сейчас был кейс интересный. Создал ТР с 1.5 месяца назад, в рамках которого встречался с бизнес-подразделением и описал правила создания объектов, но не описал логику самой работы отдела.
И сегодня попал в ситуацию, когда QA задаёт вопрос о правильности заполнения полей в случае, когда задача выходит за стандартные рамки. И я ничего не могу ответить, т.к. как в коде это работает я знаю, а как должно считаться на уровне бизнеса - информация потеряна.
Спасло бы два варианта:
1. Командировка и практика в этом подразделении на протяжении 3-5 дней (понять, что они делают, зачем делают, поработать самому на их месте).
2. Очень подробная запись логики их работы (или видео-запись конференции).

В моём случае командировку посчитали излишней, а видео-запись не велась. Надо бы уже начать записывать вообще всё.

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

Привет ребят,я из студии Видеопродакшэна Yakimenk E.S.))
Есть очень интересное предложение по поводу видео для вас)
Буду рад все рассказать в лс)

Когда предлагаешь решение без анализа и описания требований.

Хорошая иллюстрация))