Trở thành Quality Control (QC) / Tester (kiểm thử phần mềm)

Chương 1 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài này chỉ cho bạn hai đường link quan trọng của khóa học: một link tới folder tài liệu (slide deck) và một link tới folder công cụ. Đây là nơi bạn tải về mọi thứ cần thiết để học và thực hành theo khóa.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cách vào folder tài liệu chứa các slide deck của khóa học.
• Biết cách vào folder công cụ để tải các phần mềm và tài nguyên hỗ trợ.
• Nắm được những gì đã được chuẩn bị sẵn trong folder công cụ.

─── NỘI DUNG CHÍNH

▸ 1. Link tài liệu và slide deck

Bạn click vào đường link hoặc quét QR code để vào folder tài liệu. Trong folder này sẽ có nhiều slide deck của khóa học. Giảng viên lưu ý các slide sẽ được bổ sung dần qua các video sau — nghĩa là khi khóa học tiến triển, bạn quay lại folder này sẽ thấy tài liệu ngày càng đầy đủ hơn.

▸ 2. Link công cụ khóa học

Đường link còn lại dẫn tới folder công cụ. Ở đây giảng viên đã chuẩn bị sẵn một số tài nguyên, gồm Office 2019, một khóa học Google Sheets tham khảo trên Udemy, cùng các hàm Excel hữu ích (ví dụ hàm lấy giá trị, tài liệu chinh phục Excel). Tất cả sẽ được đưa dần vào folder để bạn tham khảo và tải về sử dụng.

Chương 1 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài này hướng dẫn cách học tập cùng giảng viên một cách hiệu quả: tham gia nhóm hỗ trợ, đặt câu hỏi nghiêm túc, và tận dụng các tài liệu được chia sẻ. Điểm mấu chốt: giảng viên khuyến khích bạn hỏi bất cứ khi nào chưa hiểu, qua bất kỳ kênh nào thuận tiện — mục tiêu là bạn thật sự tiếp thu được kiến thức.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cách tham gia group Zalo hỗ trợ học tập qua link hoặc QR code.
• Nắm được tinh thần học tập nghiêm túc mà giảng viên đề nghị.
• Biết nhiều kênh để đặt câu hỏi khi cần được giải đáp.

─── NỘI DUNG CHÍNH

▸ 1. Tham gia nhóm hỗ trợ

Giảng viên đã tạo sẵn một group Zalo. Bạn quét mã QR code hoặc click vào link để vào nhóm; hệ thống sẽ yêu cầu tham gia và giảng viên sẽ duyệt cho bạn vào. Đây là nơi bạn đặt câu hỏi trong suốt quá trình học.

▸ 2. Tinh thần học tập được đề nghị

Giảng viên mong bạn học tập nghiêm túc, chủ động đặt câu hỏi khi không hiểu, và sử dụng đầy đủ các template, checklist, guidelines đã được chia sẻ. Khi trao đổi trong nhóm, hãy giữ tinh thần nghiêm túc — tránh nói chuyện phím ngoài lề để không gian học tập được tập trung.

▸ 3. Nhiều kênh để đặt câu hỏi

Nếu ngại hỏi công khai trong group, bạn có thể chat riêng với giảng viên — hoàn toàn không sao. Ngoài Zalo, bạn còn có thể hỏi trực tiếp trên trang khóa học Udemy (hay nền tảng đang đăng khóa), hoặc gửi mail. Với giảng viên, kênh nào không quan trọng — miễn là bạn hỏi được và hiểu bài.

Chương 1 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài này làm rõ sự khác nhau giữa hai vị trí QA (Quality Assurance) và QC (Quality Control) — hai khái niệm rất hay bị lẫn lộn ở thị trường Việt Nam, kể cả trong các tin tuyển dụng. Điểm mấu chốt dễ nhớ: QA hướng về quy trình ở mức công ty, còn QC hướng về sản phẩm cụ thể của dự án — nhưng cả hai đều nhằm nâng cao chất lượng.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt rõ vai trò của QA và QC trong ngành phần mềm.
• Hiểu vì sao QC (Tester) mang tính chi tiết, còn QA mang tính tổng quan.
• Nhận ra hai vị trí này tuy khác nhau nhưng cùng chung mục tiêu chất lượng.

─── NỘI DUNG CHÍNH

▸ 1. QA — hướng về quy trình, mức công ty

QA tập trung vào quy trình của công ty, mang tính tổng quan. Ví dụ, QA kiểm tra xem đội dự án có thực hiện đúng quy trình không: mỗi sáng có daily meeting 15 phút và có output kèm theo hay chưa; khi deliver cho khách hàng theo hợp đồng (contract) ban đầu đã có đủ các tài liệu A, B, C như cam kết chưa. Nếu thiếu, QA sẽ phát hiện ra vấn đề đó.

▸ 2. QC — hướng về sản phẩm, mức chi tiết

QC, hay chính là Tester, kiểm tra thử phần mềm, hướng về dự án và sản phẩm cụ thể. Vị trí này mang tính chi tiết hơn rất nhiều: test một sản phẩm xem có lỗi hay không, phát hiện lỗi thì báo để sửa như thế nào. So với QA, QC đi sâu vào từng chức năng, từng màn hình thực tế.

▸ 3. Điểm chung: cùng nâng cao chất lượng

Dù khác nhau về phạm vi, cả hai vai trò đều hướng tới nâng cao chất lượng — QA nâng chất lượng ở mức quy trình/công ty, QC nâng chất lượng ở mức sản phẩm/dự án. Cách ghi nhớ đơn giản: một cái hướng về dự án, một cái hướng về mức công ty, nhưng mục tiêu cuối cùng là như nhau. Giảng viên cũng cung cấp một đường link tài liệu tham khảo thêm về sự khác biệt QA và QC.

Chương 1 · Bài 4.1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu 4 yếu tố cấu thành nên một dự án phần mềm: Cost (chi phí), Time (thời gian), Scope (phạm vi) và Quality (chất lượng). Điểm mấu chốt đáng nhớ: 4 yếu tố này ràng buộc lẫn nhau — kéo một yếu tố sẽ ảnh hưởng các yếu tố còn lại, và giữ được cả 4 là điều hiếm; giữ 3/4 hoặc 2/4 đã là tuyệt vời.

─── SAU BÀI HỌC, BẠN SẼ

• Gọi tên và giải thích được 4 yếu tố Cost, Time, Scope, Quality.
• Hiểu quan hệ đánh đổi giữa các yếu tố khi dự án bị "cháy".
• Nhìn ra một dự án đang thiếu/lệch yếu tố nào khi vào kiểm tra.

─── NỘI DUNG CHÍNH

▸ 1. Bốn yếu tố cơ bản của dự án

Trong tam giác quản trị dự án có 4 yếu tố: Cost (chi phí bỏ ra), Time (thời gian thực hiện, từ ngày nào đến ngày nào), Scope (phạm vi công việc — chỉ code, chỉ test, hay có cả deployment), và Quality (chất lượng — được định nghĩa cụ thể, ví dụ bao nhiêu line code thì có bấy nhiêu test case và bao nhiêu bug tương ứng). Một dự án chỉ được xem là "dự án" khi định nghĩa đủ 4 yếu tố này; thiếu một yếu tố là dự án đang có vấn đề.

▸ 2. Bốn yếu tố quyết định thành hay bại

Một dự án thành công khi: chi phí không vượt budget, deliver đúng hạn, nằm trong scope đã đặt ra, và đảm bảo quality. Đây chính là thước đo mà PM và role QA dựa vào để đánh giá dự án.

▸ 3. Quan hệ đánh đổi giữa các yếu tố

Các yếu tố tác động qua lại: nếu ưu tiên giảm Time để giao khách sớm, bạn phải tăng Cost (thêm người, thêm resource), mà thêm người thì Quality dễ giảm (người mới chưa quen việc), và có khi phải giảm Scope vì thời gian ngắn không kịp làm hết. Khi dự án "cháy" (deliver không kịp — vấn đề Time), thường kéo theo cost đội, quality không đạt, scope phình ra.

▸ 4. Ví dụ dễ nhớ: mở quán cà phê

300 triệu để mở quán mới chỉ là Cost. Muốn thành một dự án đúng nghĩa, phải định nghĩa thêm: mở ở đâu, khi nào mở (chi tiết Cost và Time), đối tượng khách hàng và loại cà phê (Scope và Quality). Với role QA, khi vào kiểm tra một dự án, hiểu 4 yếu tố này giúp bạn phán đoán được vấn đề đang nằm ở đâu.

Chương 1 · Bài 4.2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu vòng đời của một dự án gồm 5 phase mà hầu hết dự án đều đi qua: khởi tạo, kế hoạch, thực thi, giám sát & kiểm soát, và đóng dự án. Điểm mấu chốt đáng nhớ: Monitoring & Controlling luôn diễn ra song song, bao trùm suốt hai phase Planning và Executing để giữ dự án đi đúng kế hoạch.

─── SAU BÀI HỌC, BẠN SẼ

• Kể được 5 phase trong vòng đời dự án theo đúng thứ tự.
• Hiểu vì sao Planning và Executing lặp đi lặp lại dưới sự giám sát liên tục.
• Nắm ý nghĩa của việc closing (đóng) và đúc kết bài học cuối dự án.

─── NỘI DUNG CHÍNH

▸ 1. Năm phase của vòng đời dự án

Vòng đời dự án chạy qua 5 phase: Initiating (khởi tạo), Planning (kế hoạch), Executing (thực thi), Monitoring & Controlling (giám sát và kiểm soát), và Closing (đóng). Trong đó Planning và Executing là các process mang tính lặp đi lặp lại, còn Monitoring & Controlling bao trùm suốt quá trình đó.

▸ 2. Từ khởi tạo đến thực thi

Khi tiếp xúc khách hàng và lấy được requirement, bạn ký hợp đồng và khởi tạo dự án: assign PM, chọn người lead, thống kê khách hàng — mọi thứ còn sơ khai. Sang phase Planning, bạn phân rã chi tiết hơn thành các activity như coding, testing. Rồi bước vào Executing — thực hiện kế hoạch, review, verify.

▸ 3. Monitoring & Controlling xuyên suốt

Không có gì đảm bảo thực thi đúng 100%, nên phải liên tục theo dõi, quan sát, kiểm soát rồi điều chỉnh cho phù hợp. Mỗi ngày bạn tracking dự án, ra những action để kéo dự án bám sát cái plan ban đầu và keep được plan đó.

▸ 4. Đóng dự án (Closing)

Đến giai đoạn deliver cho khách hàng là bước Closing: làm thủ tục tổng kết, close ticket mọi thứ, rồi thống kê các bài học — thành tựu đạt được và những điều đúc kết lại đưa về cho công ty lưu cho các dự án sau. Phase này còn nhiều subset nhỏ bên trong chứ không đơn giản như vậy.

Chương 1 · Bài 4.3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chia sẻ một "tip" dễ nhớ về 4 hoạt động cơ bản, xuyên suốt của mọi dự án: Plan – Do – Check – Action (kế hoạch – thực thi – kiểm tra – hành động). Điểm mấu chốt đáng nhớ: làm bất cứ việc gì cũng phải có kế hoạch đi trước, và khi kiểm tra thấy lệch với plan thì phải ra action khắc phục để kéo về đúng kế hoạch ban đầu.

─── SAU BÀI HỌC, BẠN SẼ

• Thuộc và giải thích được chu trình Plan – Do – Check – Action.
• Áp dụng chu trình này khi được giao đi verify tình trạng một dự án.
• Hiểu vì sao "kế hoạch đi trước" là nguyên tắc bất di bất dịch.

─── NỘI DUNG CHÍNH

▸ 1. Bốn hoạt động Plan – Do – Check – Action

Đây là 4 hoạt động chính yếu, gần như việc gì cũng lặp lại như vậy:

1. Plan — lập kế hoạch.
2. Do — thực thi kế hoạch.
3. Check — kiểm tra kết quả so với kế hoạch.
4. Action — khi Check thấy không đúng plan ban đầu, ra hành động khắc phục để làm cho đúng kế hoạch.

▸ 2. Vì sao phải có kế hoạch đi trước?

Làm mà không có plan thì không lường được, không kiểm soát được, không biết tiến độ tới đâu. Vì vậy trong đầu luôn nhớ: nhận một task hay bắt tay vào bất cứ việc gì cũng phải có kế hoạch trước tiên.

▸ 3. Áp dụng cho role QA

Khi công ty giao bạn vào verify một dự án đang tới đâu hoặc có vấn đề gì, hãy đi theo chu trình: Plan trước — xác định ngày đầu vào sẽ kiểm tra gì (Time, Cost, Quality, Scope) để đánh giá dự án còn hoạt động ổn không. Sau đó Do — vào dự án, lấy data thật để kiểm tra. Rồi Check hết số liệu, thấy tốn thời gian ở đâu, lý do vì sao, và cuối cùng Action — báo cáo, đưa ra hành động cụ thể. Dù làm PM hay QC kiểm soát dự án, đây là hoạt động cơ bản và xuyên suốt cần phải nắm.

Chương 1 · Bài 4.4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Waterfall — mô hình phát triển phần mềm lâu đời nhất, chạy tuần tự từng giai đoạn như một thác nước đổ xuống, không quay ngược. Điểm mấu chốt đáng nhớ: Waterfall làm hết trọn từng phase rồi mới sang phase sau, nên xác định được ngân sách ngay từ đầu nhưng lại rất khó thích ứng khi có thay đổi.

─── SAU BÀI HỌC, BẠN SẼ

• Kể được 6 giai đoạn của Waterfall theo đúng thứ tự.
• Giải thích được ưu điểm (chốt được budget và scope ngay từ đầu) và nhược điểm (thời gian ra sản phẩm lâu, ngại thay đổi).
• Nhận biết khi nào nên chọn Waterfall cho một dự án.

─── NỘI DUNG CHÍNH

▸ 1. Sáu giai đoạn của Waterfall

Quy trình chạy tuần tự qua 6 bước: phân tích (analysis) requirement của khách hàng, thiết kế (design), phát triển (development/coding), kiểm tra (testing), triển khai (deployment) và bảo trì (maintenance). Toàn bộ dự án đi theo "chiều ngang": làm xong hoàn toàn một giai đoạn cho tất cả màn hình rồi mới chuyển sang giai đoạn kế tiếp — code hết mọi màn hình xong mới test, test xong mới deploy.

