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>

2. Get an employee by ID

This API will retrieving one employee by the employee_id, the response data will show all details of that ID.

URL https://sangbui.com/api/v1/employees/<employee_id>
Method GET
URL Params <employee_id>
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>”

    }

]

Error Response Code: 404 Not Found
Sample Call http://localhost/employee_api/v1/employees/1
Notes In our database, the employee_id from 1 to 15 will be stable and will not removed, so you can use these IDs for testing and get the sample data.

3. Add new employee

This API will suport for adding the new employee to the database. The employee_id will be auto increment.

Check the new submitted records at the home page. It will show 10 latest records and all value from the employee table.

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

Authorization: Basic d2ViX2FwcDpjaGFuZ2VpdA==

Data Params {

  “employee_name” : “<name>”,

  “employee_salary”: “<salary>”,

  “employee_age”: “<age>”

}

Success Response Code: 200 OK

Content:

{

    “status”: 1,

    “status_message”: “Employee added successfully!”

}

Error Response Code: 404 Not Found
Sample Call {

  “employee_name” : “An”,

  “employee_salary”: “1000”,

  “employee_age”: “29”

}

Notes Check the new submitted records ID and details at the home page.

4. Update an employee information

This API will help to update an employee information by the employee_id.

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

Authorization: Basic d2ViX2FwcDpjaGFuZ2VpdA==

Data Params {

        “id”: “<id>”,

        “employee_name”: “<new_name>”,

        “employee_salary”: “<new_salary>”,

        “employee_age”: “<new_age>”

    }

 

Success Response Code: 200 OK

Content:

{

    “status”: 1,

    “status_message”: “Employee updated successfully.”

}

 

Error Response Code: 404 Not Found
Sample Call {

  “id” : 7,

  “employee_name” : “Nam”,

  “employee_salary”: “800”,

  “employee_age”: “25”

}

Notes <none>

5. Delete an employee

This API will support to delete an employee by the employee_id.

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

Authorization: Basic d2ViX2FwcDpjaGFuZ2VpdA==

Data Params {

            “id” : <id>

}

Success Response Code: 200 OK

Content:

{

    “status”: 1,

    “status_message”: “Employee deleted successfully.”

}

 

Error Response Code: 404 Not Found
Sample Call {

            “id” : 5

}

Notes <none>

 

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:

 

Tiêu đề (Bug Title)

  • Miên tả ngắn gọn, thể hiện được lỗi. Tiêu đề tốt còn có thể giúp Dev biết được lỗi mà không cần xem các bước bên trong
  • Có thể sử dụng cấu trúc dạng: What…When/Where…. Thể hiễn lỗi trước sau đó đến vị trí của lỗi
  • Không nói chung chung

Ví dụ:

Good Title: Missing the username & password label at Login form

Good Title: [Authentication] The logout button does not clickable at Homepage

Bad Title: The logout button does not work

Bad Title: Something wrong with the register function

 

Mô tả lỗi (Summary)

Đây là nơi bạn có thể diễn tả rõ hơn về lỗi, không giống như tiêu đề bị gò bó bởi chiều dài, tại summary bạn có thể diễn tả dài hơn.

Tuy nhiên nếu lỗi đơn giản bạn có thể không cần ghì hoặc sao chép lại tiêu đề. Không nhất thiết phải cố gắng diễn tả dài dòng khi lỗi nó chỉ cần chừng đó thông tin là đủ.

 

Các bước tái tạo (Reproduce / Steps)

  • Các bước nên đánh thứ tự 1-2-3
  • Ngắn gọn, diễn tả một hành động, không nên ghi dài
  • Đảm bảo các bước đúng thứ tự và có thể tái tạo được

Ví dụ:

  1. Enter admin email
  2. Enter admin password
  3. Click on change profile
  4. Upload the photo with GIF format
  5. Check the uploaded photo

 

Actual / Expected (Kết quả thật tế / Kết quả mong muốn)

  • Ngắn gọn
  • Thể hiện chính xác mong muốn trong phần expected.

