select ds."name" as Сценарий
    , fb."period" as Период
    , vdbi.level1_name as СтатьяБюджетовГруппа
    , dbi."name" as СтатьяБюджетов
    , dbi.code as СтатьяБюджетовКод
    , dd."name" as МВЗ
    , dd.channel_name as КаналПродаж
    , dp."name" as Проект
    , dc."name" as Валюта
    , dpi."name" as СтатьяДиР
    , sum(fb.amount_cur) as СуммаВалюта
    , sum(fb.amount_mng) as СуммаУпр
    , sum(fb.amount_scn) as СуммаСценарий
    , sum(fb.amount_reg) as СуммаРегл
from dm_pf_analysis.fact_budget fb
left join dm_pf_analysis.dim_scenario ds on fb.scenario_id=ds.scenario_id
left join dm_pf_analysis.dim_budget_item dbi on fb.budget_item_id = dbi.budget_item_id
left join dm_pf_analysis.dim_department dd on fb.department_mvz_id = dd.department_id
left join dm_pf_analysis.dim_project dp on fb.project_id = dp.project_id
left join dm_pf_analysis.dim_currency dc on fb.currency_id = dc.currency_id
left join dm_pf_analysis.dim_plcf_item dpi on fb.plcf_item_id = dpi.plcf_item_id
left join dm_pf_analysis.v_dim_budget_item vdbi on fb.budget_item_id = vdbi.budget_item_id
where fb.period between date '2023-07-01' and date '2023-07-31'
  and ds."name" = 'Фактические данные'
  and vdbi.level1_name = 'БДР'
group by
    ds."name"
    , fb."period"
    , vdbi.level1_name
    , dbi."name"
    , dbi.code
    , dd."name"
    , dd.channel_name
    , dp."name"
    , dc."name"
    , dpi."name";

 

Тестировщик может и должен оспаривать реализацию программного обеспечения в определенных ситуациях. Вот когда и почему это важно:

Когда тестировщик может оспаривать реализацию:

1. Несоответствие требованиям:

   • Если реализация не соответствует спецификациям или требованиям, определенным в документации. Тестировщик должен сообщить об этом разработчикам и менеджерам проекта, чтобы исправить несоответствие.

2. Обнаружение дефектов:

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

3. Юзабилити и пользовательский опыт:

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

4. Оптимизация и производительность:

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

5. Нарушение стандартов и лучших практик:

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

6. Потенциальные проблемы в будущем:

   • Если тестировщик видит, что текущая реализация может привести к проблемам при масштабировании, поддержке или расширении функциональности в будущем, он должен сообщить об этом команде.

Как тестировщик должен оспаривать реализацию:

1. Обоснованные аргументы:

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

2. Конструктивная критика:

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

3. Эффективное общение:

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

4. Учет приоритетов и сроков:

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

5. Документирование и отслеживание:

   • Все замечания и оспаривания должны быть задокументированы в системе управления багами или другой системе отслеживания задач. Это помогает в управлении процессом исправления и обеспечении прозрачности.

Заключение

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