▸ 2. Ưu điểm: chốt được budget và scope từ đầu

Vì phân tích toàn bộ requirement và scope ngay từ lần đầu, bạn xác định được budget của dự án ngay từ đầu. Mô hình cũng hạn chế tối đa sự thay đổi trong quá trình làm, giúp kế hoạch ổn định. Đây là lý do các ngành như xây dựng cũng chuộng cách làm này: đã thiết kế kỹ thì chỉ chấp nhận thay đổi nhỏ, thay đổi lớn sẽ phá vỡ kết cấu.

▸ 3. Nhược điểm: chậm và ngại thay đổi

Thời gian đưa sản phẩm ra thị trường khá lâu — một dự án có thể mất 6 tháng, 1 năm, thậm chí 2 năm. Với startup cần tung sản phẩm nhanh để nghe phản hồi thực tế thì Waterfall không phù hợp; lúc đó người ta chọn Agile/Scrum. Ngoài ra, khi đang ở giai đoạn testing mà phát sinh thay đổi, bạn phải quay lại phân tích, thiết kế, code rồi mới test lại — rất tốn công.

▸ 4. Khi nào dùng Waterfall?

Nhớ đơn giản: dự án nào có thể phân tích, xác định được toàn bộ ngay từ đầu thì dùng Waterfall. Đây không phải mô hình lỗi thời bị bỏ đi — trong thực tế nó vẫn được áp dụng rất nhiều, nhất là những dự án ít thay đổi và đã được thiết kế kỹ càng.

Chương 1 · Bài 4.5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu V-Model — bản mở rộng (extend) của Waterfall, trong đó giai đoạn testing được chia nhỏ và mỗi mức test gắn với một loại tài liệu design tương ứng. Điểm mấu chốt đáng nhớ: V-Model giúp bạn thấy rõ từng mức kiểm thử — Unit, Integration, System, Acceptance — được "soi chiếu" với từng cấp thiết kế nào.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu V-Model là phiên bản mở rộng của Waterfall với testing được chia tầng.
• Ghép đúng mỗi mức test với cấp design tương ứng (Unit ↔ module design, Integration ↔ software design).
• Phân biệt ai thực hiện từng mức test: tester hay khách hàng.

─── NỘI DUNG CHÍNH

▸ 1. V-Model mở rộng từ Waterfall

V-Model giống Waterfall nhưng tách riêng giai đoạn testing thành nhiều mức, mỗi mức tương ứng với một phần thiết kế. Ý tưởng cốt lõi: mỗi loại tài liệu design sẽ có một loại test đối ứng để verify lại.

▸ 2. Bốn mức testing và tài liệu tương ứng

• Unit testing dựa trên module design (còn gọi là detail design) — thiết kế màn hình chi tiết: lấy từ field nào, database nào, validation ra sao. Unit test chỉ kiểm thử ở đơn vị một màn hình.
• Integration testing dựa trên software design (mức cao hơn) — kiểm tra sự liên kết giữa các màn hình với nhau.
• System testing kiểm tra phần liên kết giữa các hệ thống trong một hệ thống lớn.
• Acceptance testing dựa trên requirement ban đầu của dự án.

▸ 3. Ai thực hiện mức test nào?

Unit, Integration và System testing thông thường do tester đảm nhận. Riêng Acceptance testing thì khách hàng/user — người nắm nghiệp vụ — tự test để nghiệm thu sản phẩm; bên tester không làm bước này.

▸ 4. Vì sao QA cần hiểu V-Model?

Khi làm role QA, bạn kiểm soát chất lượng theo quy trình và số liệu. Hiểu V-Model giúp bạn biết dự án đang release ở mức nào (unit, integration...), sản phẩm mỗi giai đoạn ra là gì, để verify lại xem có đúng quy trình phần mềm của công ty và đạt chuẩn chất lượng hay không.

Chương 1 · Bài 4.6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Scrum — mô hình phát triển phần mềm dựa trên Agile, hiện được áp dụng rất nhiều. Điểm mấu chốt đáng nhớ: khác Waterfall, Scrum welcome to change (chào đón sự thay đổi) và chủ động ứng phó thay vì từ chối, đồng thời deliver sản phẩm theo từng sprint ngắn 2–4 tuần để ra hàng nhanh nhất có thể.

─── SAU BÀI HỌC, BẠN SẼ

• Nắm ba vai trò cốt lõi trong Scrum: Product Owner, Scrum Master, Development Team.
• Hiểu luồng làm việc từ Product Backlog → Sprint Planning → Daily Scrum → Sprint Review.
• Phân biệt vì sao Scrum deliver nhanh hơn Waterfall.

─── NỘI DUNG CHÍNH

▸ 1. Product Backlog và ba vai trò

Product Backlog chứa toàn bộ các tính năng (item/story) của sản phẩm, kèm độ ưu tiên và story point. Ba role màu xanh cần nhớ: Development team (người làm dự án), Scrum Master (đốc thúc, hướng team chạy đúng quy trình — không phải PM ra lệnh bắt buộc), và Product Owner (người được khách hàng tin tưởng giao quyền quyết định sản phẩm, chịu trách nhiệm fill item vào backlog). Ngoài ra có Stakeholder (màu cam) — những người liên quan trực tiếp hoặc gián tiếp tới dự án như HR, SA, IT, admin.

▸ 2. Sprint và các hoạt động

Mỗi sprint kéo dài 2–4 tuần. Team bóc item từ backlog ra làm trong Sprint Planning, sau đó thực hiện và mỗi ngày họp Daily Scrum — thường là stand-up meeting khoảng 15 phút, trả lời 3 câu: đã làm được gì, sắp tới làm gì, có issue gì không. Cuối sprint có Sprint Review (demo sản phẩm cho khách hàng) và Retrospective (rút bài học để tăng năng suất).

▸ 3. Nguyên tắc trong một sprint

Trong sprint đang chạy: no change (không đổi giữa chừng), quality không được giảm, còn Product Backlog thì có thể redefine liên tục — thấy tính năng không phù hợp thì đưa item mới vào backlog. Khi scope có thay đổi, phải negotiate với Product Owner để quyết định làm hay dời sang sprint sau.

▸ 4. Vì sao chọn Scrum?

Ưu điểm: welcome to change, team nhỏ linh động, mỗi 2–4 tuần đã deliver cả code lẫn test. Trong khi Waterfall làm hết theo hàng ngang mới sang phase sau nên delivery lâu, thì Scrum deliver rất nhanh. Muốn học sâu và lấy chứng chỉ, bạn tham khảo thêm khóa PM và trang scrum.org.

Chương 1 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học điểm qua các loại testing cơ bản (Unit, Integration, Acceptance) và các kỹ thuật testing cơ bản (Black box, White box, Grey box, Monkey testing) hay dùng nhất trong phần mềm. Điểm mấu chốt đáng nhớ: phân biệt theo phạm vi kiểm thử (một màn hình hay nhiều màn hình) và theo mức độ nhìn thấy bên trong (chỉ input/output hay cả xử lý ẩn).

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt Unit, Integration và Acceptance testing cùng người thực hiện mỗi loại.
• Hiểu bốn kỹ thuật Black box, White box, Grey box và Monkey testing.
• Biết trong ngành outsourcing tester thường làm cả Unit testing.

─── NỘI DUNG CHÍNH

▸ 1. Ba loại testing cơ bản

• Unit testing: kiểm thử đơn vị nhỏ nhất — trên một màn hình. Ví dụ màn hình login: kiểm từng textbox username, password, button có hợp lệ không.
• Integration testing: kiểm thử sự kết hợp của nhiều màn hình theo một luồng — ví dụ login xong sang list user, rồi edit, save, xóa, tạo user mới.
• Acceptance testing: do end user (người dùng nắm nghiệp vụ) tự test để xem phần mềm ổn không, đúng nghiệp vụ không — không phải role QC làm.

▸ 2. Ai làm loại test nào?

Theo đúng gốc quy trình, Unit testing thường do developer làm, còn tester lo Integration testing. Tuy nhiên trong ngành outsourcing, developer thường không làm hết Unit testing, nên tester "nhảy xuống" làm luôn phần Unit testing này.

▸ 3. Bốn kỹ thuật testing cơ bản

• Black box (hộp đen): chỉ biết input và output, không cần biết xử lý bên trong. Ví dụ test login: nhập đúng username/password thì thành công, nhập sai thì báo lỗi.
• White box (hộp trắng): nhìn xuyên suốt từng bước xử lý bên trong — ví dụ password được mã hóa loại nào, vào database lấy đúng không.
• Grey box (hộp xám): kết hợp cả Black box và White box khi test một chức năng.
• Monkey testing: test không theo test case nào, cứ click và thao tác theo cảm nhận như "con khỉ nhảy lung tung" để dò xem có hợp lệ không.

Ngoài ra còn các loại khác như regression, performance, stress test sẽ được nói rõ hơn ở các bài sau.

Chương 1 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu bài tập xuyên suốt sẽ được dùng đi dùng lại trong cả khóa để bạn luyện viết test case. Đây là một ứng dụng nhỏ gồm 3 màn hình với khoảng 4–5 chức năng chính. Điểm mấu chốt: hãy nắm thật kỹ luồng nghiệp vụ của bài tập này, vì các bài sau (Unit Test, Integration Test) đều lấy nó làm ví dụ thực hành.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu rõ 3 màn hình và các chức năng của bài tập mẫu: login, hiển thị danh sách, search, xóa, chỉnh sửa user.
• Nắm được luồng chuyển màn hình và các trường hợp cần kiểm thử ở mỗi màn hình.
• Sẵn sàng dùng bài tập này làm nền để viết Unit Test Case ở các bài tiếp theo.

─── NỘI DUNG CHÍNH

▸ 1. Màn hình Login

Màn hình đầu tiên gồm ô tên tài khoản, ô mật khẩu và vùng thông báo lỗi. Nhấn nút Đăng nhập: nếu nhập đúng thì chuyển sang màn hình danh sách, nếu sai thì hiển thị báo lỗi. Nút Nhập lại reset cả hai ô về trống (blank). Lưu ý điểm dễ bỏ sót khi test: ô mật khẩu phải hiển thị dấu sao che ký tự, không lộ mật khẩu ra ngoài.

▸ 2. Màn hình danh sách User

Sau khi đăng nhập, danh sách hiển thị họ và tên, email, user kèm hai chức năng Edit (chỉnh sửa) và Xóa. Danh sách có phân trang (chuyển trang số hoặc next/prev). Nhấn Edit sẽ sang màn hình chỉnh sửa; nhấn Xóa sẽ bật popup với hai nút OK/Cancel để xác nhận. Có ô tìm kiếm cho phép nhập email, họ tên hoặc user rồi nhấn tìm để load lại danh sách theo tiêu chí.

▸ 3. Màn hình chỉnh sửa User

Khi vào từ nút Edit, màn hình hiển thị sẵn thông tin user. Bạn sửa thông tin rồi nhấn Cập nhật: nếu hợp lệ thì lưu và quay lại màn hình danh sách; nếu để trống data thì báo lỗi. Nút Nhập lại ở đây không xóa mà reset về trạng thái ban đầu (ví dụ đang là "Nguyễn Quang A" thì trả về đúng "Nguyễn Quang A"). Đây chính là bộ khung để bạn thực hành viết Unit Test và Integration Test cho cả khóa.

Chương 2 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học làm rõ khái niệm Unit Testing — mức kiểm thử nhỏ nhất trong phần mềm — và điểm mấu chốt dễ hiểu nhầm: trong khóa học này, Unit Testing được thực hiện bằng tài liệu test case, KHÔNG phải bằng mã code. Đây là cách phổ biến ở các công ty gia công phần mềm (outsourcing), nơi test case được giao cho khách hàng làm bằng chứng đã kiểm thử.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Unit Testing là gì theo định nghĩa ISTQB và phân biệt "test bằng tài liệu" với "test bằng code".
• Đọc được cấu trúc một file Unit Test Case và ý nghĩa các cột chính.
• Nhận ra hai dạng trình bày test case: dạng Line (dòng) và dạng Matrix (ma trận).

─── NỘI DUNG CHÍNH

▸ 1. Unit Testing là gì?

Theo định nghĩa của ISTQB (chứng chỉ về kiểm thử), Unit Testing là đơn vị kiểm thử nhỏ nhất, thường do developer viết mã code để test. Nhưng trong ngành gia công phần mềm, "Unit Testing" ở nhiều công ty lại là viết test case trên tài liệu, không phải viết code. Khóa học này đi theo hướng test case bằng tài liệu — bạn kiểm thử trên một màn hình, một đơn vị rất nhỏ.

▸ 2. Cấu trúc một file Unit Test Case

Một test case điển hình gồm các cột: màn hình / chức năng cần test, điều kiện tiên quyết (precondition), nội dung kiểm tra, kết quả, ngày test, người test, và Bug ID (mã bug nếu phát hiện lỗi), cột Remark để ghi chú. Ví dụ: test màn hình ON001 hiển thị đúng giá trị mặc định đã được set ở lần cuối → nếu đúng thì đánh OK kèm ngày test và tên người test.

▸ 3. Hai dạng trình bày: Line và Matrix

• Dạng Line: mỗi test case là một dòng ngang, header theo dòng — dễ đọc tuần tự.
• Dạng Matrix: trình bày kiểu ma trận, có sheet UI liệt kê các màn hình; kiểm tra màu sắc, vị trí các thành phần theo chiều dọc/ngang rồi đánh OK / Not good.

▸ 4. Mục tiêu cuối cùng

Dù trình bày kiểu nào, mục tiêu của Unit Testing vẫn là: tìm ra bug và nâng cao chất lượng sản phẩm. Luôn nhớ Unit Testing kiểm thử ở đơn vị rất nhỏ — một màn hình, một chức năng.

Chương 2 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Trong ngành gia công phần mềm (outsourcing), có lúc bạn được giao sẵn mẫu Unit Test Case, có lúc thì không. Bài học chỉ ra rằng bạn hoàn toàn có thể tự tạo mẫu UTC bằng Excel — việc này không hề khó. Điểm mấu chốt: nắm được cấu trúc các sheet chuẩn của một file test case và cách dùng công thức để tự động thống kê kết quả test.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo được một file UTC bằng Excel với đủ các sheet chuẩn: Cover, Record of change, Test case, Config, Summary.
• Thiết kế được các cột của sheet test case và tạo dropdown trạng thái.
• Dùng được hàm COUNTIF kết hợp INDIRECT để thống kê kết quả test tự động theo từng sheet.

