Documentation

Functional Specifications

This document describes the functional requirements for the Task Manager application. It is intentionally written in the style of a real-world Software Requirements Specification (SRS) so that you can practise deriving test cases directly from business requirements — just as you would on a real project.

📋 How to use this document: Read each requirement and its acceptance criteria. Try to write test cases that verify each criterion before looking at the application. Then run your tests against both the SSR (/task-manager) and SPA (/task-manager-spa) versions — the functional behaviour is identical.

1. Scope

This specification covers the Task Manager feature of TestAuto.app. It applies to both the SSR and SPA front-end implementations and to the backend REST API (V1 and V2). The Buggy API is excluded from functional requirements — its intentional defects are described separately.

Out of scope

  • Documentation and main landing pages
  • Buggy API functional behaviour
  • Infrastructure, deployment, and technical architecture

2. Task Management

The core feature set allowing users to create, view, update, delete, and organize tasks.

2.1 View Task List

Description: The user can work with tasks in a paginated list view, and can switch to a board view for status-driven workflows.

Acceptance Criteria

  • AC-2.1.1: The task list displays the following shared management columns: Title, Due Date, Updated Date, Priority, and Status.
  • AC-2.1.2: When there are no tasks, the UI shows an empty-state message (e.g. “No tasks found”).
  • AC-2.1.3: The list is populated from the API on page load without requiring user interaction.
  • AC-2.1.4: Status and Priority values are displayed in a human-readable format (e.g. “In Progress” not “IN_PROGRESS”).
  • AC-2.1.5: The user can switch between list and board views without leaving the task-manager surface.
  • AC-2.1.6: The board view groups tasks into TODO, In Progress, and Done columns.
  • AC-2.1.7: Board cards expose the core metadata needed to manage tasks, including title, priority, labels, timestamps or due-date state, and task actions.
  • AC-2.1.8: The current search term and status filter continue to apply when the user switches to board view.

2.2 Create Task

Description: The user can create a new task from the task list by opening a modal and providing a title plus optional task details.

Acceptance Criteria

  • AC-2.2.1: A “New Task” or “Add Task” button/link is visible on the task list page.
  • AC-2.2.2: Clicking the button opens the task creation flow as a modal state without leaving the task list context.
  • AC-2.2.3: The form contains fields for Title (required), Description (optional), Status (required), Priority (required), Due Date (optional), Labels (optional), Checklist Items (optional), and Attachments (optional).
  • AC-2.2.4: The user can add and remove checklist-item rows inside the create flow before saving.
  • AC-2.2.5: Submitting a valid form creates the task and returns the user to the current list or board context.
  • AC-2.2.6: The newly created task appears immediately after the modal closes.
  • AC-2.2.7: Submitting without a title shows a validation error message on the Title field.
  • AC-2.2.8: Submitting a title longer than 100 characters shows a validation error.
  • AC-2.2.9: Default Status is “TODO” if not specified.
  • AC-2.2.10: Default Priority is “MEDIUM” if not specified.
  • AC-2.2.11: Due-date shortcuts for Today, Tomorrow, and Next Week are available in the create flow.
  • AC-2.2.12: The create flow allows the user to queue up to 3 attachments before save, with a 1 MB maximum per file.
  • AC-2.2.13: Files that exceed the attachment limit or size limit are blocked by the UI before the task is saved.

2.3 View Task Details

Description: The user can view the full details of a single task from a detail modal, and may also open a dedicated details-only page in a new tab.

Acceptance Criteria

  • AC-2.3.1: Each task row or board card provides a way to open task details.
  • AC-2.3.2: The detail view shows the task ID, title, description, status, priority, due date, labels, checklist items, attachment metadata, created date, updated date, and comments.
  • AC-2.3.3: Navigating to a non-existent task ID shows an appropriate error message (e.g. “Task not found”).
  • AC-2.3.4: Opening task details in a new tab renders a details-only surface rather than the full task-manager page.

2.4 Edit Task

Description: The user can modify any field of an existing task from the edit modal/state.

