Data Entry Validation Guidelines


FieldValue
Version1.0
Effective DateApril 2026
Review CycleAnnual
Document OwnerChief Information Security Officer (CISO)
ClassificationCONFIDENTIAL — Internal Use Only
Applicable StandardSOC 2 Type II — Security, Availability, Confidentiality

1. Purpose and Scope

This document establishes detailed procedures and guidelines for all data entry into QA Touch and defines the validation rules applied at each point of entry to ensure data integrity, completeness, and accuracy throughout the platform. It applies to all users and automated systems interacting with QA Touch via the web UI, REST API, or file import workflows, and supports SOC 2 Processing Integrity criteria.

2. Data Entry Channels

ChannelUser PopulationApplicable Validation Tier
Web Application UIAll authenticated workspace usersClient-side validation (UX) + mandatory server-side validation
REST APIDevelopers, automation engineers, CI/CD systemsServer-side validation only (mandatory); client-side N/A
Excel / CSV File ImportAdmins and users with import permissionFile-level, column-level, and row-level validation
Integration Sync (Jira, ADO, etc.)Automated integration connectorsPayload schema + field mapping validation
AI Feature Input FieldsUsers submitting prompts or uploading BRDs / imagesText length limits; file type and size validation; content moderation [VERIFY]
Webhook Inbound PayloadsExternal CI/CD or third-party systemsHMAC authentication + JSON schema validation

3. Universal Validation Rules

Validation TypeRule DescriptionLayerQA Touch Example
Required FieldMust be present and non-null/empty.Client + ServerTest Case Title; Defect Title; Project Name; Tester email
Maximum LengthString must not exceed defined max character count.Client + ServerTest Case Title: 255 chars; Step description: 5,000 chars; Comment: 10,000 chars
Minimum LengthString must meet minimum character count.ServerPassword: 12 chars minimum; API key name: 3 chars minimum
Data TypeValue must match declared type.ServerPriority: integer enum; Due date: ISO 8601; Workspace ID: UUID v4
Enum / PicklistValue must be within a predefined set.Client + ServerPriority: Low/Medium/High/Critical; Status: Draft/Active/Deprecated
Date FormatDates must match ISO 8601 (YYYY-MM-DD) or locale setting.Client + ServerTest Run start/end dates; Milestone due date; Created/Updated timestamps
Email FormatMust match RFC 5322 pattern.Client + ServerUser account email; notification recipient; integration contact email
URL FormatMust be a valid HTTP/HTTPS URL.ServerWebhook endpoint URL; integration base URL
UUID FormatMust be a valid UUID v4.ServerWorkspace ID, Project ID, Test Case ID in API path parameters
Range CheckNumeric value within defined min/max bounds.ServerCustom numeric fields: admin-defined min/max at field creation
UniquenessValue must be unique within defined scope.ServerProject name: unique per workspace; User email: unique across platform
Referential IntegrityFK reference must point to an existing record in same workspace.ServerTest Case in a Test Run must exist in the same project
Cross-Field ConsistencyField combination must be logically valid.ServerRun end date ≥ start date; Defect fix version ≥ affected version
File TypeUploaded file MIME type and extension must be in allowed list.ServerAttachments: jpg, png, gif, pdf, xlsx, csv, zip; AI input: jpg, png, pdf
File SizeFile must not exceed maximum size.ServerAttachments: 20 MB [VERIFY]; Import files: 10 MB [VERIFY]; AI uploads: 10 MB [VERIFY]
XSS SanitisationHTML/script tags stripped from text fields via allowlist sanitiser.ServerDescriptions, comments, step action/expected result fields
SQL Injection PreventionParameterised queries enforced for all DB operations.Server (ORM)All create/update/delete operations through ORM layer
EncodingAll text normalised to UTF-8.ServerHandles international characters in test names, comments, descriptions

4. Entity-Specific Validation Rules

4.1 Test Cases

  • Title: required; 1–255 characters.
  • Steps: at least one step required; each step must have both Action and Expected Result fields populated.
  • Priority: required; one of [Low, Medium, High, Critical]; default Medium.
  • Status: required; one of [Draft, Active, Deprecated]; default Draft.
  • Custom Fields: validated against the field type, allowed values, and constraints defined by the workspace admin.

4.2 Test Runs

  • Test Plan reference: required; must point to an existing Test Plan in the same project.
  • Step result: on submission, must be one of [Pass, Fail, Blocked, Not Run, In Progress].
  • Execution comment: optional; maximum 10,000 characters; sanitised for XSS.
  • Linked defects: referenced defect IDs must exist within the same workspace.

4.3 Defects

  • Title: required; 1–255 characters.
  • Severity: required; one of [Critical, Major, Minor, Trivial].
  • Status: required; one of [Open, In Progress, Fixed, Closed, Reopened].

4.4 User Accounts

  • Email: required; RFC 5322 format; unique across the entire QA Touch platform.
  • Password: minimum 12 characters; complexity: uppercase, lowercase, number, special character [VERIFY policy specifics].
  • Role: must be a valid role defined in the workspace RBAC configuration.

4.5 AI Input Fields

  • Prompt text: maximum character limit enforced (assumption: 4,096 tokens / ~16,000 characters [VERIFY]).
  • Uploaded file for AI: MIME type validated (jpg, png, pdf); maximum 10 MB [VERIFY].
  • Prompt content: transmitted to LLM provider over TLS; stored per AI retention policy [VERIFY].

5. Import-Specific Guidelines

  • Users must download and use the current QA Touch import template; older template versions generate a warning on upload.
  • Date columns: must be formatted as YYYY-MM-DD or MM/DD/YYYY per workspace locale setting.
  • Boolean fields: True/False or 1/0 values only; any other value causes row rejection.
  • Empty rows are silently skipped; they do not contribute to the error rate threshold.
  • After processing, users receive an import summary: records imported, records skipped, records with errors, plus a downloadable row-level error report.

6. Validation Failure Responses

ScenarioUser-Facing ResponseSystem Behaviour
Missing required field (Web UI)Red border + inline error message below fieldForm submission blocked; no API request sent to server
Invalid format (Web UI)Inline: ‘Invalid email format’ or ‘Date must be YYYY-MM-DD’Form submission blocked; corrective hint displayed
Missing required field (API)HTTP 422 with JSON: {field: 'title', message: 'Title is required'}Record not created; error logged with user ID and timestamp
Invalid enum value (API)HTTP 422: ‘priority must be one of [Low, Medium, High, Critical]‘Record not created; error logged
Import row validation failureRow listed in error report with row number and reasonValid rows processed; invalid rows excluded; user can fix and re-import
File type not accepted’Only .xlsx and .csv files are supported for import’Upload rejected immediately before any processing begins
File exceeds size limit’File exceeds the 10 MB maximum size limit’Upload rejected; no partial storage
Referential integrity failureHTTP 422: ‘Referenced project does not exist in your workspace’Record not created; error logged
Rate limit exceededHTTP 429 with Retry-After headerRequest rejected; client should retry after indicated delay