---
# System prepended metadata

title: Feedback Bài Tập & Các Lưu Ý

---

# Feedback Bài Tập & Các Lưu Ý

## Bài tập 1:

Example ổn:
- Thiếu severity (Có thể bỏ qua)


Thực tế:
- Ko scroll được là hành động. 
- Hành động không thể mô tả bằng hình ảnh.


Ngoài lề: 
- Điều kiện bị: chỉ khi quá nhiều cột.
- Hiện tại chưa scroll được => Thêm test case cho 2 TH khi confirm bug: Ít cột - Nhiều cột khi DEV apply scroll ngang

## Bài Tập 2:

#### Sai sót:
- Nếu loại là [Confirm bug] thì list bug không cần confirm

#### Cần lưu ý gì khi áp dụng list issue để chạy 1 project phát triển qua nhiều sprint ?
- Phát triển qua nhiều sprint => Có nghĩa list bug em bắt chắc chắn ko thể clear hết qua 1 sprint được
- Việc cần làm là qua mỗi lần release
- Cần phải recheck và tách các bug chưa xử lý để xếp vào các sprint tiếp theo.
- QC thì cần phải quản lý được list issue tồn đọng đó.
Chừng nào có vấn đề thì sẽ lôi nó ra để bàn .
- Và các bug ở sprint trước. Có thể được đưa vào list bug ở sprint này. 
=> Cần quản lý và kiểm soát 1 cách khôn khéo.
- Ưu điểm là: Dễ focus vào những issue cần giải quyết cho cả team
- Nhược điểm là: Khi Team size của QC lớn cho 1 sprint thì sẽ khó làm theo kiểu này. Buộc lòng 1 QC phải cover được hết 1 sprint hoặc 1 feature trong sprint để làm list bug

#### Sidenote:
- Có thể gọi list bug là GOAL.
- Nhưng điểm khác là GOAL bao gồm cả task và không chứa các bug quan trọng.
- Để biến list bug thành GOAL thì cần lọc các bug không cần thiết và tách liền các list đó thành issue lẻ và đẩy vào các sprint tiếp theo.

## Bài Tập 3:
- Ổn, chấp nhận được

## Bài Tập 4:
- Ổn
- [Link Bài Tập Checklist Release](https://hackmd.io/@eqct/H1GSsUwcP)

## Bài Tập 5:
- Ổn

## Bài Tập 5b:
- Câu hỏi: Có bao nhiêu bước để xử lý 1 bug phát hiện ở lần giao build Integration
- Làm rõ:
  1. Kể từ lúc phát hiện ở integration đến khi close
  2. Với 3 loại bug:
    - Bug trong feature của integration
    - Bug ngoài feature của integration mà do làm feature đó gây ra
    - Bug khác (miss từ các sprint trước)
- Phân loại:
  - Phải check kỹ version trước có bị hay không, có không phải có receipt ghi lại việc ở version trước không bị, version này lại bị
  - Nếu version trước không bị, tức là bị miss bugs
  - Nêu không confirm được version trước => ghi note lại, nhưng vẫn tính là miss bugs
  - Nếu bugs rơi vô loại lúc bị lúc thì vẫn tính là miss bugs, nhưng lỗi sẽ không nghiêm trọng hơn
- Các xem version:
  - Ctrl + U hoặc view page source
- Chú ý các lần giao integration.
- Câu trả lời đang chú trọng vào lần integration cuối

## Bài Tập 6:
- Ổn

## Bài Tập 7:
- Ổn

## Bài Tập 8:
- Nên nhìn nhận ở phương hướng QC, ví dụ:
  - Bug đó xảy ra ở sprint trước
  - Bug đó xảy ra ở integration test
  - etc
- Phát sinh ra mới:
  - New vơi QC khác với New DEV:
    - Khác: Qc không thấy bugs trước đó => có thể miss bugs => vẫn là new
  - Với các bugs mà DEV nói ở version trước không bị => confirm bằng cách chạy thử
  - Có những bugs chỉ cần sai nhỏ cũng gây bugs, cần chú ý

## Bài tập 9:
- Test scenario: Hành động, không gọi là testcases, ví dụ như: vào bảng điều khiển, tạo nhân viên
- Cách đặt tên, phân bố, nên tách riêng từng title để còn phân cho người khác làm chung, tránh gây nhập nhằng, khó hiểu


### Ví dụ về test scenario:
1. Confirm Sản phẩm:
  - Thêm
  - Xóa 
  - Sửa
2. Confirm Khách hàng:
  - Thêm
  - Xóa 
  - Sửa
3. Mối liên kết:
  - Tạo sản phẩm ở Thành phố xxx
  - Tạo khách hàng ở Thành phố yyy
  - Vào chi tiết khách hàng và sản phẩm => Không có liên kết
  - Update sản phẩm thành Thành phố yyy
  - Vào chi tiết khách hàng và sản phẩm => Có liên kết
  - Xóa sản phẩm / Khách hàng
  - Vào chi tiết khách hàng / Sản phẩm => Không có liên kết

Nhận xét:
  - Nó sẽ bị duplicated số 3 với số 1 và 2. 
  - Nhưng cũng cần phải list ra để đầy đủ.
  - Lúc test thì test cái số 3 thôi kèm theo các case chưa có ở 1 và 2.

## Extra:
1. Bắt Bugs:

![](https://i.imgur.com/JZiGrUT.png)

- Trả lời:
  - Hủy những thay đổi chưa lưu thành Hiện tại, bài viết chưa lưu hoặc hiện tại,......chưa lưu! Hủy bỏ sẽ không lưu thay đổi.
  - ... sẽ thay thành cái gì mà user sửa
  - Nút hủy màu xanh đổi thành Xác Nhận
  - Hủy đen vẫn giữ ạ

- Solution:
  - Ngữ cảnh ở đây là remove quyền của 1 email
  => Click nút X để đóng popup remove quyền => Nó warning
  - Hủy nút đen có nghĩa là: Không thực hiện thao tác rời khỏi poup remove quyền
  - Hủy nút xanh có nghĩa là: xác nhận không thay đổi các thao tác vừa thực hiện và thoát khỏi popup remove quyền
  - Đúng thì nên có 3 nút:
    1. Hủy
    2. Thoát khỏi và lưu
    3. Thoát khỏi và k lưu
