6 videos 📅 2025-03-19 09:00:00 America/Bahia_Banderas
1:38
2025-03-19 13:02:19
5:09
2025-03-20 09:04:50
1:01:32
2025-03-20 09:32:49
4:31
2025-03-20 09:35:15
31:01
2025-03-20 10:19:57
17:34
2025-03-20 15:02:37

Course recordings on DaDesktop for Training platform

Visit NobleProg websites for related course

Visit outline: Agile Software Testing (Course code: agilesofttest)

Categories: Scrum · Software Testing

Summary

Overview

This course session is a hands-on technical workshop focused on setting up and testing a .NET-based web application with Docker and Docker Compose, followed by API interaction via Postman and frontend login form validation. The session transitions from environment configuration to functional testing practices, introducing unit testing concepts. Participants are guided through container setup, API execution, manual API testing, UI interaction, and collaborative requirement gathering for test scenarios, with an emphasis on roles (tester, developer, product owner) in agile workflows.

Topic (Timeline)

1. Environment Setup and Container Recreation [00:00:00 - 00:03:05]

  • Participants are instructed to download a new project folder and delete existing Docker containers to recreate them with the updated content.
  • Emphasis is placed on ensuring Docker Compose is executed from the correct directory where the docker-compose.yml file resides, regardless of its location on the filesystem.
  • Trainer confirms participants have Docker installed and checks for firewall or corporate restrictions that may block downloads.
  • Guidance is given to replace the old project folder with the new one (e.g., from Desktop), ensuring path consistency for Docker Compose execution.

2. API Execution and .NET Container Navigation [00:03:16 - 00:07:04]

  • Trainer guides participants into the .NET container and navigates to the msdemo subdirectory containing the application code.
  • Participants are instructed to execute a sequence of commands (lines 86–92 from a cheat sheet): cleaning obj and bin folders, restoring NuGet packages, rebuilding the project, and running dotnet run.
  • The application is configured to run on localhost:5000 inside the container; the port is exposed externally to allow access from the host machine.
  • The health check endpoint (/api/health) is accessed via browser to confirm the backend is running successfully.

3. API Testing with Postman and Manual Validation [00:07:04 - 00:09:39]

  • Participants are asked to test the login API endpoint using Postman.
  • A pre-configured Postman request (likely a POST to /api/login) is shared via code share and imported.
  • Test inputs are manually entered: valid credentials (e.g., admin:12345), empty fields, and invalid formats to observe responses.
  • Trainer confirms all participants successfully interacted with the API and received appropriate HTTP responses (e.g., 400 for missing fields).

4. Frontend Login Form Interaction and UX Observations [00:09:39 - 00:13:03]

  • Participants access the frontend login UI at localhost:5000/login.
  • The form includes email and password fields with basic styling; submission triggers backend validation.
  • A UI bug is observed: an unexpected “define” message appears instead of a user-friendly validation prompt.
  • Trainer uses this as a teaching moment to highlight the importance of user experience and clear feedback during form submission.

5. Functional and Non-Functional Test Scenario Brainstorming [00:13:03 - 00:21:03]

  • Participants engage in a collaborative exercise to propose test cases for the login form, categorizing them as functional or non-functional.
  • Key functional test ideas identified:
    • Prevent submission with empty fields (functional).
    • Validate email format (functional).
    • Validate password requirements (e.g., length, complexity).
  • Debate arises on whether validation should occur on frontend, backend, or both — consensus is that both layers must validate for security and UX.
  • Trainer notes that frontend validation improves UX, but backend validation is mandatory for security.
  • A failed frontend validation is documented as a bug to be assigned to a developer.

6. Role-Based Requirement Ownership and Stakeholder Dynamics [00:21:04 - 00:25:05]

  • Discussion on who owns the definition of user-facing messages (e.g., “Email is required” vs. “Please enter your email address”).
  • Product Owner / Project Manager (Sergio) is identified as the stakeholder responsible for finalizing user message wording.
  • Roles are explicitly assigned: Sergio as Product Owner, others as Developers/Testers, with rotation encouraged.
  • Emphasis is placed on aligning testing activities with agile practices: requirements are captured as user stories, tracked on a board, and derived from real-world observations and common sense.

7. Introduction to Unit Testing and Caja Negra Concept [00:25:05 - 00:31:01]

  • Trainer introduces unit testing as a form of functional testing focused on isolated code units (methods, classes).
  • Unit tests are described as “black box” tests: they care only about inputs and outputs, not internal implementation.
  • The .NET object-oriented paradigm is referenced, with emphasis on testing entities like controllers, services, and models.
  • Unit tests are framed as separate programs that invoke application code and assert expected outcomes.
  • Session concludes with a planned 5-minute break before diving into creating and executing unit test projects.

Appendix

Key Principles

  • Layered Validation: Input validation must occur on both frontend (UX) and backend (security).
  • Black Box Testing: Unit tests evaluate behavior via inputs/outputs, not internal logic.
  • Role Clarity: Product Owner defines user-facing requirements; developers implement; testers validate.

Tools Used

  • Docker / Docker Compose
  • .NET CLI (dotnet run, dotnet restore, dotnet build)
  • Postman (for API testing)
  • Browser (for frontend interaction)
  • Code share (for command distribution)

Common Pitfalls

  • Running docker-compose up from the wrong directory → container fails to start.
  • Relying solely on frontend validation → security vulnerability.
  • Assuming backend validation messages are sufficient for end users → poor UX.

Practice Suggestions

  • Practice recreating containers from scratch with different project locations to reinforce path awareness.
  • Write 3 unit test cases for a simple login service: valid credentials, empty fields, invalid email.
  • Simulate stakeholder meetings: assign roles and debate message wording for validation errors.
  • Use Postman to test edge cases: special characters in email, very long passwords, missing headers.