Bad Expected: Change the text color

Good Expected: Change the text color to red (#E52121)

Bad Expected: Add the label to username

Good Expected: Add the label “Username” to the username field.

Một chú ý nhỏ nữa nhưng cũng góp phần quan trọng trong việc tạo cảm giác tốt cho dev là tránh ghi trực tiếp và đề cập đến con người trong đó.

Không nên: You need to fix the bug

Nên: The bug should be fixed

Không nên: Can you change the header text to bold?

Nên: The header text color should be in bold.

Các viết thứ hai sẽ không đề cập đến con người (You need, you must…) mà chỉ tập trung vào vấn đề.

Gợi ý:

  • Nên đính kèm ảnh, hình ảnh sẽ giúp Dev hiểu rõ vấn đề hơn, đôi khi không cần đọc các bước.
  • Hạn chế video: khá nặng và tốn nhiều thời gian để xem, chỉ dùng trong các lỗi phức tạp.
  • Phân biệt và dùng đúng mức độ priority và severity
  • Không phải các bug đều được report bằng chữ, bạn có thể report và làm việc trực tiếp với Dev. Có nhiều lỗi bạn cần và cũng nên chia sẻ thông qua giao tiếp & làm việc nhóm.
  • Kiểm tra kĩ trước khi report, tránh report trùng hoặc không phải là lỗi.
  • Không nên gộp nhiều lỗi vào 1 report, mỗi report chỉ nên xử lý một vấn đề.
  • Ghi rõ môi trường + phiên bản đang test.

Vậy tổng kết, thế nào là một bug report hiệu quả?

  1. Có thể tái tạo lại được bởi developer
  2. Ngắn ngọn, tiết kiệm thời gian
  3. Đầy đủ thông tin, hình ảnh
  4. Độc lập, có thể theo dõi được từng lỗi

Mình rất muốn nghe chia sẻ thêm từ những kinh nghiệm của các bạn trong việc viết một bug report tốt và hiệu quả, nếu có gì muốn chia sẻ hay bổ sung các bạn để lại comment nhé!

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.

1. High severity – High priority: Vd một lỗi về mua hàng không thưc hiện được, ảnh hưởng khá cao đến kinh doanh vì vậy độ ưu tiên cũng cao, cái này dễ hiểu 

2. Low severity – Low priority: Lỗi font chữ hơi to, hơi nhỏ, hơi mờ. Độ ảnh hưởng đến hệ thống và người dùng ít, họ vẫn sử dụng các chức năng được bình thường vì vậy ưu tiên thấp, cái này cũng hợp lý.

3. Low severity – High priority: Lỗi gì mà ảnh hưởng thấp, nhưng lại nên fix sớm? ví dụ một lỗi nào đó như banner bị méo / lệch – mà banner đó nằm ngay trang chủ ai vào cũng thấy, tuy nó không ảnh hưởng đến chức năng nhưng vẫn nên fix trước. Hoặc cty bạn làm về đào tạo ngoại ngữ, ở Title ghi sai chính tả, tuy không ảnh hưởng gì đến hệ thống nhưng cũng nên fix sớm, không để vậy lâu được.

4. High Severity, low priority: Lỗi nghiêm trọng, mà có thể để từ từ fix? Có thấy lấy vd như lỗi về game, game bạn có 20 level, ở level 18 nó bị crash/treo không chơi được. Đây là một lỗi khá nghiêm trọng tuy nhiên nhân biết để đạt dc level này đòi hỏi người chơi phải cày vài tháng nữa, vì vậy có thể set ưu tiên thấp xuống, tập trung fix các lỗi ở level 1,2,3.. trước tiên.

Việc set severity/priority phụ thuộc vào nhiều yếu tố như yêu cầu hệ thống, mong muốn khách hàng, kinh nghiệm tester. Việc set đúng không những giúp các lỗi được sửa nhanh chóng, đúng thứ tự ưu tiên mà còn giúp những người cấp cao hơn dễ đưa ra những quyết định liên quan đến chất lượng và thời gian dành cho những lỗi đó.