─── NỘI DUNG CHÍNH

▸ 1. Cấu trúc các sheet chuẩn

Một file test case thường bắt đầu bằng sheet Cover (bìa), sheet Record of change (lịch sử thay đổi), rồi mới đến sheet Test case (UTC). Ngoài ra nên có sheet 99 config chứa danh sách trạng thái (not yet, đang test/fixing, OK, pass, fail, pending, cancel…) để tái sử dụng, và sheet Summary để thống kê.

▸ 2. Thiết kế sheet Test case

Sheet test case gồm các cột: Test case ID (mã duy nhất), tên/tiêu đề test case (check cái gì), Precondition (điều kiện tiên quyết), Test step (nội dung check), kết quả, trạng thái, người test (person in charge), ngày và ghi chú. Bạn có thể chèn thêm layer ảnh màn hình UI vào để minh họa. Nhớ bật Wrap text cho ô xuống dòng gọn gàng và tô màu để dễ nhìn.

▸ 3. Sheet Summary với COUNTIF và INDIRECT

Ở sheet Summary, dùng COUNTIF trên cột trạng thái để đếm số OK, Not good của từng sheet UTC. Vấn đề: nếu chỉ trỏ tới một sheet cố định thì các sheet khác vẫn ra 0. Cách xử lý là dùng hàm INDIRECT — biến tên sheet trong ô (ví dụ B6) thành tham chiếu động, ghép chuỗi bằng dấu `&`, rồi kéo công thức xuống. Nhờ đó mỗi dòng summary tự đếm đúng theo sheet UTC tương ứng (UTC1, UTC2, UTC3…).

▸ 4. Mở rộng sang dạng Matrix

Ngoài dạng test case theo dòng như trên, bạn cũng có thể tạo template theo dạng Matrix — kẻ cột, kẻ dòng. Dạng Matrix phức tạp hơn một chút nhưng cách làm tương tự. Cuối cùng chỉ cần tô màu, định dạng và đặt quy tắc tên là bạn đã có template UTC để viết test case.

Chương 2 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài trước bạn đã tạo mẫu Unit Test Case bằng Excel; bài này làm lại cùng một mẫu nhưng trên Google Sheet (Spreadsheet). Điểm mấu chốt: cấu trúc sheet và công thức thống kê giống hệt Excel, chỉ khác vài thao tác đặc thù của Google Sheet như tạo file bằng `sheet.new`, làm dropdown bằng Data validation và transpose bằng Paste special.

─── SAU BÀI HỌC, BẠN SẼ

• Tạo nhanh một Spreadsheet UTC mới bằng lệnh `sheet.new` với đủ các sheet Cover, Summary, Config, UTC.
• Tạo dropdown trạng thái bằng Data validation → dropdown from a range.
• Thống kê kết quả test bằng COUNTIF kết hợp INDIRECT, cố định ô bằng phím F4.

─── NỘI DUNG CHÍNH

▸ 1. Khởi tạo file và các sheet

Gõ `sheet.new` trên trình duyệt để tạo Google Sheet mới. Tạo lần lượt các sheet: Cover, sheet lịch sử, Summary, sheet 99 config (chứa các trạng thái: Yes/Fixing, OK, Not good, Pending, Cancel) và sheet UTC (Unit test case). Cấu trúc này song song với bản Excel ở bài trước.

▸ 2. Thiết kế sheet UTC và dropdown trạng thái

Sheet UTC gồm các cột: Test case ID, Test case name (check cái gì), Precondition (điều kiện tiên quyết), Test step (nội dung check), Expected result (kết quả), trạng thái, người, ngày và ghi chú. Cột trạng thái làm thành combo box bằng Data → Data validation → Add rule → Dropdown (from a range), trỏ tới vùng trạng thái ở sheet config. Có thể chuyển kiểu hiển thị dropdown sang Arrow để bỏ dấu chip màu mờ. Nội dung test case có thể copy lại từ file Excel cũ.

▸ 3. Sheet Summary với COUNTIF và INDIRECT

Dùng Paste special → Transpose để dựng nhanh hàng tiêu đề trạng thái. Sau đó dùng COUNTIF trên cột trạng thái (cột E) để đếm, nhấn F4 để cố định vùng tham chiếu. Khi cần thống kê nhiều sheet, duplicate sheet UTC (thành sheet 2, sheet 3…) rồi dùng hàm INDIRECT ghép tên sheet ở ô biến (ví dụ B5, cố định cột) bằng `&` — mỗi dòng summary sẽ tự đếm đúng theo sheet tương ứng. Cuối cùng tô màu cho file gọn gàng. Bài tiếp theo sẽ giới thiệu về Point of View của dự án.

Chương 2 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Point of View (POV) là tập các quan điểm test — những khía cạnh cần kiểm tra trên một màn hình — được thống nhất TRƯỚC khi cả team bắt tay viết test case. Điểm mấu chốt: nếu không có POV đi trước, 4 người sẽ viết test case theo 4 kiểu khác nhau, không thống nhất và dễ bỏ sót. POV đóng vai trò như "code standard" của tester, giúp mọi người viết test case nhanh, đồng nhất và đủ ý.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu POV là gì, vì sao phải làm POV trước khi viết test case.
• Biết POV chia theo Unit Test / Integration Test / Acceptance Test, và tách phần common với phần project.
• Nắm được các nhóm quan điểm common thường gặp (verify giao diện, dialog, default value, input & validation…).

─── NỘI DUNG CHÍNH

▸ 1. POV là gì và vì sao cần làm trước

POV là những quan điểm khi thực hiện unit test: test môi trường nào, function nào, hành vi người dùng, data ra sao. Làm POV trước giúp cả team có nền tảng chung, viết test case thống nhất và đúng quan điểm dự án. File POV có thể trình bày bằng Excel, Google Sheet hoặc mindmap — quan trọng là nội dung. Trong khóa này POV chia làm phần common (dùng chung) và phần project (theo nghiệp vụ riêng).

▸ 2. Các quan điểm common tiêu biểu

• 101 – Verify giao diện: màu sắc, theme theo hệ điều hành; kiểm tra control (menu, submenu, icon, button, combo box, checkbox, textbox) về hình dạng, vị trí, kích cỡ, trạng thái (enable/disable).
• 102 – Verify dialog/confirm: vị trí, title, nội dung của các loại dialog confirm, warning, error, information.
• 103 – Default value & default focus: giá trị mặc định, con trỏ mặc định, căn lề khi khởi tạo màn hình.
• 104 – Chuột và bàn phím: Tab, Enter, right/left/middle click, các phím tắt Ctrl+C, Ctrl+V…
• 105 – Input check & validation: normal / abnormal / boundary, nhập 1 byte, 2 byte, blank, whitespace, min–max length; nhập tay hoặc copy-paste.

▸ 3. Các quan điểm mở rộng và cách chốt POV

Các quan điểm tiếp theo gồm 106 (kích cỡ/vị trí form winform: resize, minimize, maximize…), 107 (thanh cuộn, hành vi list view: read-only hay edit trực tiếp, kiểm tra file setting), 108 (check file log: nội dung, cấu trúc, thời gian; di chuyển giữa các màn hình), 109 (khởi động lại máy, đổi parameter), cùng các quan điểm verify hình ảnh, pause/dừng, và kết nối/ngắt kết nối database. Để ra được file POV, team cần họp nhiều lần để thống nhất, sau đó share cho toàn team làm căn cứ viết test case.

Chương 2 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài trước bạn đã có file Point of View (POV); bài này chỉ cách ánh xạ từng quan điểm POV thành test case cụ thể cho màn hình Login. Điểm mấu chốt: mở POV bên cạnh, đi qua từng quan điểm (101, 103, 105…) và với mỗi quan điểm viết ra một hoặc vài test case đầy đủ Precondition – Test step – Expected result. Đây là mindset, cách nhìn để viết test case không bị thiếu ý.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cách gắn mã màn hình (SCR01) và mã test case ID theo quy tắc thống nhất.
• Chuyển được từng quan điểm POV thành test case có Precondition và Expected result rõ ràng.
• Viết test case đủ chi tiết để người ngoài dự án đọc cũng hiểu và thực hiện được.

─── NỘI DUNG CHÍNH

▸ 1. Ánh xạ POV 101 – Verify giao diện

Đặt mã màn hình SCR01 cho màn hình Login, test case ID ghép theo dạng SCR01 + số thứ tự. Test case đầu tiên từ POV 101: kiểm tra giao diện hiển thị giống sheet UI (bạn tạo một sheet UI chứa ảnh thiết kế màn hình). Sau đó viết các test case kiểm tra màu sắc, hình dạng, vị trí của tất cả control đúng như thiết kế. Nếu thiết kế có tiêu chí cụ thể thì ghi thêm để test từng hạng mục.

▸ 2. Ánh xạ POV 103 – Initial default check

Ở quan điểm 103, kiểm tra giá trị hiển thị khi khởi tạo lần đầu và giá trị mặc định. Ví dụ cho màn hình Login với điều kiện "vào được màn hình" và "chưa nhập bất kỳ giá trị nào", Expected result gồm: ô tài khoản và mật khẩu bằng blank, nút Đăng nhập ở trạng thái disabled, nút Nhập lại enabled, không có thông báo lỗi. Đừng quên default focus — con trỏ mặc định phải nằm ở ô tài khoản.

▸ 3. Ánh xạ POV 105 – Input check & validation

Với POV 105, viết cặp test case hợp lệ / không hợp lệ. Ví dụ nhập giá trị 1 byte hợp lệ ("user a" viết liền, không ký tự đặc biệt) → nhập được, không lỗi; nhập ký tự 2 byte → báo lỗi không nhập được; nhập khoảng trắng → kiểm tra kết quả xử lý. Ghi rõ how to input (nhập tay hay copy-paste) và control to apply (textbox, list view, number box…).

▸ Lưu ý khi viết test case theo POV

Tiêu chí quan trọng: test case phải rõ ràng đến mức người ngoài dự án đọc cũng hiểu — ghi "nhập user a viết liền, không ký tự đặc biệt" thay vì chỉ "nhập user a". Khi test thực tế, phải đối chiếu lại tài liệu: nếu tài liệu ghi không có thông báo lỗi nhưng hệ thống thực tế lại báo lỗi, phải cập nhật test case cho đúng. Tài liệu thường ghi thiếu, nên người viết cần họp với comtor để hiểu rõ hệ thống. POV chỉ lo phần common; phần nghiệp vụ riêng của màn hình (như chức năng login đúng/sai) bạn viết thêm test case riêng.

Chương 2 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Trước khi giao (deliver) file Unit Test Case cho khách hàng, tài liệu phải được định dạng chỉn chu thì mới xem là hoàn thiện. Bài học chỉ ra các lỗi định dạng thường gặp trên Excel và cách chuẩn hóa file về chế độ in gọn gàng — điều đặc biệt quan trọng khi làm việc với khách hàng Nhật, vốn hay in tài liệu ra để thao tác trực tiếp.

─── SAU BÀI HỌC, BẠN SẼ

• Biết vì sao file test case cần được định dạng đúng trước khi giao cho khách hàng.
• Dùng được chế độ Page Break Preview để canh vùng in.
• Chuẩn hóa mọi sheet: xóa vùng thừa, thống nhất font chữ.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao phải định dạng file trước khi giao?

Một file test case nội dung đúng nhưng trình bày lộn xộn (con trỏ để lung tung, khung bị mất) thì chưa "hoàn thiện". Với nhiều công ty Nhật, tài liệu thường được in ra giấy để nhìn và thao tác trực tiếp, nên khi deliver bắt buộc phải ở trạng thái sẵn sàng in.

▸ 2. Dùng Page Break Preview để canh vùng in

Chọn chế độ Page Break Preview để thấy rõ ranh giới trang in và chỉnh sẵn vùng in. Khi bật lên, bạn sẽ thấy phần khoảng trắng thừa rất nhiều — những khoảng trắng không dùng đến này cần được xóa hết, chỉ chừa lại đúng phần dữ liệu cần thiết, rồi save lại file. Đường ranh giới trang sẽ co gọn lại đúng vùng nội dung.

▸ 3. Chuẩn hóa toàn bộ sheet và font chữ

Không chỉ một sheet — mọi sheet trong file đều phải được định dạng lại như nhau, xóa sạch vùng dữ liệu thừa, không để lộn xộn. Cuối cùng, font chữ phải thống nhất: nếu tiêu đề dùng Times New Roman thì toàn bộ phần bên dưới cũng phải là Times New Roman.

▸ Mẹo quan trọng: kiểm tra từng sheet trước khi deliver

Lỗi hay gặp nhất là chỉ chỉnh sheet đầu tiên rồi quên các sheet còn lại. Trước khi gửi, hãy mở lần lượt từng sheet, bật Page Break Preview và soát: vùng in gọn chưa, còn khoảng trắng thừa không, font đã đồng nhất chưa.

Chương 2 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Định dạng file test case bằng tay (canh vùng in, đồng nhất font, xóa link lỗi cho từng sheet) rất tốn thời gian và lặp đi lặp lại. Tác giả tự viết một công cụ định dạng tài liệu bằng Excel để tự động hóa các thao tác này. Điểm mấu chốt: chỉ vài cú nhấn nút, công cụ áp dụng zoom, page break, đổi font… cho toàn bộ các sheet cùng lúc, tiết kiệm rất nhiều thời gian.

─── SAU BÀI HỌC, BẠN SẼ

• Biết công cụ định dạng làm được gì và tải/giải nén nó ở đâu (học viên khóa này được dùng miễn phí).
• Dùng được các tính năng chính: zoom đồng loạt, reset page break, count page, đổi font toàn file.
• Dùng được chức năng tạo index, insert comment và export comment ra danh sách link.

─── NỘI DUNG CHÍNH

▸ 1. Công cụ giải quyết vấn đề gì

Công cụ tự động hóa các thao tác định dạng lặp đi lặp lại: đưa con trỏ về ô A1 rất nhanh, page break cho tất cả các sheet, xóa các link lỗi. File hướng dẫn kèm theo cũng chính là file demo trong bài. Link download có mật khẩu là smartitsoft.com; tải về rồi giải nén để dùng.