Acceptance Criteria

  • AC-2.4.1: Each task has an “Edit” action accessible from the task list or detail view.
  • AC-2.4.2: The edit form is pre-populated with the current values of all editable fields, including labels, due date, and checklist items.
  • AC-2.4.3: Saving a valid edit updates the task and returns the user to the task list or board context.
  • AC-2.4.4: The updated values are reflected in the list or board immediately after save.
  • AC-2.4.5: The same validation rules as creation apply, including title, due-date, and label validation.
  • AC-2.4.6: Cancelling the edit discards changes and returns to the previous task-manager state.
  • AC-2.4.7: The edit flow supports adding new attachments and queuing existing attachments for removal before save, using the same 3-file and 1 MB limits as creation.

2.5 Delete Task

Description: The user can permanently remove a task.

Acceptance Criteria

  • AC-2.5.1: Each task has a “Delete” action accessible from the task list or detail view.
  • AC-2.5.2: Clicking Delete shows a confirmation prompt before proceeding.
  • AC-2.5.3: Confirming deletion removes the task and it no longer appears in the list.
  • AC-2.5.4: Cancelling the confirmation leaves the task unchanged.
  • AC-2.5.5: The task count or statistics update to reflect the deletion.

2.6 Labels, Checklist Items, Comments, and Attachments

Description: Tasks support lightweight labels, embedded checklist items, file attachments, and a comment timeline for collaboration-style scenarios.

Acceptance Criteria

  • AC-2.6.1: Users can assign zero or more labels to a task during create and edit flows.
  • AC-2.6.2: Labels are shown in the task list, board cards, or detail state in a visible, readable format.
  • AC-2.6.3: Users can add and remove checklist items, and toggle checklist-item completion, during create and edit flows.
  • AC-2.6.4: Checklist items remain associated with the task after save and reload, and are visible in the detail view.
  • AC-2.6.5: Users can add, update, and delete comments from the task detail workflow.
  • AC-2.6.6: Comments display text content and remain associated with the task after reload.
  • AC-2.6.7: Users can add up to 3 attachments per task from the create and edit flows.
  • AC-2.6.8: Each attachment is limited to 1 MB, and files above that limit are rejected before upload.
  • AC-2.6.9: Saved attachments remain associated with the task after save and reload, and the detail view shows attachment name, type, size, and upload timestamp.
  • AC-2.6.10: Removing an attachment from the edit flow persists after save and reload.

2.7 Due Dates and Overdue States

Description: Tasks can optionally include a due date, and the UI exposes date shortcuts plus validation and overdue feedback.

Acceptance Criteria

  • AC-2.7.1: The create and edit flows allow an optional due date to be set or cleared.
  • AC-2.7.2: The date picker exposes Today, Tomorrow, and Next Week shortcuts.
  • AC-2.7.3: Saving a non-urgent task with a past due date shows a warning state but remains allowed.
  • AC-2.7.4: Saving an urgent task with a past due date is blocked by validation.
  • AC-2.7.5: Saving a task with a due date more than 365 days in the future is blocked by validation.
  • AC-2.7.6: Task presentations that expose due-date state can visually indicate when a task is overdue after save and reload.

3. Search and Filtering

Mechanisms to narrow the displayed task list.

3.1 Text Search

Description: The user can filter tasks by entering a search term.

Acceptance Criteria

  • AC-3.1.1: A search input is visible on the task list page.
  • AC-3.1.2: Typing in the search input filters the list to tasks whose Title, Description, or Labels contain the search term (case-insensitive).
  • AC-3.1.3: Search results update without requiring a full page reload.
  • AC-3.1.4: Clearing the search input restores the full unfiltered list.
  • AC-3.1.5: When no tasks match the search term, an appropriate message is displayed.

3.2 Status Filter

Description: The user can filter tasks by their status.

Acceptance Criteria

  • AC-3.2.1: A status filter control (e.g. dropdown) is visible on the task list page.
  • AC-3.2.2: Selecting a status shows only tasks with that status.
  • AC-3.2.3: All three statuses can be selected: TODO, IN_PROGRESS, DONE.
  • AC-3.2.4: A “All” or “Any” option resets the filter.
  • AC-3.2.5: Status filter and text search can be combined.

