Test Architect

Job Description:

Mandatory Skill: Fraud Experience.

• The Quality Engineering Test Architect (QE-TA) is a strategic testing leader responsible for overseeing and orchestrating end-to-end testing governance across projects and releases.
• The QE-TA serves as the central point of coordination between Business Analysts, Business Sponsors, Testing Teams, and Project stakeholders — ensuring that testing activities are well-planned, properly executed, and aligned with release objectives.
• The QE-TA drives testing quality, monitors progress and defect resolution, and produces key testing artifacts that support informed decision-making throughout the software delivery lifecycle.

Key Responsibilities

• Take ownership of reviewing the Project Scope document (in PTS) and, where available, the Project Feature document (in Confluence) to make an informed determination on whether End-to-End (ETE) testing is required for the project.
• Where ETE testing is identified as necessary:
• Proactively drive alignment by scheduling and leading conversations with Business Analysts (BAs) and the Business Sponsor — building a shared understanding of ETE scenarios and ensuring all impacted teams are identified early.
• Bring testing teams into the discussion to collaboratively finalize scenario steps and clear any outstanding questions before they become blockers.
• Target: Full ETE scenario sign-off and open questions resolved no later than one week before the start of UAT/Unified Testing — setting the team up for a clean, confident testing entry.
• Strategically coordinate Testbed (TBED) criteria pull readiness by reminding testing teams to submit for UAT1 and UAT2 environments in alignment with the Release Calendar — keeping the team ahead of critical timeline dependencies.
• Drive Test Data Management (TDM) preparation by coordinating or submitting requests as applicable through the designated SharePoint site, ensuring test data is available and ready before execution begins.
• Own and distribute the Testing Status email during Unified Testing — serving as the team's visibility anchor. Calibrate communication frequency to the project's risk posture:
• Low concern projects: Send the day before or morning of the weekly Project/Scrum of Scrums (SoS) call.
• Medium/High concern projects: Increase communication cadence to reflect urgency and maintain stakeholder confidence.
• Champion testing readiness by sending timely reminders to testers prior to the release start, ensuring user stories and test scripts are uploaded to the correct Zephyr Release Fix Version — aligned to the matching Fix Version in JIRA.
• For non-Zephyr teams, provide clear direction by notifying testers to build their test scripts in Excel format and equipping them with the Required Testing and Test Exit Report Input document — ensuring no team is left without a clear path forward.
• Maintain a sharp eye on testing team progress, actively monitoring for any signs of slippage that could jeopardize completion timelines. Intervene early and decisively to ensure testers have the time and support needed to meet release milestones.
• Oversee defect health in JIRA — tracking aging defects, driving timely updates, and facilitating resolution with a sense of urgency. For defects tied to a Vendor or Partner fix, ensure accountability is correctly placed with the applicable Citi Developer serving as the primary point of contact.
• Establish a strong quality foundation by initiating the Test Plan Input at the first impacted Sprint — setting the tone for structured, disciplined testing from the outset.
• For Zephyr-executing teams, validate that:
• The Zephyr Release aligns with the User Stories Fix Version.
• All user stories and test scripts are successfully loaded into Zephyr and ready for execution.
• Lead the closure phase with rigor — generate the TER Readiness Checklist and take full ownership of creating the Test Exit Report (TER), a Release-level document that tells the complete story of testing performed for the project's production release.
• Leverage the JIRA TA Dashboard or targeted JIRA queries to confirm all impacted Scrum Teams are accounted for — including teams that engaged later in the project lifecycle — so that no testing effort goes undocumented or unvalidated.