Process: US Recharged Functional

Complete workflow from requirement to release. Two areas, clear perimeters, zero gray areas.

QA defines and validates the functional Dev review, build and release

Complete flow — 8 steps

💡

1Functional requirement

The functional requirement is translated into what is needed and why.

📋

2US Recharged FunctionalQA Area

QA area puts together the complete functional specification. No code, no architecture.

→Objective and scope
→Out of scope
→Expected behavior, step by step
→Visible preconditions
→Measurable acceptance criteria
→Functional exceptions by role
→Visible UI rules (maxlength, tooltips, cursors, styles, typography, sizes)
→Responsive criteria and breakpoints
→Functional rules (filters, sorting, pagination)
→Exact error messages
→Component states (hover, disabled, loading, error)
→Iconography and grids
→Writing functional test cases
→QA checklist

🔍

3Review and IterationDevelopment Area

Dev Area reviews the US and corrects it together with QA Area until it is complete.

→Functional gaps detection
→Logic and ambiguity correction
→Technical constraints validation
→Data impact assessment
→Acceptance criteria adjustment
→Technical feasibility confirmation

↩Feedback: return to the functional user story for corrections (iterative cycle until approval)

⚡

4Prompt / Deployment with AIDevelopment Area

With the US approved, the Dev Area prompts and builds.

🧪

5Technical testingDevelopment AreaQA Area

Validation of the implementation at a technical level.

→Technical business logic
→Data integrity and persistence
→API and service integration
→Security (OAuth, tokens, rate limits)
→Edge cases
→Performance and load
→Technical regression

✅

6Functional testingQA Area

Validation against US approved. The visible, what the user sees and touches.

→The main flow works end to end
→Fields accept/reject the defined values
→Maxlength is respected in every field
→The cursor starts in the expected position
→No erratic cursor jumps
→Tooltips appear when expected
→Visual style matches the specification
→The correct iconography is used
→Filters and sorting work visually
→Pagination behaves as expected
→Cross-browser validation
→No breakage on mobile/tablet
→Error messages match the specification
→Buttons and actions respond correctly
→Run the test cases written in the user story
→All acceptance criteria are met

🔧

7SettingsDevelopment Area

Deviations found in testing are corrected.

↩Feedback: return to functional testing to revalidate the changes

🚀

8Release

The functionality is released.

Perimeters — responsibility by area

QA Area

→Functional objective and scope
→Expected behavior (user step by step)
→This text could not be loaded.
→Functional test cases
→Visible rules: maxlength, tooltips, cursors, styles
→Typography, sizes, iconography
→Responsive criteria and breakpoints
→Functional exceptions (e.g., superadmin skips validation X)
→Pagination, filters, and sorting at the UI level
→Text of error messages
→Component states (hover, disabled, loading, error)
→Run test cases against the user story
→Complete manual functional validation

Outside scope

✗Gherkin / pseudocode
✗Architecture / API / SQL
✗Deep security (OAuth, tokens, state)
✗Technical performance
✗Logs / internal persistence
✗AI prompts / decisions

Dev Area

→Capture the functional requirement
→Review and iterate on the user story with QA
→Define architecture and stack
→Prompt and build with AI
→Technical business logic
→Data integrity and persistence
→Security (OAuth, tokens, rate limits)
→Complete technical testing
→Edge cases
→Fix deviations after testing
→Release

Outside scope

✗Write technical Gherkin
✗Define technical Definition of Ready
✗Evaluate logs or performance
✗Decide on auth flows
✗Validate data persistence

Template — US Reloaded Functional (step 2)

QA Area Deliverable

1. Definition

→Clear, concise title

2. Expected behavior

→Step by step from the user's perspective
→What they see, touch, and what happens
→Functional exceptions
→Visible preconditions

3. Visible Rules/UI

→Maxlength per field
→Expected data types
→Tooltips and helper text
→Cursors and initial cursor position
→Styles, typography, sizes
→Iconography
→Grids and responsive breakpoints
→Component states (hover, disabled, loading, error)

4. Functional rules

→Visible filters (AND/OR, ascending/descending)
→Pagination criteria
→Default sort order
→Exceptions by role (superadmin, etc.)
→Exact error messages
→State combinations

5. Acceptance criteria

→Measurable and verifiable
→In plain language, not Gherkin
→The field X accepts a maximum of 50 characters
→When filtering by date, results are sorted in descending order
→On mobile, the menu collapses into a hamburger menu

6. Functional test cases

→Cases for the main flow (happy path)
→Field validation cases
→Predictable error cases
→Responsive cases
→Role-exception cases
→Filter, sorting, and pagination cases

7. QA Checklist

→Visible validations to execute
→Fields, tooltips, cursors
→Styles and iconography
→Responsive behavior on key devices
→Messages and component states

8. Mockup/visual evidence

→Screenshots, wireframes, Figma
→Annotated screenshots
→Prototypes or flow diagrams
→Visual reference for the expected result

QA Area participate in step 2 and step 6.
Functional specification at startup. Functional validation at the end.

Dev Area manage steps 1, 3, 4, 5, 7 and 8.
Requirement, review and iteration, construction, technical testing, adjustments and release.

Feedback loops between steps 3↩2 and 7↩6 ensure lock-free quality.
Each area operates within its perimeter. No gray areas.