▸ 2. Các tính năng định dạng chính

• Zoom đồng loạt: nhấn nút zoom hoặc phím tắt (ví dụ Ctrl+Shift+Z), nhập 85% / 50% → tất cả các sheet về cùng mức zoom.
• Reset page break: nhấn một phát, toàn bộ sheet chuyển sang page break preview; sau đó bạn tự kéo chỉnh lại vì công cụ không hiểu hết bố cục.
• Count page: đếm số trang in của từng sheet và tổng toàn file (ví dụ tổng 57 page).
• Đổi font: nhập tên font, nhấn OK → mọi sheet chuyển về cùng một font.

▸ 3. Index, comment và export

Nhấn Create index để sinh một sheet index liệt kê tất cả sheet, giúp tìm nhanh. Với ghi chú, bạn insert comment/note vào các ô chưa đúng, rồi nhấn Export comment để công cụ gom toàn bộ comment ra một danh sách có link nhảy thẳng tới ô tương ứng; có thể xóa hết comment khi xong. Công cụ được tặng miễn phí cho học viên đăng ký khóa học, giúp format tài liệu test case nhanh hơn rất nhiều.

Chương 2 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đây là bài giải bài tập tổng hợp: viết Unit Test Case cho 3 màn hình cơ bản (Login, List User, Modify User) bằng cách bám theo file POV đã học. Điểm mấu chốt: với mỗi màn hình, luôn test theo thứ tự layout → default → validation → chức năng nghiệp vụ, và nhớ rằng ở mức Unit Test bạn chỉ kiểm tra đơn thuần trong màn hình đó, chưa chuyển sang màn hình khác.

─── SAU BÀI HỌC, BẠN SẼ

• Áp dụng được POV để viết test case cho từng màn hình theo trình tự chuẩn.
• Phân tích được nghiệp vụ chính của mỗi màn hình để không bỏ sót test case.
• Nhận ra ranh giới giữa Unit Test và Integration Test khi test các luồng có chuyển màn hình.

─── NỘI DUNG CHÍNH

▸ 1. Màn hình Login (SCR01)

Bắt đầu bằng test case layout (POV verify giao diện): màn hình hiển thị đúng thiết kế, màu sắc, textbox, button đúng vị trí. Tiếp đến kiểm tra giá trị mặc định khi khởi tạo, rồi validation cho các textbox: nhập hợp lệ / không hợp lệ, ký tự 1 byte / 2 byte, ký tự đặc biệt, không phải Unicode, khoảng trắng, kiểm tra thông báo lỗi. Cuối cùng test nút Nhập lại có reset đúng không và nút Đăng nhập đưa vào màn hình bên trong.

▸ 2. Màn hình List User

Vẫn mở POV để test input check, index value, ký tự đặc biệt trước, rồi tới layout, rồi nghiệp vụ. Nghiệp vụ chính của màn hình này là tìm kiếm (theo họ tên, email, user — đúng thì ra, sai thì không ra), cùng phân trang, edit và sort. Test cả trường hợp nhiều kết quả gần giống nhau để kiểm tra phân trang, và đổi cấu hình số record mỗi trang. Với chức năng xóa: nhấn xóa hiện popup, OK thì xóa và list lại.

▸ Lưu ý quan trọng: xác định phạm vi Unit Test

Với List User, cần ghi rõ trong test case một tình huống dễ sai: đang ở trang số 3, xóa một user thì hệ thống quay về trang 1 hay giữ nguyên trang 3, và user ở trang sau có được dồn lên không? Đây là điều phải quy định rõ theo nghiệp vụ. Đồng thời nhớ: ở mức Unit Test, khi nhấn Edit bạn không đi tiếp vào màn hình chỉnh sửa rồi quay lại — luồng chuyển màn hình đó thuộc phần Integration Test sẽ nói sau.

▸ 3. Màn hình Modify User

Test từng field: nhập hợp lệ / không hợp lệ cho mỗi ô, nhấn Cập nhật kiểm tra kết quả và thông báo lỗi khi data không hợp lệ, nhấn Nhập lại kiểm tra reset. Trước tất cả những cái đó, đừng quên test layout của màn hình. Nguyên tắc xuyên suốt: bám theo POV để test phần common trước, sau đó mới bước sang test nghiệp vụ riêng của màn hình.

Chương 2 · Bài 9

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học phân biệt hai khái niệm dễ nhầm: Unit Test Case và Unit Test Report. Điểm mấu chốt: khi bạn mới ghi test case ra mà chưa có kết quả đánh giá thì đó vẫn chỉ là test case; khi đã điền đầy đủ thông tin thực hiện test (ai test, ngày nào, trạng thái, bug ID) thì nó trở thành report. Bài cũng làm rõ luồng test — log bug — retest — đóng bug mà một tester đi qua trong thực tế.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được Unit Test Case (chưa có kết quả) và Unit Test Report (đã điền kết quả thực hiện).
• Nắm được flow chuẩn: test → phát hiện lỗi → log bug kèm evidence → retest → đóng bug.
• Biết vì sao không được xóa Bug ID sau khi đóng bug.

─── NỘI DUNG CHÍNH

▸ 1. Test Case và Test Report khác nhau ở đâu?

Cùng một file, nhưng khi bạn chỉ mới liệt kê các bước kiểm tra thì nó là Unit Test Case. Khi bạn đã điền thông tin thực hiện — trạng thái pass/fail, người test, ngày test — thì nó chính là Unit Test Report. Quy tắc này áp dụng y hệt cho Integration Test Case và Integration Test Report.

▸ 2. Luồng test và log bug

Chạy phần mềm lên, test trên màn hình (ví dụ màn hình login). Khi phát hiện lỗi, bạn vào hệ thống log bug, ghi nhận bug và chụp hình evidence tại thời điểm lỗi để đội developer hiểu và tái hiện được. Developer fix xong sẽ báo bug đã resolved; tester lên retest lại, thấy OK thì đóng bug.

▸ 3. Ghi nhận retest và giữ Bug ID

Nhiều test case có thêm cột ngày retest, đặt sau ngày test lần đầu. Sau khi retest thấy đạt, bạn đánh OK và điền lại trạng thái. Lưu ý quan trọng: không xóa Bug ID đã log — phải giữ lại để người sau biết lần test trước đã phát hiện bug này. Đó chính là việc tracking một test case xuyên suốt vòng đời của nó.

▸ Lưu ý khi làm report

Trọng tâm của bài là ý nghĩa của việc ghi nhận thông tin, không phải thao tác trên công cụ log bug (phần đó đã được demo ở bài trước). Hãy tập trung hiểu rõ: report là test case đã được "sống" qua một lần thực thi thật.

Chương 3 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học mở đầu Chương 3, giới thiệu Integration Testing — mức kiểm thử tích hợp nhiều màn hình. Điểm mấu chốt để phân biệt với Unit Testing: nếu Unit Testing kiểm thử một đơn vị nhỏ nhất (một màn hình), thì Integration Testing kiểm thử luồng nghiệp vụ đi qua nhiều màn hình kết hợp lại với nhau. Đây là bước để đảm bảo chương trình hoạt động đúng theo cả một quy trình, không chỉ đúng ở từng chức năng rời rạc.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Integration Testing là kiểm thử sự tích hợp và luồng nghiệp vụ giữa nhiều màn hình.
• Phân biệt rõ mục tiêu của Integration Testing so với Unit Testing.
• Nhận ra vì sao một chức năng có thể "có bug ở unit" nhưng vẫn "chạy được ở luồng nghiệp vụ".

─── NỘI DUNG CHÍNH

▸ 1. Integration Testing khác Unit Testing thế nào?

Unit Testing test một màn hình: field này có validate không, nút đăng nhập ở màn hình này bấm có đúng không. Integration Testing (viết tắt IT) test nhiều màn hình nối tiếp nhau: login thành công → chuyển sang màn hình danh sách/tìm kiếm → chuyển sang màn hình chỉnh sửa user. Trọng tâm là sự kết hợp của nhiều màn hình theo một luồng, chứ không phải một màn hình đơn lẻ.

▸ 2. Phần chủ yếu: đi theo luồng nghiệp vụ

Điều cốt lõi khi làm Integration Testing là phải test đúng theo luồng nghiệp vụ. Bạn không kiểm tra từng ô nhập rời rạc, mà kiểm tra cả chuỗi thao tác đi qua nhiều màn hình có chạy thông suốt và đúng đắn hay không.

▸ 3. Mục tiêu và sự khác biệt về phạm vi

Mục tiêu của Integration Testing là kiểm tra tính hoạt động của chương trình theo luồng nghiệp vụ có đúng hay không. Ví dụ: một field ở màn hình nhập mã tài khoản có thể có bug cho phép nhập ký tự đặc biệt (lỗi ở mức unit), nhưng khi nhập giá trị bình thường thì vẫn login được và vẫn chuyển sang các màn hình khác — nghĩa là về mặt luồng, chức năng chính vẫn hoạt động. Integration Testing tập trung vào cái tổng thể đó, còn Unit Testing chỉ soi vào một màn hình.

Chương 3 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn tạo file Integration Test Case (ITC) bằng Excel ở dạng Line (hàng ngang) — mỗi test case là một dòng. Cách làm gần giống file Unit Test Case đã học, chỉ khác ở chỗ: với IT, mỗi sheet (hoặc mỗi file) là một luồng nghiệp vụ, thay vì một màn hình. Bài cũng chỉ cách dựng sheet thống kê tự động bằng hàm COUNTIF để báo cáo số lượng và tỷ lệ phần trăm test case.

─── SAU BÀI HỌC, BẠN SẼ

• Dựng được cấu trúc một file ITC đầy đủ: cover, history, UI, test case và summary.
• Nắm ý nghĩa các cột chính và bộ trạng thái Not yet / OK / Not good / Pending / Cancel.
• Dùng được hàm COUNTIF để thống kê và tính phần trăm test case ở sheet cover.

─── NỘI DUNG CHÍNH

▸ 1. Cấu trúc các sheet trong file

Một file ITC dạng Line thường gồm: sheet cover (bìa, ghi tên tài liệu và luồng), sheet history (theo dõi sheet name, action, version tài liệu), sheet UI, và sheet test case (ITC). Điểm khác cốt lõi so với Unit Test: mỗi sheet/file ITC ứng với một luồng (ví dụ Luồng 1), chứ không phải một màn hình.

▸ 2. Các cột và bộ trạng thái

Cột chính của test case gồm: test case name, step by step, expected result (kết quả mong đợi), status, người thực thi, ngày thực thi, môi trường, ghi chú, và có thể thêm bug ID. Bộ trạng thái (đặt ở sheet 99-config): Not yet (chưa làm), OK (pass — test thành công), Not good (có bug), Pending (tạm hoãn), Cancel (hủy).

▸ 3. Thống kê bằng COUNTIF

Tạo sheet summary (hoặc thống kê ngay trên sheet cover). Dùng hàm COUNTIF đếm số test case theo từng trạng thái, nhớ khóa vùng bằng F4. Tính tổng bằng SUM rồi trừ Cancel ra (test case Cancel không tính vào tổng). Lấy số của một trạng thái chia cho tổng, định dạng phần trăm để biết tỷ lệ — ví dụ Not yet 89%, OK 11% trên tổng 9 test case. Có thể thống kê riêng theo môi trường (Chrome…) bằng cách đổi cột tham chiếu trong công thức.

Chương 3 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học hướng dẫn tạo file Integration Test Case (ITC) bằng Excel theo dạng Matrix (ma trận) — khác với dạng Line ở bài trước. Điểm đặc trưng của dạng này là đánh dấu kết quả bằng ký hiệu maru (dấu tròn kiểu Nhật). Template matrix về cơ bản giống Unit Test Case, chỉ khác cách trình bày: mỗi bước kiểm tra được tick theo ma trận thay vì viết thành từng dòng riêng.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu cách trình bày test case theo dạng Matrix và khi nào dùng dạng này.
• Biết cách đánh dấu maru (dấu tròn) hoặc chữ O để ghi nhận kết quả kiểm tra.
• Nắm được các trường thông tin của template: điều kiện tiên quyết, kết quả xác nhận, round test, ngày tạo/review/thực thi.

─── NỘI DUNG CHÍNH

▸ 1. Dạng Matrix và ký hiệu maru

Ở dạng Matrix, mỗi bước test được đánh dấu bằng maru — dấu tròn trong tiếng Nhật. Bạn có thể gõ chữ "maru" trong bộ gõ tiếng Nhật để ra hình tròn, hoặc đơn giản dùng chữ O (Shift + O) cũng được. Cách đánh này ban đầu hơi lạ nếu chưa quen, nhưng bản chất không phức tạp.

▸ 2. Cách ghi một luồng test

Template gồm cột điều kiện tiên quyết, nội dung kiểm tra, và kết quả sau khi xác nhận. Ví dụ một luồng: vào màn hình login → hiển thị màn hình login khi chưa có thông tin đăng nhập → đăng nhập thành công → di chuyển đến màn hình list user. Với mỗi bước, bạn rê chuột và đánh maru vào ô tương ứng để đánh dấu đã kiểm tra.

▸ 3. Round test và thông tin template

Template có 2 round (Round 1, Round 2) để ghi nhận nhiều lần test. Nếu test OK thì đánh OK kèm ngày test lại. Ngoài phần test case, template còn có các trường: ngày tạo, người tạo, ngày review, ngày thực thi. Sheet summary đã dựng sẵn để tổng hợp số lượng test case (có thể phải chỉnh lại công thức nếu bị lỗi nhẹ). File này sẽ được chia sẻ để bạn tải về dùng làm mẫu.

Chương 3 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chỉ cách chuyển các file Integration Test Case đã tạo bằng Excel (cả dạng Line lẫn Matrix) sang Google Sheets. Điểm mấu chốt rất đơn giản: bạn không cần dựng lại từ đầu — chỉ cần đưa file Excel lên Google Drive rồi dùng lệnh Save as Google Sheets để chuyển đổi. Nhờ vậy file test case load nhanh hơn và tiện làm việc online, chia sẻ.

─── SAU BÀI HỌC, BẠN SẼ