3.3 Filter Persistence Across Views

Description: Search and status filtering remain active as the user changes view mode or navigates between pages.

Acceptance Criteria

  • AC-3.3.1: The current search term and status filter remain active when the user switches between list and board views.
  • AC-3.3.2: Pagination in list view preserves the current search term and status filter.
  • AC-3.3.3: Board view applies the currently filtered task set before grouping tasks into status columns.

4. Sorting

The user can control the order in which tasks are displayed.

4.1 Column Sorting

Acceptance Criteria

  • AC-4.1.1: The task list supports sorting by at least: Title, Due Date, Updated Date, Priority, and Status.
  • AC-4.1.2: Clicking a column header sorts the list by that column in ascending order.
  • AC-4.1.3: Clicking the same column header again toggles to descending order.
  • AC-4.1.4: The active sort column and direction are visually indicated.

5. Pagination

When the task list is long, it is split across multiple pages.

5.1 Paginated Navigation

Acceptance Criteria

  • AC-5.1.1: The task list shows 25 tasks per page by default.
  • AC-5.1.2: Pagination controls for first, previous, next, and last page are displayed when there is more than one page.
  • AC-5.1.3: Navigating to the next page loads the next set of tasks.
  • AC-5.1.4: The previous-page controls are disabled on the first page.
  • AC-5.1.5: The next-page controls are disabled on the last page.
  • AC-5.1.6: Page information is displayed in the format “Page N of M”.
  • AC-5.1.7: The current visible item range and total task count are displayed.
  • AC-5.1.8: The user can change page size between 10, 25, 50, and 100 items per page.

6. Statistics / Scorecard

The user can see an at-a-glance summary of task counts.

6.1 Task Summary Display

Acceptance Criteria

  • AC-6.1.1: A statistics panel or scorecard is visible on the task list page.
  • AC-6.1.2: The panel shows total task count.
  • AC-6.1.3: The panel shows task count broken down by status (TODO, IN_PROGRESS, DONE).
  • AC-6.1.4: Statistics update automatically when tasks are created or deleted.

7. Authentication (V2 API / Authenticated UI)

When the application is connected to the V2 API, users must authenticate to access task data. The SSR and SPA front-ends support an optional login flow.

7.1 Login

Acceptance Criteria

  • AC-7.1.1: A “Login” button is visible to unauthenticated users.
  • AC-7.1.2: Clicking Login opens a modal state with Username and Password fields without leaving the task-manager context.
  • AC-7.1.3: Submitting valid credentials authenticates the user and grants access to task data.
  • AC-7.1.4: Submitting invalid credentials shows an error message without granting access.
  • AC-7.1.5: After successful login, a user identifier (e.g. username) is visible in the UI.

7.2 Logout

Acceptance Criteria

  • AC-7.2.1: A “Logout” action is accessible to authenticated users.
  • AC-7.2.2: After logout, the user is no longer authenticated and task data is no longer accessible.
  • AC-7.2.3: After logout, the “Login” button is visible again.

7.3 Session Persistence

Acceptance Criteria

  • AC-7.3.1: An authenticated session persists across page reloads within the browser tab.
  • AC-7.3.2: After token expiry (1 hour), the user is prompted to re-authenticate.

8. Backend API Requirements

Requirements that the REST API must satisfy, independently of the front-end.

8.1 Task CRUD via API

