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, and delete tasks.

2.1 View Task List

Description: The user can see all tasks in a tabular format, and can switch to a board view for status-driven workflows.

Acceptance Criteria

  • AC-2.1.1: The task list displays the following columns: Title, Status, Priority, Created Date.
  • 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 to a board view that groups tasks into TODO, In Progress, and Done columns.

2.2 Create Task

Description: The user can create a new task from the task list by opening a create modal and providing a title and optional 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: Title (required), Description (optional), Status (required), Priority (required), Labels (optional).
  • AC-2.2.4: Submitting a valid form creates the task and returns the user to the task list context.
  • AC-2.2.5: The newly created task appears in the task list immediately after the modal closes.
  • AC-2.2.6: Submitting without a title shows a validation error message on the Title field.
  • AC-2.2.7: Submitting a title longer than 200 characters shows a validation error.
  • AC-2.2.8: Default Status is “TODO” if not specified.
  • AC-2.2.9: Default Priority is “MEDIUM” if not specified.

2.3 View Task Details

Description: The user can view the full details of a single task from a detail modal/state.

Acceptance Criteria

  • AC-2.3.1: Each task row or board card provides a way to open task details or editing.
  • AC-2.3.2: The detail view shows all task fields: ID, Title, Description, Status, Priority, Labels, 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”).

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 fields.
  • 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 (AC-2.2.6, AC-2.2.7).
  • AC-2.4.6: Cancelling the edit discards changes and returns to the previous task-manager state.

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 and Comments

Description: Tasks support lightweight labels 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, update, and delete comments from the task detail workflow.
  • AC-2.6.4: Comments display text content and remain associated with the task after 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 Priority Filter

Description: The user can filter tasks by priority level.

Acceptance Criteria

  • AC-3.3.1: A priority filter control is available.
  • AC-3.3.2: Selecting a priority shows only tasks with that priority.
  • AC-3.3.3: All priority values can be selected: LOW, MEDIUM, HIGH, URGENT.
  • AC-3.3.4: Priority filter can be combined with status filter and text search.

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, Status, Priority, Created Date.
  • 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 a maximum of 20 tasks per page by default.
  • AC-5.1.2: Pagination controls (previous, next, page numbers) 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” control is disabled or hidden on the first page.
  • AC-5.1.5: The “next” control is disabled or hidden on the last page.
  • AC-5.1.6: The current page number is visually highlighted.
  • AC-5.1.7: Total task count and page info (e.g. “Page 1 of 3”) are displayed.

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 or navigates to a login form with Username and Password fields.
  • 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: POST /api/v1/tasks/{id}/comments creates a comment from a request body containing text.
  • AC-8.1.7: PUT /api/v1/tasks/{id}/comments/{commentId} updates an existing comment.
  • AC-8.1.8: DELETE /api/v1/tasks/{id}/comments/{commentId} removes a comment and returns 204.
  • AC-8.1.9: Requesting a non-existent task ID returns 404.

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?priority=HIGH returns only tasks with priority HIGH.
  • AC-8.2.3: GET /api/v1/tasks?search=keyword returns only tasks whose title, description, or labels contain the keyword (case-insensitive).
  • AC-8.2.4: GET /api/v1/tasks?sort=priority,desc returns tasks sorted by priority descending.
  • 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 total count plus breakdown by status and priority.
  • 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/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 token issues a new token and returns 200.

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.
PreviousTest ExercisesNextDocumentation Home