Student forms

Parity: 15 of 15 scenarios

Each scenario was recorded on the original and replayed against the migrated app. Three runs from a fresh database gave byte-identical diffs for every scenario; none has a defect. Open a scenario for its steps, screenshots of both apps, the golden record, the diff and its waivers.

• Match: the same value. Tolerated: different only within a written rule of the tolerance policy, here the audit dates a save stamps with today's date, and list-of-values rows the Forms client had not fetched yet.
• Waived: 1 waivers are proposed for the customer's decision; 1 of them cover 5 values here, where the migrated app deliberately does not copy the original (see waivers).
• Defect: a difference to repair. Unmapped: none; every recorded value has a counterpart in the migrated app.

The same app with an Angular front end: 15 of 15

The check does not depend on what the new interface is built with. This app has a second front end written in Angular on the same back end and API, and the same scenarios, mapping, tolerance policy and waivers check it: 15 of 15 scenarios at parity, 0 defects, three runs from a fresh database byte-identical, and every diff byte-identical to the default front end's.

The app is also rebuilt from native APEX components on its original Oracle schema, checked with the same scenarios: the APEX version.

Faithful to the original

The migrated app copies the original's behaviour, including what looks like a bug. These are the places a visitor will notice.

The interface is new; the behaviour is the original's, and the scenarios check it value by value. Some of that behaviour looks like a bug on a web page. It is kept on purpose, because the point of the demo is that nothing changed:

• Adding a student never saves. In the Students window of QAFE_FORM2, Save stops at FRM-40600: Record has already been inserted. The block's primary key, STUDENT_ID, is required but on no canvas and set by no trigger, so Forms' own key check refuses every new row before it reaches the database.
• Emptying a student's first name fails on Save with FRM-40509: ORACLE error: unable to UPDATE record. The form has no check; a database trigger on STUDENT raises the error, as in the original schema.
• Courses cannot be deleted in QAFE_FORM2: Remove Record answers FRM-41049: You cannot delete this record., because the block does not allow deletes.
• A section's course number overwrites the course. In QAFE_FORM3, typing an existing course number into a section copies it into the course shown above (the original's validation trigger fetches into the master block's item). An unknown number gives "This course does not exist in the database."
• A course cost below 5 is refused with "Course cost has to be greater than 5".
• Lists come in storage order, not sorted. No block has an ORDER BY, so courses, instructors and students appear in the order the database stores them: the student list starts with Yvonne Allende (student 385), as in the original database.
• Audit dates have no time of day. The forms assign SYSDATE to date items, which drops the time, so created and modified dates are stored as midnight.
• Oracle message texts on a PostgreSQL app. FRM-40400: Transaction complete, FRM-40350: Query caused no records to be retrieved, FRM-40100: At first record and the other FRM messages are the original's, and the message line is part of the recorded behaviour. Moving the cursor clears it, as in Forms.
• Each form runs on its own, as the three original modules do; the start page lists them.

The original's Java client also announces the course number for screen readers when the cursor reaches it ("Course No.454"). That text is not on the screen; the browser leaves announcements to the screen reader (waiver S1).

Coverage of the original

Every trigger and program unit of the Forms modules, measured with Forms Runtime Diagnostics while the scenarios ran; database PL/SQL measured with DBMS_PLSQL_CODE_COVERAGE.

Decision branches: 14, of which 10 covered, 4 unreachable (retirement candidates) and 0 blocked. Database PL/SQL: 10 unit(s) in the coverage report, 2 of 3 blocks covered. Exit check: PASS.

Waivers

Source behaviour a customer would probably not replicate, proposed for the customer's decision. Each is pinned to the exact values it covers; the counts are values waived in the final diffs. File: waivers.yaml.

Waived: 1 waivers are proposed for the customer's decision; 1 of them cover 5 values here, where the migrated app deliberately does not copy the original (see waivers).