• Đưa được file Excel test case lên Google Drive để chuẩn bị chuyển đổi.
• Chuyển file Excel sang Google Sheets bằng lệnh File → Save as Google Sheets.
• Nhận biết icon phân biệt file Excel và file Google Sheets sau khi convert.

─── NỘI DUNG CHÍNH

▸ 1. Đưa file Excel lên folder Drive

Chuẩn bị hai file template đã tạo ở các bài trước (dạng Line và dạng Matrix). Đóng các file đang mở, rồi kéo hai template này lên folder tài liệu trên Google Drive. Trong giao diện Drive, bạn sẽ thấy các file Excel hiển thị với icon đặc trưng của Excel.

▸ 2. Convert sang Google Sheets

Click đúp mở file Excel (ví dụ template dạng Line) — Drive mất một chút thời gian để load. Khi file đã mở, chọn File → Save as Google Sheets. Ngay tại thời điểm đó, hệ thống sẽ tạo ra một bản Google Sheets từ file Excel. Làm y hệt với file dạng Matrix: click đúp mở rồi File → Save as Google Sheets.

▸ 3. Phân biệt file sau khi convert

Sau khi convert, để ý icon của hai file sẽ khác nhau: một cái là Excel, một cái là Google Sheets. Bản Google Sheets giữ nguyên template, bạn vẫn dùng bình thường để viết test case. Đây là cách nhanh nhất để có file test case chạy trực tiếp trên Google Sheets mà không phải làm lại từ đầu.

Chương 3 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu Screen Flow — sơ đồ luồng màn hình, mô tả người dùng đi từ màn hình này sang màn hình khác như thế nào theo luồng nghiệp vụ. Điểm mấu chốt: trước khi viết Integration Test Case, Screen Flow giúp bạn nhìn được bức tranh tổng thể của phần tích hợp — các màn hình liên đới ra sao — để biết cần viết test case cho những luồng nào và viết đã đầy đủ chưa.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu Screen Flow là gì và vì sao nó cần cho việc viết Integration Test Case.
• Vẽ được một Screen Flow cơ bản bằng công cụ miễn phí draw.io.
• Biết một cách vẽ thay thế: dùng shape và mũi tên ngay trong slide.

─── NỘI DUNG CHÍNH

▸ 1. Screen Flow là gì và dùng để làm gì?

Screen Flow chính là luồng nghiệp vụ giữa các màn hình. Vì Integration Test là kiểm thử tích hợp theo luồng, bạn cần thấy được data chuyển từ màn hình này sang màn hình kia thế nào. Sơ đồ này giúp định hình toàn cảnh sự liên đới giữa các màn hình — tương tự phần vẽ sơ đồ đã làm ở chương Unit Testing — để khi nhiệm vụ trải qua nhiều màn hình, bạn biết mình cần viết test case cho cái nào, đủ hay chưa.

▸ 2. Vẽ Screen Flow bằng draw.io

Truy cập draw.io, chọn Create New Diagram, đặt tên (ví dụ "01 Screen Flow") rồi Enter. Công cụ có sẵn rất nhiều template và hoàn toàn miễn phí. Bài demo vẽ luồng của ứng dụng bài tập: màn hình login → dùng mũi tên trỏ sang màn hình list (danh sách) → màn hình edit; edit xong quay lại list; từ list có nhánh xóa dẫn tới trạng thái xóa/không xóa, khi xóa thì thao tác thêm là xóa trong database. Có thể đánh số thứ tự và chỉnh text (edit text) cho từng bước để sơ đồ rõ ràng.

▸ 3. Cách vẽ thay thế bằng slide

Ngoài draw.io, bạn có thể vẽ Screen Flow ngay trong slide: vào Insert, vẽ các shape, rồi nối chúng bằng mũi tên (ví dụ màn hình login → màn hình list user). Dù dùng công cụ nào, mục tiêu cuối vẫn là thấy rõ bức tranh tổng thể để viết Integration Test Case cho mạch lạc.

Chương 3 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học nối tiếp Screen Flow đã vẽ ở bài trước, hướng dẫn dựa vào sơ đồ luồng màn hình để viết Integration Test Case (ITC) và thực hiện testing. Điểm mấu chốt: mỗi mũi tên chuyển màn hình trên Screen Flow chính là một test case cần viết. Cứ đi theo luồng, bạn viết được lần lượt các test case một cách đầy đủ và không bỏ sót.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cách đọc Screen Flow để xác định các test case cần viết.
• Viết được test case IT đầy đủ: test case name, các step, expected result.
• Viết liên tục theo luồng nghiệp vụ: login → list → edit → xóa/không xóa.

─── NỘI DUNG CHÍNH

▸ 1. Từ Screen Flow ra test case

Mở lại Screen Flow (trên draw.io) đã vẽ: login → màn hình danh sách; từ danh sách có nhánh xóa (hiện popup confirmation, xác nhận thì vào database xóa rồi quay lại danh sách) và nhánh edit (chuyển sang màn hình edit, sửa xong quay lại danh sách). Mỗi bước chuyển màn hình trên sơ đồ tương ứng với một test case cần viết.

▸ 2. Viết test case theo từng luồng

Viết lần lượt theo luồng:

• Kiểm tra chức năng chuyển màn hình từ login sang list: Step 1 vào màn hình login; Step 2 nhập thông tin, login thành công; expected result là vào màn hình danh sách user.
• Kiểm tra di chuyển vào màn hình edit: tại màn hình danh sách, click nút edit; kết quả là chuyển sang màn hình edit.
• Kiểm tra edit thành công và quay lại list: tại màn hình edit, chỉnh sửa thông tin một user bất kỳ, Save; kết quả là save thành công và quay lại màn hình list user.

▸ 3. Nhánh xóa và không xóa

Ở màn hình list, viết test case cho chức năng xóa: click nút xóa → hiện popup confirmation → chọn xóa → dữ liệu user bị xóa khỏi database (phải vào database xác nhận) → quay lại màn hình list. Đối chiếu với nhánh không xóa: khi chọn không xóa thì không có action nào tác động lên dữ liệu, và cũng quay lại màn hình list. So sánh hai nhánh giúp bạn thấy rõ điểm giống và khác để viết test case cho trọn vẹn.

Chương 3 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Sau khi viết xong Integration Test Case, phần thường bị bỏ quên là định dạng tài liệu trước khi deliver cho khâu tiếp theo. Bài học cho thấy file ITC được chuẩn hóa giống hệt cách bạn đã làm với file Unit Test Case — vì bản chất nó cũng chỉ là một file test case. Điểm mấu chốt: nội dung đúng chưa đủ, file phải gọn gàng và sẵn sàng in thì mới xem là hoàn thiện.

─── SAU BÀI HỌC, BẠN SẼ

• Biết vì sao file ITC cần được định dạng chỉn chu trước khi giao đi.
• Áp dụng lại quy trình full format đã học ở Unit Test Case cho file ITC.
• Ghi đúng thông tin thay đổi vào sheet History khi cập nhật tài liệu.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao phải định dạng file ITC trước khi giao?

Nhiều bạn viết xong test case là gửi luôn, không để ý file sẽ được deliver đi như thế nào. Integration Test Case không khác gì Unit Test Case về mặt trình bày — cũng là một file test case cần được định dạng lại cho hợp lý, gọn gàng trước khi giao cho khâu sau. Một file đẹp, đúng chuẩn thể hiện sự chuyên nghiệp và giúp người nhận đọc dễ hơn.

▸ 2. Các bước chuẩn hóa file

Áp dụng lại đúng quy trình full format đã học:

• Đưa mọi sheet về chế độ Page Break Preview và kéo con trỏ về ô A1 ở tất cả các sheet.
• Chỉnh zoom về mức thống nhất (100% hoặc 85%) cho dễ nhìn.
• Tô màu các tiêu đề theo đúng checklist / form mẫu của dự án.
• Với sheet dữ liệu chính: kéo giãn cột cho dễ đọc; sheet config thì ẩn đi; sheet History thì định dạng lại cho ngay ngắn.

▸ 3. Ghi lịch sử vào sheet History

Mỗi lần cập nhật, ghi lại thay đổi vào sheet History: cột Action (ví dụ add new sheet), version (ví dụ 1.0) và mô tả ngắn. Đây là dấu vết để theo dõi tài liệu đã được sửa gì qua từng phiên bản.

▸ Mẹo quan trọng: theo đúng form mẫu của dự án

Mọi quy ước "đẹp" — màu tiêu đề, cách canh cột, cách ghi version — đều nên tuân theo form mẫu / checklist của công ty hoặc dự án, đừng làm theo cảm tính. Khi đã quen và có sẵn tool hỗ trợ, định dạng xong một file chỉ mất khoảng 5 phút.

Chương 3 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giải một bài tập Integration Test Case thực tế cho luồng ba màn hình Login → Danh sách → Edit, để bạn quen cách nhìn nghiệp vụ và viết test case IT. Điểm mấu chốt: trước khi viết, hãy vẽ Screen Flow để thấy rõ luồng đi qua từng màn hình, rồi mới bật file test case lên viết theo. Integration Test kiểm tra sự kết nối giữa các màn hình chứ không chỉ một màn hình đơn lẻ.

─── SAU BÀI HỌC, BẠN SẼ

• Vẽ được Screen Flow cho một luồng nghiệp vụ trước khi viết ITC.
• Viết được test case IT theo từng step cho luồng login, list, edit, delete.
• Biết phân biệt xóa vật lý và xóa luận lý, và vì sao phải xác nhận trên database.

─── NỘI DUNG CHÍNH

▸ 1. Vẽ Screen Flow trước khi viết

Kinh nghiệm thực chiến: luôn vẽ Screen Flow trước. Với bài tập gồm màn hình login, màn hình danh sách và màn hình edit, bạn vẽ luồng nghiệp vụ đơn giản để thấy rõ nó đi qua mấy bước, thứ tự ra sao. Có được cái nhìn tổng thể này rồi mới bật file test case lên viết thì sẽ nhanh và không sót luồng.

▸ 2. Viết test case IT theo từng step

Mỗi test case IT mô tả một luồng nghiệp vụ trọn vẹn. Ví dụ luồng vào màn hình edit:

1. Đăng nhập thành công.
2. Vào màn hình list user.
3. Search một user bất kỳ đang tồn tại.
4. Click button Edit để vào màn hình edit.

Kết quả mong đợi: vào được màn hình edit. Tương tự, luồng xóa user gồm: đăng nhập → vào màn hình list → search → click Delete → xác nhận trên popup → kết quả xóa được user đã chọn. Một luồng cơ bản như vậy chỉ cần khoảng mười tới hai chục test case IT là quá đủ.

▸ 3. Xóa vật lý và xóa luận lý — xác nhận trên database

Với nghiệp vụ xóa, nên ghi thêm bước xác nhận trên database. Thực tế hầu hết hệ thống không xóa vật lý (xóa mất data) mà xóa luận lý: bật cờ `is_deleted = 1` để record không hiển thị nhưng vẫn còn trong database. Các hệ thống lớn như ngân hàng gần như luôn xóa luận lý để lưu trữ dữ liệu. Việc xác nhận nên là luận lý hay vật lý phải căn cứ requirement của khách hàng — nếu không rõ thì hỏi lại khách hàng.

Chương 3 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học làm rõ ranh giới giữa Integration Test Case và Integration Test Report: cùng một file, nhưng khi bạn điền trạng thái test, ngày test và Bug ID vào thì nó chuyển từ test case thành test report. Điểm mấu chốt đáng nhớ: khi test trên nhiều môi trường (Chrome, Firefox, Edge…), đừng bao giờ duplicate cả sheet — hãy thêm cột cho từng môi trường để tránh dữ liệu bị nhân bản.

─── SAU BÀI HỌC, BẠN SẼ

• Phân biệt được test case và test report qua các thông tin trạng thái đã điền.
• Thiết kế cột cho nhiều môi trường test mà không phải duplicate sheet.
• Hiểu vì sao phải giữ lại Bug ID để tracking sau này.

─── NỘI DUNG CHÍNH

▸ 1. Từ test case sang test report

Một file mới chỉ ghi nội dung kiểm tra thì vẫn là test case. Khi bạn thực thi và điền thêm trạng thái test, ngày test, và Bug ID (mã ticket sau khi log bug lên hệ thống), file đó trở thành test report. Nói cách khác, report chính là test case đã được chạy và ghi lại kết quả.

▸ 2. Test nhiều môi trường: thêm cột, đừng duplicate sheet

Sai lầm phổ biến là duplicate sheet ra thành "test cho Chrome", "test cho Edge"… Hậu quả: mỗi lần sửa một test case, bạn phải cập nhật lại tất cả các sheet — rất dễ sai lệch. Thay vào đó, giữ một sheet duy nhất và thêm cột cho từng môi trường. Mỗi môi trường chỉ cần đủ ba thông tin:

1. Trạng thái test của môi trường đó.
2. Cột Bug ID hoặc Note cho môi trường đó.
3. Ngày thực thi.

Người tester thường là một người nên không cần lặp lại cột người test cho từng môi trường.

▸ Lưu ý quan trọng: không bao giờ xóa Bug ID

Khi developer đã fix xong và bạn retest ok, hãy đổi trạng thái sang OK nhưng giữ nguyên Bug ID — đừng xóa. Bug ID là mối liên kết để sau này tracking lại: test case nào từng bắt được bug nào. Tốt nhất, trong bug cũng ghi kèm Test Case ID; nếu không kịp thì tối thiểu phải giữ liên kết ở field Bug ID.

Chương 4 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mở đầu chương về log và monitoring bug, bài học trả lời câu hỏi nền tảng: vì sao phải log bug lên hệ thống quản lý dự án thay vì chỉ báo miệng. Điểm mấu chốt: log bug là việc bắt buộc của người QC — nó tạo ra bản ghi (record) để theo dõi vòng đời lỗi và làm căn cứ báo cáo chất lượng sản phẩm. Bài giới thiệu nguyên lý chung, không giới hạn ở một công cụ cụ thể nào.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu bug là gì và những loại vấn đề nào có thể log lên hệ thống.
• Nắm được vòng đời cơ bản của một bug từ new đến close.
• Giải thích được vì sao báo miệng không thể thay cho việc log bug.

─── NỘI DUNG CHÍNH

▸ 1. Bug là gì và log những gì?