Acceptance Criteria

  • AC-8.1.1: GET /api/v1/tasks returns a paginated list of tasks with a 200 status.
  • AC-8.1.2: POST /api/v1/tasks with a valid body creates a task and returns 201.
  • AC-8.1.3: POST /api/v1/tasks without a title returns 400 with a descriptive error.
  • AC-8.1.4: PUT /api/v1/tasks/{id} replaces all mutable fields and returns 200 while refreshing updatedAt.
  • AC-8.1.5: DELETE /api/v1/tasks/{id} removes the task and returns 204.
  • AC-8.1.6: Task request and response payloads support labels, dueDate, and checklistItems in addition to the core task fields.
  • AC-8.1.7: POST /api/v1/tasks/{id}/comments creates a comment from a request body containing text.
  • AC-8.1.8: PUT /api/v1/tasks/{id}/comments/{commentId} updates an existing comment.
  • AC-8.1.9: DELETE /api/v1/tasks/{id}/comments/{commentId} removes a comment and returns 204.
  • AC-8.1.10: POST /api/v1/tasks/{id}/reorder moves a task within or across board columns using targetStatus and targetIndex.
  • AC-8.1.11: DELETE /api/v1/tasks clears all tasks and returns 204.
  • AC-8.1.12: Requesting a non-existent task ID returns 404.
  • AC-8.1.13: Task response payloads include an attachments array containing attachment metadata.
  • AC-8.1.14: POST /api/v1/tasks/{id}/attachments accepts multipart/form-data with one or more files parts and returns attachment metadata with 201.
  • AC-8.1.15: Attachment uploads are limited to 3 files per task and 1 MB per file; requests that exceed those limits return 400 with a descriptive message.
  • AC-8.1.16: DELETE /api/v1/tasks/{id}/attachments/{attachmentId} removes a stored attachment and returns 204.

8.2 Filtering and Sorting via API

Acceptance Criteria

  • AC-8.2.1: GET /api/v1/tasks?status=TODO returns only tasks with status TODO.
  • AC-8.2.2: GET /api/v1/tasks?search=keyword returns only tasks whose title, description, or labels contain the keyword (case-insensitive).
  • AC-8.2.3: GET /api/v1/tasks?sort=priority&direction=desc returns tasks sorted by priority descending.
  • AC-8.2.4: GET /api/v1/tasks?sort=updatedAt&direction=desc returns the most recently updated tasks first.
  • AC-8.2.5: Multiple query parameters can be combined.

8.3 Pagination via API

Acceptance Criteria

  • AC-8.3.1: The response body includes: content, totalElements, totalPages, currentPage, pageSize.
  • AC-8.3.2: ?page=0&size=5 returns the first 5 tasks.
  • AC-8.3.3: Requesting a page beyond the last page returns an empty content array (not an error).

8.4 Task Statistics

Acceptance Criteria

  • AC-8.4.1: GET /api/v1/tasks/summary returns totalTasks, todoTasks, inProgressTasks, and doneTasks.
  • AC-8.4.2: Summary counts are consistent with the full task list.

8.5 V2 Authentication

Acceptance Criteria

  • AC-8.5.1: POST /api/v2/auth/login with valid credentials returns a JWT token with a 200 status.
  • AC-8.5.2: POST /api/v2/auth/login with invalid credentials returns 401.
  • AC-8.5.3: All /api/v2/tasks/* endpoints require a valid Bearer token; missing or invalid tokens are rejected by the security layer.
  • AC-8.5.4: A token is valid for exactly 3600 seconds from issue time.
  • AC-8.5.5: POST /api/v2/auth/refresh with a valid refresh payload issues a new token and returns 200.
  • AC-8.5.6: DELETE /api/v2/tasks is restricted to ADMIN users.

9. Non-Functional Requirements

9.1 Performance

  • NF-9.1.1: The task list page loads within 2 seconds on a standard broadband connection.
  • NF-9.1.2: API responses (V1 and V2) return within 200 ms under normal conditions.

9.2 Usability

  • NF-9.2.1: The application is usable on common viewport sizes (desktop, tablet, mobile).
  • NF-9.2.2: All form fields have visible labels.
  • NF-9.2.3: Error messages are descriptive and indicate how to correct the input.

9.3 URLs and Navigation

  • NF-9.3.1: The SSR Task Manager is accessible at /task-manager.
  • NF-9.3.2: The SPA Task Manager is accessible at /task-manager-spa.
  • NF-9.3.3: Direct URL navigation to these routes works without error.
  • NF-9.3.4: Dedicated task details routes are available at /task-manager/details/{id} and /task-manager-spa/details/{id}.
PreviousTest ExercisesNextDocumentation Home