• Coding,  Testing

    e-API Dashboard Document

    Introduce

    The document that mentioned on eAPI Dashboard details and guideline, this is the reality API with the common methods, it will support and help testers to work and practice on the APIs.

    These APIs are publicly and support for the testing purposes only. Do not submit the real and sensitive information.

    If you have any questions, please feel free to drop me a message via [email protected], I appreciate your feedback, contributing and ideas.

    • Homepage: https://sangbui.com/api/index.php
    • API Endpoint: https://sangbui.com/api/v1/employees

    1. Get all employees data

    This API will retrieving all employees data from the table and return information that included name, salary and age.

    URL https://sangbui.com/api/v1/employees
    Method GET
    URL Params <none>
    Header Content-Type: application/json

    Authorization: Basic d2ViX2FwcDpjaGFuZ2VpdA==

    Data Params <none>
    Success Response Code: 200 OK

    Content:

    [

        {

            “id”: “<id>”,

            “employee_name”: “<name>”,

            “employee_salary”: “<salary>”,

            “employee_age”: “<age>”

        },

    {

            “id”: “<id>”,

            “employee_name”: “<name>”,

            “employee_salary”: “<salary>”,

            “employee_age”: “<age>”

        }

    ]

    Error Response Code: 404 Not Found
    Sample Call <none>
    Notes <none>

  • Testing

    Cách viết một bug report tốt

    Report bug là công việc thường xuyên và liên tục của một người làm test, nhưng đã bao giờ bạn nghĩ mình có thể làm gì để một bug report trở nên hoàn chỉnh, ngắn gọn cũng như thể hiện sự chuyên nghiệp và rõ ràng trong từng report được gởi ra cho Dev?

    Bài này mình chia sẻ những kinh nghiệm của bản thân trong việc viết một bug report hy vọng sẽ giúp ích cho các bạn.

    Một mẫu report bug tham khảo:

  • Testing

    Mối liên hệ giữa priority và severity trong quản lý bug

    Short: Severity & Priority không có mối liên hệ gì cả.
    —-
    Long: 
    Severity: Chỉ mức độ ảnh hưởng sẽ gây nên cho hệ thống (hoặc người dùng) khi có lỗi xảy ra. Các mức cơ bản:
    – Critical
    – Major
    – Moderate
    – Low (or Minor)

    Priority: Định nghĩa thứ tự sẽ xử lý / fix lỗi đó. Lỗi có độ ưu tiên cao hơn sẽ được sửa trước. Các mức cơ bản:
    – Priority 1 – Critical
    – Priority 2 – High
    – Priority 3 – Medium
    – Priority 4 – Low

    Có bạn nghĩ hai cái này có sự liên quan nhau, ví dụ lỗi có ảnh hưởng cao sẽ nên fix trước hoặc lỗi ảnh hưởng thấp sẽ có ưu tiên thấp nhưng không phải vậy. Mình sẽ có 4 ví dụ để cho thấy nó không liên quan.