Bug là lỗi của sản phẩm phần mềm — nhưng không chỉ vậy. Lỗi ở tài liệu (tài liệu thiết kế, spec…) hay các loại vấn đề khác của dự án đều có thể log lên hệ thống. Nếu chỉ log khi phần mềm có lỗi thì chưa đầy đủ; hầu hết mọi lỗi và vấn đề của dự án đều nên được ghi nhận để quản lý tập trung.

▸ 2. Vòng đời của một bug

Một bug đi qua các trạng thái cơ bản: New → Assign → Open → Fix → Retest → Verify → Close. Nếu retest không đạt thì Reopen để fix lại. Khi log lên, bạn còn xác định vấn đề đó thực sự là bug hay là change request / vấn đề khác. Với những bug có độ ưu tiên hoặc Severity (độ ảnh hưởng) không cao, có thể pending để fix sau rồi vẫn deliver sản phẩm.

▸ 3. Vì sao không thể chỉ báo miệng?

Báo miệng cũng có thể fix được, nhưng không để lại record. Khi đó bạn không có cách nào chứng minh đã phát hiện bug, cũng không thể báo cáo chất lượng sản phẩm ra sao. Log bug lên hệ thống chính là cách nhìn vào sản phẩm để đánh giá chất lượng và các vấn đề còn tồn đọng — vì thế đây là bước bắt buộc, tuyệt đối đừng bỏ qua.

Chương 4 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học liệt kê những hạng mục thông tin tối thiểu để mô tả một bug cho đầy đủ, rõ ràng. Điểm mấu chốt và cũng dễ nhầm nhất: phân biệt Severity (mức độ nghiêm trọng) với Priority (độ ưu tiên) — hai khái niệm không phải lúc nào cũng đi cùng chiều. Nắm rõ từng trường thông tin giúp bạn tự tạo được form bug trên Google Sheets hay Excel khi hệ thống không có sẵn.

─── SAU BÀI HỌC, BẠN SẼ

• Liệt kê được các thông tin cơ bản cần có của một bug.
• Phân biệt rõ Severity và Priority qua ví dụ cụ thể.
• Tự thiết kế được form bug khi phải tự setup trên Excel / Google Sheets.

─── NỘI DUNG CHÍNH

▸ 1. Các thông tin cơ bản của một bug

Một bug tối thiểu cần có:

• Tiêu đề — tên hiện tượng của bug.
• Mô tả và các bước tái hiện (từng step dẫn tới lỗi).
• Severity — mức độ nghiêm trọng, và Priority — độ ưu tiên.
• Phân loại bug và nguyên nhân (ví dụ bug layout).
• Bug thuộc file nào: Unit Test hay Integration Test.
• Assignee — người được giao xử lý bug.
• Hình ảnh / video tái hiện bug (bắt buộc khi tester log bug).

▸ 2. Phân biệt Severity và Priority

Severity là mức độ nghiêm trọng của lỗi; Priority là mức cần sửa sớm hay muộn. Hai giá trị này có thể ngược chiều nhau:

• Logo website sai chính tả: không ảnh hưởng hệ thống nên Severity thấp, nhưng ảnh hưởng hình ảnh công ty nên Priority cao.
• Game 10 level, tới level 9 thì app chết: rất nghiêm trọng nên Severity cao, nhưng vì ít người lên tới đó nên Priority thấp, có thể sửa sau.

Tùy tình huống mà xác định tương quan giữa hai giá trị này.

▸ 3. Khi phải tự setup form bug

Trong các hệ thống quản lý sẵn có, những trường này thường được cung cấp sẵn — bạn chỉ cần click và điền theo. Nhưng khi tự setup trên Google Sheets hay Excel, bạn phải hiểu rõ ý nghĩa từng thông tin để tạo đủ các trường cho một bug hoàn chỉnh.

Chương 4 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học giới thiệu ba công cụ để quản lý bug: Redmine, Excel và Google Sheets (Spreadsheet). Điểm mấu chốt: dù dùng công cụ nào, bản chất vẫn là cùng một bộ trường thông tin của bug — Redmine cung cấp sẵn qua bug template, còn Excel/Sheets thì bạn tự tạo các field tương ứng. Hiểu nguyên lý này thì đổi công cụ nào bạn cũng làm được.

─── SAU BÀI HỌC, BẠN SẼ

• Biết ba lựa chọn công cụ phổ biến để log và quản lý bug.
• Nhận ra bộ trường thông tin của một bug là như nhau giữa các công cụ.
• Hình dung được cách một bug template trên Redmine trông ra sao.

─── NỘI DUNG CHÍNH

▸ 1. Redmine — hệ thống quản lý bug dựng sẵn

Bài học demo một Redmine đã được build sẵn. Sau khi login, bạn lọc Tracker is bug để xem danh sách bug. Khi tạo bug mới, chọn New issue → Bug → bug template, hệ thống sẽ bung ra sẵn các trường cần điền — bạn chỉ việc nhập nội dung.

▸ 2. Excel và Google Sheets — tự tạo trường

Nếu không dùng Redmine, bạn có thể quản lý bug bằng Google Sheets (Spreadsheet) hoặc Excel. Cách làm: tự tạo các field giống như các trường của Redmine, rồi log bug xuống lần lượt. Trường đầu tiên và quan trọng là Bug ID. Excel và Google Sheets tương tự nhau, chỉ cần copy mẫu về là dùng được.

▸ 3. Bộ trường thông tin của một bug

Dù ở công cụ nào, một bug đầy đủ đều cần các trường bắt buộc như nhau:

• Các bước tái hiện.
• Actual result và Expected result.
• Additional information.
• Target version, Severity, Priority, Assignee.

Nắm được bộ trường này, bạn có thể log bug nhất quán trên Redmine, Excel hay Google Sheets. Các bài sau sẽ hướng dẫn chi tiết cách tạo những trường này thành một file hoàn chỉnh trên từng công cụ.

Chương 4 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học demo trọn quy trình log một bug thật lên Redmine, bắt đầu từ lúc thực thi file test case và bắt gặp lỗi. Điểm mấu chốt: bug và test case phải được liên kết hai chiều — file test case ghi lại Bug ID của Redmine, còn issue trên Redmine ghi kèm Test Case ID (UTC ID) — để sau này truy vết dễ dàng.

─── SAU BÀI HỌC, BẠN SẼ

• Thực hiện được quy trình từ đánh Not good trong test case đến tạo issue trên Redmine.
• Điền đúng các trường của một bug: mô tả, bước tái hiện, kết quả, assignee, severity/priority.
• Liên kết hai chiều Bug ID và Test Case ID giữa file test case và Redmine.

─── NỘI DUNG CHÍNH

▸ 1. Từ test case tới việc phát hiện bug

Thực thi file test case, ví dụ test case số 1 của màn hình login: kiểm tra giao diện, màu sắc có khớp với UI thiết kế không. Nếu đạt thì đánh OK; nếu lỗi thì đánh Not good, ghi người test và ngày test, rồi chuẩn bị chỗ để điền Bug ID.

▸ 2. Tạo bug trên Redmine

Sang Redmine, chọn New issue → Bug → bug template để hệ thống bung ra mẫu. Điền các trường dựa trên test case:

1. Mô tả: ví dụ "Lỗi giao diện khi hiển thị màn hình login, màu sắc chưa đúng yêu cầu".
2. Bước tái hiện: vào được màn hình login, thực hiện kiểm tra.
3. Actual result: button đang bị màu đỏ, không click được.
4. Expected result: hiển thị đúng tài liệu, như hình đính kèm.
5. Assignee: gán cho một bạn dev; đặt ngày mong muốn; chọn Severity/Priority (ở đây cao vì không vào được màn hình tiếp theo).

Nhớ chụp hình layout lỗi để đính kèm làm bằng chứng tái hiện, rồi submit.

▸ 3. Liên kết hai chiều test case và bug

Sau khi submit, Redmine trả về mã ID của bug — đưa ID này vào cột Bug ID trong file test case. Ở chiều ngược lại, trên Redmine ghi kèm Test Case ID (UTC ID): nếu hệ thống có sẵn trường Test Case ID thì điền vào đó, không thì đưa lên Subject hoặc phần mô tả phía dưới đều được. Nhờ liên kết hai chiều này, bạn luôn biết bug thuộc test case nào và test case nào đã bắt được bug đó.

Chương 4 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Không phải dự án nào cũng có hệ thống quản lý như Redmine. Khi làm ở một nhóm hoặc dự án nhỏ không có công cụ quản lý, bạn vẫn cần một chỗ để log bug — và Excel hoặc Spreadsheet chính là lựa chọn thay thế. Bài học chỉ cách tự dựng một file log bug mô phỏng lại đúng các trường của hệ thống quản lý, để dùng chung cho cả nhóm. Điểm mấu chốt: bản chất công cụ nào cũng như nhau, quan trọng là quy định rõ ai log, ai fix, chuyển trạng thái ra sao.

─── SAU BÀI HỌC, BẠN SẼ

• Biết cách ánh xạ các trường của Redmine (Tracker, Bug ID, Subject, Description, Status, Priority, Assignee…) sang một file Spreadsheet.
• Tạo được combo box chọn giá trị cho các trường như Status, Priority, Severity bằng Data Validation.
• Định dạng file log bug gọn gàng để nhóm dùng chung.

─── NỘI DUNG CHÍNH

▸ 1. Thiết kế template mô phỏng hệ thống quản lý

Mục tiêu là làm cho file Spreadsheet có đủ các trường cần thiết giống một ticket bug trên Redmine. Chừa dòng/cột đầu để đánh số thứ tự (Column), rồi lần lượt tạo các trường: Tracker (giá trị Bug), Bug ID, Subject, Description, Status, Priority, Assignee cùng các trường liên quan. Khi đã có đủ các trường này thì coi như bạn đã dựng xong khung template.

▸ 2. Tạo combo box bằng Data Validation

Với các trường có giá trị cố định — Status (new…), Priority (low, normal, high, urgent, immediate), Severity (critical, major, minor, trivial) — hãy tạo một sheet cấu hình riêng (ví dụ đặt tên config) liệt kê sẵn các giá trị. Sau đó chọn vùng cần áp dụng, vào Data → Data validation, chọn kiểu dropdown và trỏ range tới vùng giá trị trong sheet config. Nhấn OK là ô đó có combo box để chọn nhanh, hạn chế nhập sai.

▸ 3. Định dạng và chia sẻ file dùng chung

Tô màu tiêu đề, kẻ border, merge và wrap text cho cột Description để nội dung dài không bị tràn. Khi file đã gọn gàng giống một file tracking bug thật, việc còn lại chỉ là fill data: ví dụ một bug lỗi button login gồm bước tái hiện, actual result, expected result, status new, priority cao. Cuối cùng, phân quyền và share file cho tất cả các bên cùng log bug — sao cho dễ input, dễ sử dụng.

Chương 5 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mở đầu chương 5 về kỹ thuật tổng kết số liệu và báo cáo, bài học giải thích Test Plan là gì và vì sao dự án cần nó. Hiểu đơn giản, Test Plan là kế hoạch, chiến lược để thực hiện việc testing sao cho sản phẩm phần mềm đạt chất lượng. Bài đi qua một file template Test Plan mẫu, giải thích từng sheet để bạn hình dung một tài liệu Test Plan hoàn chỉnh trông như thế nào.

─── SAU BÀI HỌC, BẠN SẼ

• Trả lời được câu hỏi "bạn biết làm Test Plan không?" theo đúng bản chất công việc.
• Nắm được các thành phần chính của một tài liệu Test Plan.
• Biết cách tùy chỉnh template Test Plan theo đặc thù dự án của mình.

─── NỘI DUNG CHÍNH

▸ 1. Test Plan là gì?

Chữ "plan" ở đây mang nghĩa lên kế hoạch cho việc testing. Đây là một tài liệu focus vào khâu test: định ra làm gì, làm thế nào, ai làm, khi nào để sản phẩm đạt chất lượng. Để lập được kế hoạch đó, bạn cần hiểu rõ nhiều thứ về dự án — nên Test Plan phản ánh mức độ nắm việc của người QC.

▸ 2. Các sheet trong template Test Plan

Template mẫu gồm nhiều sheet nối tiếp nhau:

• Giới thiệu: định nghĩa các thuật ngữ dùng trong tài liệu (acceptance test, quality control, quality assurance, program test…).
• Requirement for test: liệt kê những gì cần test — functional và non-functional requirements.
• Acceptance test criteria: điều kiện để chấp nhận file test là pass (ví dụ tiêu chí về coverage, số lượng test case theo catalog).
• Test strategy: chiến lược test — đối tượng test, kỹ thuật test, điều kiện hoàn thành, chuẩn bị môi trường/thiết bị.
• Result: nguồn lực con người (human resource) và test management — cách tracking bug, communication, quản lý bug và test case.
• Test environment: liệt kê toàn bộ môi trường, hardware, software cần có trước khi test.
• Test milestone: các mốc hoàn thành theo mốc thời gian (xong test case, test xong và đếm bug…).
• Deliverable: các sản phẩm bàn giao cho phase sau hoặc cho khách hàng (ví dụ file unit test case), kèm ngày dự kiến và ngôn ngữ tài liệu.

▸ 3. Template chỉ là mẫu — hãy tùy chỉnh

Template được cung cấp sẵn để bạn thấy một Test Plan gồm những gì. Trong thực tế, hãy tinh chỉnh nó theo đặc thù dự án của mình chứ đừng bê nguyên. Nắm được tổng thể này thì khi ai đó nhắc tới Test Plan, bạn dựng được ngay bức tranh toàn cảnh cho khâu test.

Chương 5 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mỗi ngày, người viết test case hoặc team lead cần thu thập số liệu: hôm nay tạo được bao nhiêu case, bao nhiêu OK, bao nhiêu Not Good. Nếu mở từng file Excel rồi chép tay số liệu thì rất mất thời gian và dễ sai. Bài học giới thiệu một công cụ tự viết (được chia sẻ trong folder công cụ của khóa) giúp lấy tự động giá trị tại một ô cố định trong nhiều file test case cùng lúc.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao cần một công cụ để collect số liệu test case thay vì chép tay.
• Xác định đúng vị trí ô cần lấy bằng chỉ số column và row.
• Dùng công cụ để gom số liệu status (OK / Not Good / Cancel) từ nhiều file một lần.

─── NỘI DUNG CHÍNH

