Chương 16 Trung Cấp

Git Cơ Bản Cho QA

Version control không chỉ dành cho Dev — QA cần Git để quản lý test code, tìm regression và cộng tác hiệu quả.

🌿 Git Fundamentals

Repository (Repo)Toàn bộ codebase và lịch sử thay đổi. Remote repo (GitHub/GitLab) là source of truth. Local repo là bản copy trên máy bạn.
BranchDòng phát triển song song. Main/master = production. Feature branches = tính năng đang develop. QA test trên feature branch trước khi merge.
CommitSnapshot của code tại một thời điểm. Mỗi commit có hash (ID duy nhất), author, timestamp, message. History không thể xóa.
Working TreeFiles hiện tại bạn đang thấy và chỉnh sửa. Staged = ready to commit. Unstaged = changed nhưng chưa stage.
Merge / Pull RequestTích hợp thay đổi từ feature branch vào main. PR (GitHub) / MR (GitLab) là nơi review code trước khi merge.

💻 Commands Hay Dùng cho QA

# Lấy code về
git clone https://github.com/org/repo.git
git pull                      # update branch hiện tại
git fetch --all               # fetch tất cả branches, chưa merge

# Xem trạng thái và lịch sử
git status                    # file nào changed/staged
git log --oneline --graph     # lịch sử commit dạng compact
git log --since="2025-01-01"  # commits từ ngày này
git diff main...feature/login # diff giữa 2 branches

# Chuyển branch để test
git checkout feature/payment  # switch sang feature branch
git checkout -b test/my-branch # tạo branch mới
git branch -a                  # list tất cả branches

# Tìm ai thay đổi gì
git blame src/checkout.js     # từng dòng, ai viết, khi nào
git show abc1234              # xem nội dung của commit cụ thể
git log --author="Jane"       # commits của Jane

# Lưu tạm để switch branch
git stash                     # save changes tạm thời
git stash pop                 # khôi phục changes
git stash list                # xem danh sách stashes

🔀 Git Flow & QA Testing Strategy

Feature Development: Dev tạo branch từ develop: feature/user-auth. QA có thể checkout branch này để test early nếu cần.
PR / Code Review: Dev tạo PR từ feature → develop. QA review PR diff: xem scope của thay đổi, identify areas cần test extra.
QA Testing on Staging: Sau khi PR merge vào develop → auto-deploy lên staging. QA test đầy đủ trên staging environment.
Release Branch: Khi sẵn sàng release: tạo release/v2.5.0 từ develop. QA test release branch — chỉ bug fixes được accept, no new features.
Hotfix: Bug critical trên production → branch từ main: hotfix/payment-crash. Fix → PR vào main. QA test ngay, priority highest.
Tag & Deploy: Sau QA sign off, tag: git tag v2.5.0. Deploy tag này lên production. QA có thể verify exact version deployed.

💡 QA & PR Reviews

QA nên đọc PR diff trước khi test — biết chính xác gì thay đổi giúp focus testing effort. Nếu diff nhỏ (chỉ 1 file, 20 lines) → sanity test. Nếu diff lớn (refactor, nhiều files) → full regression risk, test rộng hơn.

👀 PR Review cho QA

QA review PR không phải code review — QA review để hiểu scope và identify risk:

Files Changed: Xem tab "Files Changed" trong GitHub/GitLab. Những file nào bị modify? DB schema thay đổi? API contract thay đổi?
Risk Assessment: Thay đổi ở payment module → test rộng hơn. Thay đổi CSS nhỏ → test responsive. Thay đổi DB query → test data integrity.
Missing Tests: PR có include test code không? Nếu không → risk cao hơn. Comment constructively: "Could you add tests for the edge case where order is empty?"
Breaking Changes: API endpoint changed → old clients bị break không? Backward compatible?
QA Checklist Comment: Post comment trong PR với testing scope: "Testing scope for this PR: Payment module (regression), new discount logic, email notifications."

🔍 git bisect — Tìm Regression Commit

git bisect dùng binary search để tìm commit nào gây ra regression. Cực kỳ powerful khi bug mới xuất hiện nhưng không biết khi nào.

# Bước 1: Bắt đầu bisect
git bisect start

# Bước 2: Mark commit hiện tại là BAD (có bug)
git bisect bad

# Bước 3: Mark một commit cũ là GOOD (không có bug)
git bisect good v2.3.0    # hoặc commit hash

# Git tự động checkout commit ở giữa
# -> Test xem bug có xuất hiện không

# Nếu bug xuất hiện:
git bisect bad

# Nếu bug không xuất hiện:
git bisect good

# Lặp lại cho đến khi Git thông báo "first bad commit"
# Log 10 commits: chỉ cần 4 lần bisect để tìm ra!

# Kết thúc bisect
git bisect reset

💡 Bisect hiệu quả

Với 100 commits, bisect chỉ cần 7 lần test để tìm bad commit (log2(100) ≈ 7). Thủ công sẽ mất ~50 lần. Khi tìm ra bad commit, git show <hash> xem changes → đây là evidence gửi cho dev.

✏️ Bài Tập

📝 Bài Tập: Git cho QA Daily Work

Viết 5 git commands bạn sẽ dùng vào ngày đầu tiên join một project mới để hiểu codebase và lịch sử
Scenario: Bạn nhận được bug report "Sorting by price broken" nhưng không biết khi nào nó bị break. Version 3.0.0 OK, version 3.5.0 broken. Describe step-by-step cách dùng git bisect.
Bạn đang test trên branch feature/checkout thì PM yêu cầu test hotfix gấp trên branch hotfix/payment. Bạn đang có changes chưa commit. Describe exact git commands để switch mà không mất work.
Bạn review PR và thấy dev thay đổi SQL query trong OrderRepository. Viết 5 câu hỏi/test cases bạn sẽ focus vào dựa trên PR diff này.