Comments 7
Заяем аналитику делать работу тестировщика? Или в мире 1С так принято просто?
Хороший вопрос! В мире классической разработки это действительно выглядит странно, но в 1С своя специфика.
Если мы говорим про внутренний инхаус крупных компаний, там стек обычно полный: есть архитекторы, консультанты и аналитики. Но даже там ручной QA — это исчезающий вид. Чаще всего всё закрывают автотестами (Vanessa Automation), а функциональную приемку "на соответствие бизнесу" всё равно делает аналитик.
А вот в компаниях, которые занимаются внешним внедрением, ситуация жестче. Там команда часто состоит из троих: Менеджер (его задача — продать проект), Разработчик и Аналитик. И вот тут Аналитик реально превращается в "человека-оркестра": он снимает требования, пишет ТЗ, сам же его тестирует и сам сдает заказчику.
Матрица трассировки в таких условиях — это не попытка отобрать хлеб у тестировщика, а единственный способ для аналитика выжить, не пропустить баги и не "хлопать глазами" на сдаче. Это просто инструмент контроля качества там, где больше некому этот контроль обеспечить.
Да, в мире 1С очень часто нет выделенной роли тестировщика, поэтому кроме аналитика типа некому :) В идеальном мире сейчас грамотные аналитики 1С пишут сценарии функционального тестирования с использованием специализированного ПО, которые затем прогоняются в автоматическом режиме.
Я думал работа системного аналитика заключается в знание программы, чтоб не переизобретать и не тестировать переизобретенные костыли, а по максимому использовать что заложено в типовое решение.
Я к тому что в УТ насколько помню, заложена реализация с нескольких складов. Если ошибаюсь прошу меня заранее извенить, выгараю без компьютера на пляжу.
Хорошего отдыха! ☀️ Вы абсолютно правы: изобретать то, что уже есть в типовом функционале — это зло. Золотое правило 1С-аналитика: максимально использовать заложенное вендором.
В статье я взяла этот кейс именно как короткий и понятный каждому аналитику пример, чтобы не перегружать текст спецификой сложной кастомной логики. Моя цель — показать саму систему: как работает Матрица трассировки.
Этот инструмент универсален. Его можно и нужно применять на любой доработке: от маленькой колонки до огромной подсистемы, которой точно нет в коробке.
Вы правильно объясняете на доступных, базовых примерах, так делают многие учителя в уц1.
Единственное отличие что они свою упрощенную конфигурацию называют каркасной. Это заготовка с который ученик работает.
Называя это торговлей, можно в будущем наткнутся на ленивого аналитика получившего похожую задачу и списавшего в интернете требования с условиями приемки.
Это породит дальнейшие ошибки в человеческой многоножке. Мусор на входе - порождает мусор на выходе.
А так замечательная статья. Можно в колонки и строки добавить наименование, а не только номер и в ней орентироваться можно будет без сопровождающего описания. Это убережет мозги от хранения бесполезных переменных fr и tc.
Насчет "каркасности" примера — это осознанный выбор. На Хабре в 80% случаев встречаются только обзоры инструментов, но почти нет конкретики: а как его применить в реальной жизни? Я взяла УТ как понятную базу, чтобы сфокусироваться на методике.
К сожалению, в среде аналитиков 1С системная проверка через Матрицу трассировки — это большая редкость. Многие привыкли проверять "на глаз", и моя статья — попытка показать, что можно (и нужно) работать по-другому.
Про "человеческую многоножку" — риск есть, но я надеюсь, что статья научит коллег именно думать, а не просто копировать ID. Насчет названий требований прямо в матрице — отличный совет, в крупных проектах это действительно спасает мозги от лишних переменных. Спасибо за конструктив!»
Как Аналитику 1C проверить любую доработку