▸ 1. Bài toán: gom số liệu từ nhiều file test case

Giả sử bạn có nhiều file test case (ví dụ 4 file), mỗi file có phần thống kê status: N (not yet), NG (not good), OK, Cancel, cùng các loại test case như normal, abnormal, boundary. Hằng ngày cần biết mỗi file cho ra bao nhiêu case ở từng trạng thái. Mở lần lượt từng file để ghi lại là cách làm thủ công, chậm và dễ nhầm.

▸ 2. Công cụ "get giá trị của cell"

Công cụ hoạt động bằng cách trỏ tới ô cần lấy trong các file. Bạn cần khai báo:

• Đường dẫn chứa các file test case.
• Sheet name: tên sheet chứa dữ liệu cần lấy.
• Column index: chỉ số cột (ví dụ cột 8 đến cột 14).
• Row index: chỉ số dòng chứa số liệu tổng kết.
• Title: nhãn cho các cột status để dán vào bảng kết quả.

Mẹo xác định column/row: mở file test case, đếm đúng thứ tự cột và dòng của ô muốn lấy rồi điền vào tool.

▸ 3. Chạy Get & Go và tra ngược về file gốc

Sau khi điền đủ tham số, đóng các file test case đang mở rồi nhấn Get & Go. Công cụ sẽ quét toàn bộ file trong đường dẫn và đổ số liệu status của từng file vào bảng tổng hợp. Tiện lợi hơn nữa: khi click vào một dòng kết quả, nó mở thẳng file gốc và nhảy tới đúng ô đã lấy — rất tiện để kiểm tra lại. Ngoài số lượng test case, bạn có thể dùng cùng cách này để lấy bất kỳ giá trị nào ở các ô cố định.

Chương 5 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Có số liệu test case rồi, bước tiếp theo là tính năng suất — trung bình một tiếng, một ngày làm được bao nhiêu test case. Bài học dựng một bảng Excel giả định để minh họa cách tính, từ đó biết ai đạt năng suất, ai chậm để tập trung hỗ trợ. Điểm mấu chốt rất đơn giản: năng suất = tổng số test case chia cho tổng thời gian (effort) bỏ ra; công cụ nào cũng tính giống nhau.

─── SAU BÀI HỌC, BẠN SẼ

• Tính được năng suất theo ba góc nhìn: theo khoảng thời gian, theo từng ngày, và theo từng người.
• Dùng hàm NETWORKDAYS để đếm số ngày làm việc, loại bỏ thứ Bảy và Chủ nhật.
• Đọc bảng năng suất để nhận ra ai đang chậm cần được hỗ trợ.

─── NỘI DUNG CHÍNH

▸ 1. Dựng bảng dữ liệu theo ngày và theo người

Lập một trục thời gian (ví dụ trải dài khoảng hai tuần), ghi rõ mỗi ngày là thứ mấy và tô màu ngày nghỉ (thứ Bảy, Chủ nhật) để loại khỏi tính toán. Với mỗi ngày làm việc, ghi lại theo từng doer (người làm): số test case họ tạo mới và spend time (số giờ họ bỏ ra hôm đó). Đây là dữ liệu gốc để tính năng suất.

▸ 2. Ba cách tính năng suất

Nguyên tắc chung là lấy tổng test case ÷ tổng effort, áp cho từng phạm vi:

• Theo khoảng thời gian: cộng tổng test case của cả nhóm chia cho tổng số giờ để ra năng suất trung bình mỗi giờ, rồi nhân với số giờ một ngày công để ra năng suất một ngày của cả team.
• Theo từng ngày: với mỗi ngày, lấy tổng test case của ngày chia cho tổng spend time của ngày đó — năng suất sẽ dao động lên xuống theo ngày.
• Theo từng người: lấy tổng test case của một người chia cho tổng effort của chính người đó, để so sánh ai cao ai thấp.

▸ 3. Đếm ngày làm việc bằng NETWORKDAYS

Để tính tổng effort chuẩn, cần biết chính xác số ngày làm việc trong kỳ. Dùng hàm NETWORKDAYS(start, end) — hàm này tự bỏ qua thứ Bảy và Chủ nhật, trả về đúng số ngày công. Từ số ngày làm việc nhân số giờ mỗi ngày ra tổng giờ, rồi áp công thức năng suất ở trên.

▸ 4. Đọc bảng để ra quyết định

Khi bảng đã có năng suất theo người, theo ngày và theo kỳ, bạn có thể phán đoán ai đạt hay không đạt. Người nào năng suất chậm thì focus vào tìm hiểu nguyên nhân và hỗ trợ. Đó là giá trị thực của việc đo năng suất: không chỉ để báo cáo mà để quản lý và cải thiện đội.

Chương 5 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài trước lấy số liệu test case từ file Excel bằng công cụ riêng. Bài này giải quyết cùng bài toán nhưng cho file Spreadsheet (Google Sheet) — nơi cách làm khác hẳn. Ý nghĩa công việc thì như nhau, nhưng mỗi công cụ có cơ chế riêng: với Google Sheet, bạn dùng hàm IMPORTRANGE để kéo dữ liệu từ file test case này sang bảng thống kê ở file khác một cách tự động và cập nhật liên tục.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao Spreadsheet cần cách lấy số liệu khác với Excel.
• Dùng được hàm IMPORTRANGE để lấy dữ liệu từ một file Spreadsheet khác.
• Dựng một bảng monitor tổng hợp số liệu test case từ nhiều file, tự cập nhật khi tester chỉnh sửa.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao dùng IMPORTRANGE

Mỗi file test case là một file Spreadsheet riêng. Để một bảng tổng hợp (monitor) hiển thị số liệu Summary của tất cả các file, ta không chép tay mà dùng IMPORTRANGE — hàm kéo một vùng dữ liệu từ file nguồn về file đích. Đây chính là cơ chế lấy data giữa các Spreadsheet/Google Sheet online.

▸ 2. Cú pháp và cách dùng

IMPORTRANGE cần hai tham số chính:

1. URL (hoặc key) của file Spreadsheet nguồn — copy đường dẫn của file cần lấy.
2. Chuỗi range dạng `"Tên_sheet!Vùng"` — ví dụ lấy vùng `B5:C5` của Sheet1, hay ô Summary cần theo dõi.

Lần đầu tham chiếu tới một file khác, Google Sheet hiện nút Allow access — bạn phải nhấn cho phép thì dữ liệu mới đổ về. Sau khi Enter, ô đích hiển thị đúng giá trị đang có ở file nguồn.

▸ 3. Tự cập nhật và nhân bản cho nhiều file

Điểm mạnh: khi tester mở file test case gốc và sửa số liệu (ví dụ đổi số OK), thì bảng tổng hợp bên này tự cập nhật theo (có độ trễ nhẹ). Lặp lại IMPORTRANGE cho từng link test case — mỗi file một dòng — bạn dựng được một bảng thống kê sống, luôn phản ánh số liệu mới nhất mà không phải mở từng file. Đây là cách monitor test case mỗi ngày trên nền Spreadsheet.

Chương 5 · Bài 5

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Ngoài số liệu test case, quá trình testing còn một loại số liệu quan trọng: bug. Bug được phát hiện mỗi ngày, được giải quyết mỗi ngày, và có xu hướng tăng/giảm theo thời gian. Bài học chỉ cách thống kê số liệu bug ngay trên file Excel/Spreadsheet để phán đoán được tình hình dự án — bug có đang giảm không, màn hình nào nhiều bug, còn tồn bao nhiêu. Cách làm dựa vào các hàm đếm quen thuộc và tùy theo góc nhìn cần quản lý.

─── SAU BÀI HỌC, BẠN SẼ

• Xác định được những tiêu chí bug đáng thống kê theo kinh nghiệm thực tế.
• Dùng các hàm COUNTIF/COUNTIFS và UNIQUE để đếm bug theo ngày và theo trạng thái.
• Trực quan hóa kết quả bằng biểu đồ và hiểu cùng công thức chạy được trên cả Excel lẫn Google Sheet.

─── NỘI DUNG CHÍNH

▸ 1. Nên thống kê những gì về bug

Dựa vào kinh nghiệm làm thực tế, những góc nhìn đáng theo dõi gồm: số bug được phát hiện mỗi ngày, số bug được giải quyết mỗi ngày (dựa theo trường modify và status của bug), ai log bug và ai xử lý bug (author, person in charge), cùng xu hướng bug hiện tại. Nhờ liên kết Bug ID với Test Case ID, còn biết được một bug ảnh hưởng tới bao nhiêu test case (các trường re-test, modify test, percent check).

▸ 2. Đếm bug theo ngày

Trước tiên xác định khoảng ngày cần thống kê: dùng hàm MIN để tìm ngày log bug đầu tiên và MAX để tìm ngày cuối, rồi trải các ngày ở giữa. Với mỗi ngày, dùng COUNTIFS với điều kiện Tracker = bug và Reg date = ngày tương ứng để ra số bug phát hiện trong ngày đó. Cách này cho bạn biểu đồ số lượng bug tạo ra mỗi ngày.

▸ 3. Đếm bug theo trạng thái và vẽ biểu đồ

Để thống kê theo trạng thái, dùng hàm UNIQUE trên cột status của bug list để liệt kê ra tất cả các trạng thái hiện có mà không bị trùng. Sau đó dùng COUNTIF (Tracker = bug, kết hợp điều kiện cột status) để đếm số bug ở mỗi trạng thái. Kết quả có thể vẽ thành biểu đồ hình bánh để nhìn tỉ lệ trực quan.

▸ 4. Công thức dùng chung cho Excel và Spreadsheet

Bài demo trên Google Sheet, nhưng các công thức COUNTIF/COUNTIFS/UNIQUE hoạt động y hệt trên Excel, và đều có thể link tới sheet khác. Ở mảng thống kê bug này, Spreadsheet và Excel không khác gì nhau — cứ chọn tiêu chí theo nhu cầu dự án rồi áp đúng hàm là ra số liệu.

Chương 5 · Bài 6

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài trước thống kê bug từ file Google Sheet. Bài này chỉ cách lấy số liệu bug khi bug được quản lý trên hệ thống Redmine. Điểm mấu chốt rất đáng nhớ: gần như hệ thống quản lý nào cũng có chức năng export ra file CSV — nên chỉ cần export bug ra rồi import lại vào công cụ thống kê là bạn tận dụng được toàn bộ công thức đã học. Redmine chỉ là ví dụ; Jira, Backlog hay hệ thống khác đều làm tương tự.

─── SAU BÀI HỌC, BẠN SẼ

• Filter và export danh sách bug từ Redmine ra file CSV.
• Import file CSV vào Google Sheet để thống kê bằng hàm COUNTIF.
• Áp dụng cùng quy trình cho các hệ thống khác như Jira, Backlog.

─── NỘI DUNG CHÍNH

▸ 1. Filter và export bug từ Redmine

Vào Redmine, đặt bộ lọc Tracker = bug và Status = any để lấy toàn bộ bug (hệ thống khác thì filter theo cách của nó). Sau đó chọn chức năng export, chọn phạm vi cột (all column hoặc select column tùy nhu cầu), chọn encoding phù hợp rồi save file CSV về máy.

▸ 2. Import CSV vào Google Sheet

Trong file thống kê, tạo một sheet để chứa dữ liệu bug (ví dụ sheet số 5), chọn chức năng import, upload file CSV vừa export. Khi được hỏi tạo sheet mới hay dùng sheet hiện tại, chọn current sheet để đổ dữ liệu vào đúng sheet đã chuẩn bị, rồi nhấn import. Toàn bộ bug cùng các trường ID, Status, Priority… sẽ được nạp lên.

▸ 3. Thống kê và quy trình lặp lại

Có data rồi, dùng COUNTIF (và các hàm tương tự) để thống kê theo trạng thái, độ ưu tiên… đúng như đã học ở bài trước. Quan điểm làm việc: mỗi lần cần thống kê thì export lại từ Redmine và đổ đè vào sheet dữ liệu — các công thức ở những chỗ khác sẽ tự chạy theo và cập nhật bảng báo cáo đầy đủ.

▸ Mẹo quan trọng: một quy trình dùng cho mọi hệ thống

Đừng học riêng cho Redmine. Bản chất là export CSV → import → thống kê. Khi chuyển sang Jira, Backlog hay công cụ khác, bạn chỉ cần tìm chức năng export tương ứng rồi lặp lại đúng các bước trên — không có gì phải học lại từ đầu.

Chương 5 · Bài 7

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Đi làm ở công ty gia công phần mềm — hay bất kỳ công ty nào — thì báo cáo tổng hợp mỗi ngày là việc bắt buộc, đồng thời cũng là phần "đau đầu" nhất vì nhiều khi bạn không biết nói gì. Bài học đưa ra một danh sách đề mục cụ thể để bạn luôn có nội dung báo cáo rõ ràng cho khách hàng, cấp trên và cả các member trong nhóm. Cốt lõi: báo cáo là để chia sẻ tình hình hiện tại đang tới đâu.

─── SAU BÀI HỌC, BẠN SẼ

• Biết những đề mục cần báo cáo mỗi ngày trong phase testing.
• Diễn đạt được số liệu test case, bug, năng suất và tiến độ thành một bản báo cáo mạch lạc.
• Tự điều chỉnh nội dung báo cáo theo yêu cầu của người quản lý dự án.

─── NỘI DUNG CHÍNH

▸ 1. Báo cáo khối lượng tạo và test case

Báo cáo hôm nay bạn tạo được bao nhiêu test case cho màn hình nào (ví dụ: màn hình đăng ký user 15 test case), và dự kiến còn viết thêm bao nhiêu, khi nào xong. Đây là cách người nghe nắm được công việc đang chạy tới đâu.

▸ 2. Báo cáo chất lượng qua số liệu bug

Khi test một chức năng, hãy nêu rõ đã log bao nhiêu bug, bao nhiêu chưa fix, bao nhiêu đã fix và đang đợi retest. Ví dụ: chức năng list user đã log 50 bug, còn 35 bug chưa fix. Với số bug so với số test case như vậy, bạn đưa ra nhận định chất lượng có vấn đề và nhờ development team xem lại.

▸ 3. Báo cáo năng suất

