# 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:


- 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