Inactive

** 4/25/23 -RFI-ARC-23-058 has been amended due to a Question. See uploaded Attachment (Amendment 1) for Amendment 1. The closing period remains the same ** REQUEST FOR INFORMATION Automated Testing a... ** 4/25/23 -RFI-ARC-23-058 has been amended due to a Question. See uploaded Attachment (Amendment 1) for Amendment 1. The closing period remains the same ** REQUEST FOR INFORMATION Automated Testing and Application Lifecycle Tools INTRODUCTION AND BACKGROUND This is a Request for Information (RFI) issued by the U.S. Department of the Treasury, Bureau of the Fiscal Service (BFS). The purpose of the RFI-ARC-23-058 notice is to identify potential solutions for Automated Testing and Application Lifecycle Tools. The information is being sought for informational and acquisition planning purposes. Scope and Objective Our technology divisions in ARC currently perform all patch and upgrade testing through manually performed test scripts. We are aiming to put some applications in place to enable automated testing for highly reusable scripts, and then track the status of all involved tests through a lifecycle management tool. In support of ARC’s mission, BFS seeks to identify commercial off the shelf (COTS) solutions that would perform to the needs of the User Stories below: User Stories: An internal GS-12 analyst needs to be able to quickly create test scripts in a tool to accomplish all identified testing as part of specific events like upgrades, monthly patching, and project-based development in a suite of ARC applications including Oracle E-Business Suite, PRISM, Salesforce, and OneStream applications. To quickly make a test script database, the tool needs to be able to record his testing steps and then output a file that can be ran at any point in the development cycle to make sure functionality developed passes. On scripts where multiple pieces of data are needed, a parameter input to provide intake values is needed. A GS-12 Testing analyst is required to use SSO to login to our Oracle instance. We currently use PIV cards for all SSO operations. The application must be able to utilize a SAML assertion to login to applications also to meet presidential memos on Zero Trust Architecture. A GS-13 tool administrator, is part of the project team for our Procurement system upgrade. During the project plan, she must be able to perform load testing and stress testing (up to 5000 users) with a subset of identified procurement system scripts that have already been developed. A developer in our Oracle development group, has a constant need to be able to run module test scripts after he makes a change to the Oracle CEMLI logic. Since our development group is a JIRA shop for tracking developments, he needs to be able to leverage automated testing from a JIRA story. Failed tests must report back the specific fail to the JIRA story. This helps to establish our DevSecOps posture for the future. A GS-13 Project Manager for a recent PRISM upgrade, has requested pass/fail statistics on all testing performed during the project. She needs to be able to access either in Dashboard view, or report form, metrics related to the identified tests which show successes and failures for each identified test performed. If dashboards are available, the ability to dive into the failures to explore the reasons for failure is needed. This data should also be able to be exported to a standard CSV format to be pulled into enterprise dashboards. Also, to confirm all test status, the console of the testing application must be able to easily identify failed scripts and the exact steps that failed. The GS-13 tool administrator above, needs to schedule tests for a newly identified emergency patch. She should be able to select any number of previously developed test scripts into a test plan. This test plan should be able to be scheduled or started immediately on demand. She should not have to be present if the schedule must occur after hours due to this critical event. Tests that are ran after hours and fail, should have the ability to notify an email address. These test plans should be able to be reused throughout the tool's lifetime. A GS-12 Testing Analyst needs to also perform some manual tests each cycle, that have little to no reusability. These manual tests should be able to be input into the tools tracking mechanism and identified in specific test plans with the identified automated scripts to give us an entire Lifecycle management report on testing. Manual tests should identify the individual who performed the test and pass/fail results included in an overall Lifecycle Management testing report. We should have the ability to upload a manual testing form as proof of the created event. A GS-12 IT Specialist wants to work closely with the test team to understand their testing requirements, so that they can deliver high-quality database changes that meet their needs. While also, providing the test team with clear and concise documentation that explains how to test database changes effectively. A GS-12 IT Specialist wants to collaborate with the test team to establish performance testing procedures that ensure that database changes are scalable and performant. Secondly, he wants to provide the test team with access to the database schema and data, so that they can test their changes against realistic data. A GS-13 Senior IT Specialist wants to work with the test team to establish automated testing procedures that can be integrated into our CI/CD pipeline, so that we can deliver high-quality database changes to production quickly and reliably. An external contracted developer needs to be able to quickly access and understand all the documentation and required controls & tools for the changes they are developing. Tooling should include end user training to prevent custom creation of knowledgebase content. An IT Specialist supervisor want to work with the test teams to identify and remediate any database-related issues that arise during testing, so that we can deliver a quality product to production. A Branch Manager wants to establish a secure development lifecycle (SDL) process, so that he can ensure that security is integrated into every stage of the software development process and that his databases are protected against cyber threats and meets all required controls. Other Minimum requirements are as follows: Tool must be able to pass a SAML assertion through our single sign on applications. Tool must be able to perform automated testing through JAVA forms SUBMISSION GUIDELINES Vendor responses to this RFI shall include sufficient evidence that clearly demonstrates the respondent’s interest and capability to satisfy the scope and objectives outlines above. Responses shall include a general capabilities statement that includes a description of their standard line(s) of business, information outlining their experience, and technical narrative addressing the specific requirements. All User Stories on the RFI shall be answered to by vendors. Responses shall be no greater than 5 pages using font size no smaller than 10, inclusive of any tables, pictures, or diagrams that identifies their: Contact information, Socio Economic Status(es) (Business Size) Capabilities of their organization and key personnel (project manager(s)) to perform the work described in the “User Stories”, and Their existing Government-Wide Contract Vehicle number and SIN Categories/Pool Number. (e.g. GSA Schedule 00CORP contract, OASIS) Responses submitted will assist the Government in its market research to determine the availability of commercial sources in determining an acquisition strategy in terms of setting aside this requirement. In order for Fiscal Service to assess set-aside possibilities, interested parties shall also identify their socio economic status(es) based on the following in their capability statement: 1) small business; 2) 8(a) business; 3) HUBZone small business; 4) small disadvantaged business; 5) woman-owned small business; 6) economic disadvantage women-owned small business; 7) veteran-owned small business; 8) service-disabled veteran-owned small business, or 9) large business under each of their GWACs. No pricing is being requested or will be considered at this time. This is only a request for information for determining an acquisition strategy. No other information regarding this RFI will be provided at this time. All electronic materials and attachments submitted shall be formatted in accordance with the Bureau of the Fiscal Service’s Security Requirements. The following file extensions are not allowable and application materials/data submitted with these extensions cannot be opened: .bat, .cmd, .com, .exe, .pif, .rar, .scr, .vbs, .hta, .cpl, html, mhtml, and .zip files Microsoft Office non-macro enabled compatible documents are acceptable. If the interested vendor determines that other formats are necessary, it is the interested vendor’s responsibility to verify with Fiscal Service that those formats are acceptable. The Government does not allow 3rd party messaging systems/secure mail DEADLINE FOR RESPONSES Vendors shall submit responses to this RFI by e-mail to purchasing@fiscal.treasury.gov no later than Friday, May 5th, 2023 at 1:00pm Eastern time. Responses shall reference “Response to RFI-ARC-23-058 ATTN: CA/RG” in the subject line of the e-mail message. DISCLAIMERS This RFI is not a request for proposal/quote, and this request does not imply an obligation on the part of the Government to purchase products/services or to proceed to any request for proposal/quotation for such products/services. Further, this RFI does not obligate the Government to ultimately pursue a particular acquisition strategy. The Government will not be liable for any costs incurred by vendors in preparing and submitting a response to this RFI. Submission of a response confers no rights upon the responder. NO FORMAL SOLICITATION IS AVAILABLE. Requests for additional information and/or a copy of the solicitation will not be considered an affirmative response to this posting. Telephone responses or inquiries to this RFI will not be accepted. All responding vendors are advised that responses to this notice, in and of themselves, will in no way be considered for contract award. In the event that a resultant solicitation would ensue, interested parties would be required to respond separately and formally in order to be considered for contract award. Additionally, a determination not to compete the proposed acquisition based upon responses to this request would be at the sole discretion of the Government.