Năng suất được tính bằng cách đo đạc từng ngày (đã hướng dẫn ở video trước). Ví dụ tổng 2000 test case, năng suất khoảng 35 test case/ngày. Năng suất test tính tương tự năng suất tạo: lấy tổng số test case thực hiện mỗi ngày chia cho thời gian spend ra.

▸ 4. Báo cáo tiến độ tổng thể

Nêu dự án đạt bao nhiêu phần trăm cho phase testing. Thông thường không tính theo đơn vị màn hình mà theo test case: lấy số test case thực tế chia cho tổng số test case dự kiến trong plan. Ví dụ plan 150 test case, thực tế mới 45 → suy ra phần trăm tiến độ.

▸ Lưu ý khi báo cáo

Không có khuôn cứng cho mọi dự án. Báo cáo cần vừa mang tính tổng quan, vừa đủ chi tiết để thấy được năng suất. Người quản lý dự án yêu cầu báo cáo cái gì thì bạn tập trung vào cái đó.

Chương 5 · Bài 8

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Những con số khô khan kiểu "hôm nay 50, hôm sau 60" rất khó để người đọc hình dung tình hình. Bài học chỉ ra vì sao nên biến số liệu thống kê thành chart trong báo cáo, và giới thiệu ba loại chart hay dùng: Burndown chart, column chart và pie chart. Điểm mấu chốt: chart giúp người xem dễ hình dung xu hướng của dự án hơn hẳn bảng số.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu vì sao báo cáo nên trực quan hóa số liệu bằng chart.
• Vẽ được column chart và pie chart từ bug list trên Google Sheets.
• Nắm ý nghĩa của Burndown chart và biết nơi tham khảo cách vẽ chi tiết.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao phải làm chart cho báo cáo?

Số liệu rời rạc khiến người đọc khó nắm nội dung. Khi đưa vào chart, chỉ cần nhìn là thấy ngay xu hướng — ví dụ số bug mỗi ngày đang giảm dần. Bạn copy chart đó bỏ thẳng vào báo cáo, người xem hình dung dễ hơn rất nhiều.

▸ 2. Vẽ column chart và pie chart từ bug list

Mở file bug list, quét vùng dữ liệu gồm cột ngày và cột số lượng bug phía dưới, rồi chọn Insert → Chart và đổi sang kiểu column. Chart sẽ thể hiện ngày 28 bao nhiêu bug, ngày 29 bao nhiêu bug... Bật Data Label để hiện con số cụ thể trên từng cột. Pie chart dùng để thể hiện tỷ lệ phần trăm của từng thành phần. Bạn tùy chỉnh cách trình bày theo ý mình.

▸ 3. Ý nghĩa từng loại chart

• Burndown chart: có một tổng số lượng (task) ban đầu rồi "burn down" — giảm dần theo thời gian. Nhìn chart biết được lượng còn phải làm, đang tiến độ hợp lý hay bị trễ.
• Column chart / pie chart: thể hiện số lượng, mức tăng giảm, bao nhiêu phần trăm; thường chỉ diễn tả một, hai yếu tố.

▸ Lưu ý khi chọn chart

Phần Burndown chart khá dài nên video này không demo, thay vào đó tác giả để link video công khai — bạn tìm trên YouTube với từ khóa "Burndown chart Smart IT Soft" để xem cách vẽ chi tiết. Theo kinh nghiệm của tác giả, chỉ cần bấy nhiêu chart là đủ; thêm nhiều loại chart khác sẽ phức tạp hơn mà không cần thiết.

Chương 6 · Bài 1

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Mở đầu chương cuối về phân tích chất lượng, bài học giới thiệu chỉ số norm — bộ mật độ chuẩn giữa số dòng code (LOC), số test case và số bug — để đo xem một dự án có đạt chất lượng hay không. Điểm mấu chốt: đối chiếu test case và bug thực tế với norm giúp bạn đọc ra chất lượng sản phẩm qua con số, nhưng norm chỉ mang tính tham khảo và cần điều chỉnh cho phù hợp từng dự án.

─── SAU BÀI HỌC, BẠN SẼ

• Hiểu chỉ số norm là gì và cách tính test case, bug tối thiểu / trung bình từ LOC.
• Đọc được chất lượng dự án qua tương quan giữa số test case và số bug.
• Ý thức được giới hạn của norm và biết khi nào cần điều chỉnh hoặc dựa vào kinh nghiệm.

─── NỘI DUNG CHÍNH

▸ 1. Chỉ số norm và control limit

Norm là mật độ chuẩn do lịch sử mỗi công ty tạo ra. Ví dụ: 1000 LOC có khoảng 90 test case; nếu source code là 2000 LOC thì test case dự kiến khoảng 180. Viết ít hơn là thiếu, nhiều hơn là thừa. Mỗi norm đi kèm control limit gồm cận trên và cận dưới: nằm trong khoảng đó là ổn, vượt cận trên coi như có vấn đề. Tương tự với bug — ví dụ 1000 LOC có 8 bug (cận trên 12, cận dưới 4): source 5000 LOC thì tối thiểu 20 bug, trung bình khoảng 40 bug.

▸ 2. Đọc chất lượng qua tương quan test case và bug

• Test case ít mà bug nhiều → sản phẩm kém chất lượng.
• Test case nhiều mà bug ít → test case không chất lượng.
• Test case nhiều và bug cũng nhiều → test case thừa và sản phẩm vẫn kém chất lượng.
• Cả test case và bug đều nằm trong norm trung bình → sản phẩm đạt chất lượng.

▸ 3. Norm cho từng loại bug (UT và IT)

Phân biệt bug unit test và bug integration test khi log lên hệ thống (điền vào trường QC activity) để thống kê. Ví dụ mật độ tham khảo: unit test 8 bug/KLOC (cận dưới 4), integration test có mật độ riêng. Tiêu chí đánh giá đạt / không đạt dựa trên số liệu so với norm.

▸ Lưu ý khi dùng norm

Norm có thể không chuẩn, thậm chí bị "bùa số" — điền đủ test case nhưng test qua loa thì bug không ra. Những sai số này thuộc về con người, phải giải quyết bằng training chứ không thể ép bằng con số. Nhiều dự án cũng không biết chính xác bao nhiêu LOC, khi đó phải dựa vào kinh nghiệm và độ hài lòng của khách hàng. Hãy xem norm là công cụ tham khảo để có cơ hội cải thiện.

Chương 6 · Bài 2

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài học chỉ cách phân tích danh sách bug từ một file báo cáo thống kê Google Sheets, dựa vào các trường phân loại như QC activity, loại bug (defect type) và nguyên nhân gây ra bug. Từ dữ liệu đó, bạn dùng công thức đếm và vẽ chart để nhìn ra xu hướng chất lượng của dự án. Điểm mấu chốt: có phân tích trước thì mới nhận xét được, và nhận xét dựa trên xu hướng chứ không chỉ con số đơn lẻ.

─── SAU BÀI HỌC, BẠN SẼ

• Biết các trường cần điền khi log bug để phục vụ phân tích (QC activity, defect type, category, nguyên nhân).
• Dùng hàm countif để tổng hợp bug theo từng tiêu chí rồi vẽ chart.
• Đọc ra xu hướng và nhận xét sơ bộ chất lượng dự án từ chart.

─── NỘI DUNG CHÍNH

▸ 1. Dữ liệu đầu vào từ việc log bug

Khi tester hoặc developer xác định một bug, họ điền các trường: QC activity (unit test / integration test / acceptance test), điểm kết thúc, loại bug, nguyên nhân gây ra bug. Chính những trường phân loại này giúp bạn thống kê và phân tích về sau. Không điền đủ trường thì không thống kê được.

▸ 2. Tổng hợp bằng countif và vẽ chart

Cách lập công thức rất đơn giản — chủ yếu dùng countif (đã hướng dẫn ở các clip trước). Ví dụ count QC activity theo unit test và integration test, count defect type, count category; sau đó sum hoặc count lại rồi quét vùng kết quả để vẽ chart. Mỗi tiêu chí cho ra một chart phân tích riêng.

▸ 3. Nhận xét theo xu hướng

Sau khi có chart, đưa ra nhận xét. Ví dụ QC activity: 87% bug ở unit test, 9% ở integration test, 3% ở acceptance test — bug càng về sau càng giảm là hợp lý, vì unit test bắt được nhiều bug thì các giai đoạn sau bug giảm. Ngược lại, nếu unit test bắt ít mà integration test bắt nhiều thì giai đoạn UT đang có vấn đề.

▸ 4. Phân tích theo loại và nguyên nhân bug

Chọn all để xem tất cả loại, hoặc lọc riêng unit test để chart đổi theo. Nhìn vào loại bug thấy dự án bị nhiều lỗi layout, rồi tới logic code, có cả hard code. Nhìn nguyên nhân thấy bất cẩn chiếm cao nhất (khoảng 37%), rồi tới misunderstand... Từ các chart này bạn nắm được xu hướng cái gì nhiều, cái gì ít. Việc đưa ra hành động cải thiện sẽ được nói ở video sau.

Chương 6 · Bài 3

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Nối tiếp bài phân tích bug, bài học này chỉ cách đi từ số liệu đến hành động cải thiện chất lượng cho dự án. Bạn nhìn vào chart phân loại bug, phán đoán vấn đề nằm ở đâu (layout, logic code, dev nào yếu...), rồi đề xuất hành động cụ thể như tăng cường training và review. Điểm mấu chốt: phân tích tốt nhất là làm ngay khi vấn đề đang xảy ra; làm sau khi xong thì thuộc về buổi retrospective để rút kinh nghiệm cho giai đoạn sau.

─── SAU BÀI HỌC, BẠN SẼ

• Đọc tỷ lệ bug theo QC activity để đánh giá giai đoạn nào đang bắt bug tốt.
• Truy ra loại lỗi và mức độ nghiêm trọng (Severity) chiếm nhiều để khoanh vùng vấn đề.
• Đề xuất hành động cải thiện phù hợp với nguyên nhân tìm được.

─── NỘI DUNG CHÍNH

▸ 1. Đọc tỷ lệ bug theo giai đoạn

Giả định dự án đang ở acceptance test và bị kêu "bug nhiều quá". Mở file phân tích, nhìn tỷ lệ: unit test 87%, integration test 10%, acceptance test 3% — tức unit test bắt nhiều nhất, acceptance test bắt ít nhất. Đây thực ra là tỷ lệ ok, vì bug được bắt sớm ngay từ unit test.

▸ 2. Truy loại lỗi và nguyên nhân

Thống kê theo phân loại cho từng giai đoạn: unit test bắt nhiều nhất là layout, rồi logic code; integration test cũng tương tự. Khi lỗi tập trung nhiều ở layout và logic code, có thể suy ra dev chưa rành phần layout dẫn đến lỗi nhiều. Có thể dùng VLOOKUP đối chiếu sang bảng thước có sẵn để ra kết luận nhanh.

▸ 3. Phân tích theo Severity và theo màn hình

Lọc theo Severity để xem mức độ: ví dụ unit test có 7 critical, 83 major, 23 minor. Critical càng ít thì sản phẩm càng ổn; critical layout mà nhiều (khoảng 8 con) và major layout rất nhiều thì team làm chưa tốt. Xem tiếp phân loại theo màn hình để biết dev nào đang có vấn đề, từ đó làm meeting hướng dẫn dev đó xử lý tốt hơn.

▸ Lưu ý khi đề xuất hành động

Quy trình là: nhìn chart → phán đoán → ra hành động cải thiện, rồi ở lần phân tích tiếp theo kiểm tra xem hành động đó có hiệu quả không. Số norm vẫn hữu ích nhưng thường khó đo vì không phải lúc nào cũng biết chính xác bao nhiêu LOC, bao nhiêu test case; khi đó hãy dựa vào tương quan giữa các số liệu đưa về để phân tích và ra quyết định cải thiện.

Chương 6 · Bài 4

─── BÀI HỌC NÀY NÓI VỀ ĐIỀU GÌ?

Bài cuối khóa giới thiệu một công cụ tự động do tác giả tự code và tích hợp vào hệ thống Redmine của mình, giúp lấy dữ liệu dự án và phân tích chất lượng một cách tự động. Thay vì làm thủ công từng bước như các bài trước, bạn chỉ cần nhập thông số, gọi API là công cụ tự đổ dữ liệu và xuất ra đánh giá. Điểm mấu chốt: đây là bản demo minh họa hướng tự động hóa việc phân tích chất lượng cho nhiều dự án cùng lúc.

─── SAU BÀI HỌC, BẠN SẼ

• Hình dung cách một công cụ tự động kéo dữ liệu Redmine về file phân tích.
• Biết các bước cấu hình cơ bản: nhập username, API key và gọi API lấy issue.
• Hiểu công cụ tổng hợp gì: bug, task, tiến độ, Burndown và các chart.

─── NỘI DUNG CHÍNH

▸ 1. Truy cập công cụ và cấu hình

Bạn cần xin tài khoản Redmine của tác giả để vào link công cụ. Sau khi mở trang, vào phần Tool → check correct project và nhập đầy đủ thông số. Lấy API key bằng cách vào My Account → Show API key trên Redmine rồi copy sang.

▸ 2. Gọi API và tự động phân tích

Chọn dự án cần check correct / phân tích, gọi Get full issue rồi Submit. Công cụ sẽ lấy toàn bộ issue của dự án, đổ vào một file Google Sheets template đã có sẵn công thức. Từ đó nó tự phân tích và xuất ra đánh giá cho dự án — chỉ với một cú nhấn.

▸ 3. Những gì công cụ tổng hợp

Công cụ phân tích tự động về bug, task, tiến độ, Burndown chart, column chart, pie chart, summary theo từng người, từng file và từng màn hình. Nhờ vậy bạn nhanh chóng biết màn hình nào đang bị trễ, ai đang có vấn đề. Với công ty chạy nhiều chục project, chỉ cần một người chạy tool là xong.

▸ Lưu ý khi xem kết quả

Dữ liệu demo trong bài đã cũ (từ năm 2021) nên mọi thứ đều báo trễ và một số chart thiếu dữ liệu để hiển thị. Mốc phân tích để mặc định là today (ngày hiện tại); bạn có thể chỉnh mốc ngày lùi lại (ví dụ trừ 180 ngày) hoặc sửa ngày trong file template để xem kết quả cho đúng. Khi đổ dữ liệu mới vào, Burndown và các chart sẽ phản ánh hợp lý hơn.