Học làm Tester (QC) khi bạn đang làm Comtor (Phiên dịch)

Chương 2 · Bài 1

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

Bài học chỉ ra những lợi thế sẵn có của một IT-Comtor (phiên dịch trong dự án phần mềm) khi chuyển sang vị trí QC / Tester. Điểm mấu chốt: bạn đã nắm sẵn ba thứ mà một QC rất cần — ngoại ngữ, sự quen thuộc với tài liệu, và tính cẩn thận — nên chỉ cần một mentor và một lộ trình rõ ràng là chuyển đổi được rất nhanh.

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

• Nhận ra các điểm mạnh sẵn có của IT-Comtor khi làm QC/Tester.
• Hiểu vì sao những điểm mạnh đó đúng là thứ vị trí QC/QA cần.
• Có thêm động lực và niềm tin để chuyển đổi nghề nghiệp.

─── NỘI DUNG CHÍNH

▸ 1. Ba điểm mạnh sẵn có của IT-Comtor

• Ngoại ngữ: làm trong thị trường Nhật, bạn đã có sẵn tiếng Nhật — một rào cản lớn với người khác nhưng là thế mạnh của bạn.
• Quen với tài liệu: ở vị trí Comtor, bạn đã dịch rất nhiều tài liệu, Q&A, câu hỏi, report bug… nên đã quen đọc và hiểu ngôn ngữ của khách hàng và của người viết.
• Tính cẩn thận: học ngoại ngữ và làm việc với khách Nhật rèn cho bạn sự tỉ mỉ — đúng phẩm chất mà một QC/QA rất cần.

▸ 2. Vì sao chuyển sang QC/Tester rất thuận lợi

Những điểm mạnh trên chính là thứ vị trí QC cần. Vì vậy khi chuyển vai trò, bạn chỉ cần thêm một mentor / người hướng dẫn và một lộ trình rõ ràng là có thể làm được rất nhanh.

▸ 3. Case study thực tế

Giảng viên chia sẻ một trường hợp: một bạn từ vị trí IT-Comtor, chỉ trong vòng một năm đã chuyển lên làm PM (quản lý dự án) và làm rất tốt. Đây là người giảng viên đào tạo trực tiếp — minh chứng rằng nếu tận dụng đúng điểm mạnh và học có lộ trình, bạn hoàn toàn có thể chuyển đổi nhanh và phát triển xa hơn.

Chương 2 · Bài 2

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

Bài học phác họa một sơ đồ tổ chức cơ bản của một dự án trong ngành gia công phần mềm (outsourcing), giúp bạn hình dung các vị trí và mối quan hệ giữa chúng. Điểm mấu chốt: hiểu được ai làm gì trong dự án sẽ giúp bạn — người xuất phát từ Comtor — thấy rõ vị trí QC / Tester nằm ở đâu và phối hợp với những vai trò nào.

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

• Hình dung được sơ đồ tổ chức cơ bản của một dự án outsourcing.
• Phân biệt vai trò của các vị trí chính trong dự án.
• Xác định được vị trí QC/Tester trong bức tranh tổng thể.

─── NỘI DUNG CHÍNH

▸ 1. Các vị trí quản lý và điều phối

Ở cấp cao nhất là người quản lý tổng thể, thường chỉ theo dõi bức tranh chung và chỉ join trực tiếp khi cần (ví dụ có comment, yêu cầu từ khách hàng). Chịu trách nhiệm chính cho dự án là PM (Project Manager) — người quản lý dự án. Với dự án lớn có thể có thêm Sub PM hỗ trợ PM.

▸ 2. Các vị trí chuyên môn

Trong dự án còn có các vai trò chuyên môn phối hợp cùng nhau:

• Comtor: phiên dịch trực tiếp với khách hàng, dịch tài liệu và các yêu cầu từ khách hàng.
• Technical Leader: chịu trách nhiệm về mặt kỹ thuật, thống nhất framework và các vấn đề kỹ thuật.
• QA: dựa theo quy trình của công ty để kiểm tra xem dự án có làm đúng quy trình hay không.
• QC: thực hiện test — kiểm thử chất lượng sản phẩm của dự án.

▸ 3. Cách tổ chức team QC

Một dự án thường chia thành nhiều team, và mỗi team thường có một QC phụ trách. Khi dự án lớn, có thể chia dọc hoặc chia ngang; lúc đó vị trí QC có thể tách thành một team QC riêng, có QC Lead riêng để điều phối. Đây là sơ đồ rất cơ bản, nhưng đủ để bạn nắm được cấu trúc các vị trí trong ngành gia công phần mềm.

Chương 2 · Bài 3

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

Bài học cho bạn thấy nhu cầu tuyển dụng thực tế của thị trường đối với vị trí QC / Tester biết ngoại ngữ. Điểm mấu chốt: qua các trang tuyển dụng phổ biến, số lượng tin tuyển Tester rất lớn, và hầu hết đều mong muốn ứng viên biết ngoại ngữ — đúng lợi thế mà một người xuất phát từ Comtor đang sẵn có.

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

• Biết cách tự khảo sát nhu cầu tuyển dụng QC/Tester trên thị trường.
• Nhận ra ngoại ngữ là một lợi thế cạnh tranh lớn ở vị trí này.
• Có thêm tự tin rằng cơ hội việc làm sau khi chuyển đổi là khả thi.

─── NỘI DUNG CHÍNH

▸ 1. Khảo sát nhu cầu qua các kênh tuyển dụng

Giảng viên cung cấp hai đường link để bạn tự tham khảo: một từ TopCV và một từ LinkedIn. Khi mở ra, bạn sẽ thấy số lượng tin tuyển dụng cho vị trí Tester rất nhiều — riêng trên TopCV đã có khoảng 70 việc làm, và trên LinkedIn cũng rất nhiều. Đây là cách trực quan để bạn tự đánh giá độ "khát" nhân lực của thị trường thay vì chỉ nghe nói.

▸ 2. Ngoại ngữ là lợi thế then chốt

Điểm đáng chú ý: hầu hết nhà tuyển dụng Tester đều mong muốn ứng viên biết ngoại ngữ. Với người xuất phát từ Comtor, đây chính là thế mạnh sẵn có — biến bạn thành ứng viên phù hợp mà nhiều người khác không có. Vì vậy, biết ngoại ngữ là một điều rất quan trọng giúp mở rộng cơ hội.

▸ 3. Lộ trình tìm việc hợp lý

Kết luận: nếu học về vị trí QC, việc tìm việc khá dễ, không đến mức quá khó. Lời khuyên là bước đầu có thể chọn những vị trí nhẹ nhàng hơn để làm quen, tích lũy thời gian và kinh nghiệm; khi đã cứng cáp hơn, câu chuyện phát triển nghề nghiệp sẽ khác đi theo hướng tích cực.

Chương 2 · Bài 4

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

Bài học vẽ ra một roadmap (lộ trình) nghề nghiệp cho người xuất phát từ IT-Comtor khi chuyển vào ngành gia công phần mềm. Điểm mấu chốt: từ vị trí Comtor, bạn hoàn toàn có thể đi theo hướng Tester / QC và tiến xa hơn tới các cấp Senior, Team Lead, Expert và quản lý dự án — với thời gian rút ngắn đáng kể nếu có mentor hướng dẫn.

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

• Hình dung được lộ trình phát triển từ Comtor lên các vị trí cao hơn.
• Ước lượng được thời gian cần thiết cho từng bước chuyển đổi.
• Có định hướng rõ ràng hơn cho con đường nghề nghiệp của mình.

─── NỘI DUNG CHÍNH

▸ 1. Bước khởi đầu: từ Comtor sang Tester

Từ vị trí Comtor, có hai hướng rất gần là BA và Tester; khóa học tập trung hướng bạn tới Tester / QC. Nếu học từ từ, sau khoảng 3 tháng bạn có thể đi tìm việc; nếu học nhanh và tập trung, chỉ khoảng 1 tháng rưỡi đến 2 tháng là đủ để bắt đầu ứng tuyển.

▸ 2. Lộ trình đi lên từ Tester

Sau khi làm Tester, bạn có thể phát triển theo hai nhánh:

• Đi sâu chuyên môn để lên Senior (cấp cao, rất giỏi trong lĩnh vực) — khoảng 1 năm.
• Đi theo hướng quản lý để làm Team Lead — cũng khoảng 1 năm.

Xa hơn, lộ trình lên Expert (chuyên gia) rồi tới cấp quản lý dự án thường mất khoảng 3 năm.

▸ 3. Rút ngắn lộ trình nhờ mentor

Giảng viên nhắc lại một case study đã chia sẻ: một bạn từ vị trí Comtor chỉ trong 1 năm đã lên tới cấp quản lý dự án. Bài học rút ra: nếu bạn học nhanh hơn, tập trung hơn và có người mentor đồng hành, bạn hoàn toàn có thể chạm tới vị trí quản lý chỉ trong khoảng một năm. Đây là định hướng dựa trên kinh nghiệm thực tế để bạn hình dung tương lai của mình.

Chương 2 · Bài 5

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

Bài học giúp bạn phân biệt rõ hai vị trí QA và QC — hai vai trò dễ nhầm lẫn nhưng có công việc hằng ngày rất khác nhau. Điểm mấu chốt: cả hai cùng hướng tới một mục tiêu improve quality (cải thiện chất lượng), nhưng QC tập trung vào sản phẩm của dự án, còn QA tập trung vào quy trình (process) và làm việc độc lập với dự án.

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

• Phân biệt được bản chất công việc của QA và QC.
• Hiểu điểm giống nhau và khác nhau giữa hai vị trí.
• Biết mỗi vị trí trực thuộc và làm việc trong phạm vi nào.

─── NỘI DUNG CHÍNH

▸ 1. QC làm gì?

QC focus vào dự án: test các phần của dự án, kiểm tra chất lượng sản phẩm, control quality của dự án. QC là người hiểu rất rõ mọi thứ liên quan tới dự án, kiểm tra trực tiếp và control lỗi của dự án đó. Nói cách khác, QC cải thiện chất lượng theo hướng của dự án, bám sát đúng dự án mình phụ trách.

▸ 2. QA làm gì?

QA chủ yếu quan tâm tới process (quy trình): xem quy trình hiện tại của dự án có đúng với quy trình của công ty và đúng với process plan đã đề ra hay không. QA thường là một bộ phận độc lập, trực thuộc quản lý của công ty (system), được điều phối vào để audit dự án theo một quy chuẩn nhất định — thay vì nhìn theo góc nhìn nội bộ của dự án.

▸ 3. Điểm giống và khác nhau

Cả QA và QC đều hướng tới cùng một mục tiêu: improve quality. Đó là điểm giống nhau. Khác nhau nằm ở phạm vi và cách tiếp cận:

• QC: kiểm tra trực tiếp vào dự án, control lỗi, hiểu sâu về dự án.
• QA: lo về quy trình của công ty, đứng độc lập với dự án để audit theo các góc nhìn (view) khác nhau.

Trên slide có một link tham khảo dẫn tới bảng so sánh chi tiết giữa hai vị trí để bạn hiểu rõ hơn.

Chương 2 · Bài 6

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

Bài học tổng hợp các kỹ năng tối thiểu và cần thiết để làm tốt vị trí QC / Tester. Điểm mấu chốt: một QC giỏi không chỉ biết bấm nút test — mà phải hiểu quy trình sản xuất phần mềm, nắm nhiều kỹ thuật testing, biết báo cáo — phân tích số liệu, và đặc biệt là cẩn thận, tỉ mỉ vì bạn là chốt chặn cuối trước khi sản phẩm đến khách hàng.

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

• Nắm được danh sách kỹ năng cốt lõi của một QC/Tester.
• Hiểu vì sao sự cẩn thận và tỉ mỉ quyết định chất lượng sản phẩm.
• Biết cách log bug, phân tích bug và định hướng cải thiện chất lượng.

─── NỘI DUNG CHÍNH

▸ 1. Nền tảng: quy trình và kỹ thuật testing

Trước hết bạn phải hiểu quy trình sản xuất phần mềm — giống như muốn kiểm tra một ngôi nhà thì phải biết nó được xây thế nào, để biết cần kiểm tra phần nào và ở đâu. Tiếp đó là các kỹ thuật testing: mỗi kỹ thuật bắt được một loại defect khác nhau, nên tùy tình huống phải chọn đúng kỹ thuật (A hay B) để xử lý hiệu quả.

▸ 2. Báo cáo, phân tích và nguyên tắc kiểm thử

Kỹ năng báo cáo và phân tích đòi hỏi bạn đọc được "câu chuyện" đằng sau số liệu — "số liệu biết nói" — để nhìn ra vấn đề. Bạn cũng cần nắm nguyên tắc kiểm thử, ví dụ nguyên tắc không có phần mềm nào hết bug: còn test, còn dùng thì còn bug; việc test hết mọi thứ để không còn lỗi là điều impossible, chỉ là chưa test tới thì bug chưa lộ ra.

▸ 3. Log bug và phân tích cải thiện chất lượng

Khi làm việc trong hệ thống với nhiều người, bạn phải biết log bug đúng chuẩn để ai nhìn vào cũng hiểu issue, đồng thời quản lý số lượng bug (open / fixed / close, còn lại bao nhiêu) — thực hành trên Redmine, và tương tự với các hệ thống khác. Cao hơn là phân tích bug để tìm điểm bất thường: bug thường rơi vào nguyên tắc 80-20 (khoảng 80% tập trung ở một số điểm), từ đó đưa ra phương án cải thiện chất lượng cụ thể hơn.

▸ Lưu ý quan trọng: cẩn thận và tỉ mỉ

Vì QC là chốt gần cuối trước khi sản phẩm qua khách hàng, thiếu cẩn thận sẽ dẫn tới bug leak. Ví dụ khi test một function login hoặc tạo user, nếu thấy điểm bất cập, bạn phải confirm đầy đủ các bên liên quan — đừng chỉ nghe một mình developer rồi vội cho qua. Tỉ mỉ còn nghĩa là kiểm tra kỹ số liệu: test trên version nào, tổng số test case OK / NG / cancel / pending, và lý do của từng trạng thái.

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 về quy trình phần mềm, giúp bạn phân biệt hai loại công ty cơ bản trong ngành: công ty gia công (outsourcing) và công ty sản phẩm (product). Điểm mấu chốt: hiểu rõ mình đang làm ở môi trường nào để biết cách hành xử, ra quyết định và tận dụng đúng thế mạnh của bản thân trong vai trò QC/Tester.

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

• Phân biệt được công ty gia công và công ty sản phẩm qua mục tiêu, bản quyền và cách vận hành.
• Hiểu vì sao ở công ty gia công, QC không tự quyết mà phải hỏi và lấy confirm từ khách hàng.
• Biết điều chỉnh kỹ năng và cách làm việc cho phù hợp với từng môi trường khi đi xin việc.

─── NỘI DUNG CHÍNH

▸ 1. Công ty gia công (outsourcing)

Công ty gia công cung cấp dịch vụ, thực hiện công việc theo yêu cầu khách hàng. Đặc điểm: không sở hữu sản phẩm, công nghệ hay bản quyền riêng; chỉ tập trung vào nhân lực — quản lý dự án, quản lý cho khách hàng, tư vấn và cung cấp dịch vụ.

▸ 2. Công ty sản phẩm (product)

Công ty sản phẩm phát triển và sở hữu sản phẩm, công nghệ riêng của mình. Họ tập trung nghiên cứu, phát triển sản phẩm rồi cung cấp ra thị trường, đồng thời nắm bản quyền về công nghệ và thương hiệu.

▸ 3. QC làm việc khác nhau ở hai môi trường

Với vai trò QC — kiểm tra sản phẩm có đạt chất lượng hay không — cách xử lý khác nhau rõ rệt:

• Ở công ty gia công: khi thấy điểm bất cập trong logic, bạn không tự sửa mà phải log Q&A, hỏi khách hàng. Việc tự quyết rất ít; những gì thấy hợp lý/không hợp lý đều báo khách hàng nhưng phải lấy confirm trước khi làm.
• Ở công ty sản phẩm: bạn có thể đề xuất, chỉnh sửa hoặc gom lại để ra một flow tốt hơn, thay đổi được ít nhiều.

Vì mục đích hai môi trường khác nhau, khi ứng tuyển bạn cần hiểu rằng skill và cách hành xử của mình trong mỗi công ty cũng phải khác nhau cho phù hợp.

Chương 3 · Bài 2

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

Bài học chỉ ra những đặc điểm nổi bật của ngành gia công phần mềm ở Việt Nam, để bạn hiểu cách ngành này vận hành, suy nghĩ và hành xử. Điểm mấu chốt: khi nắm được các đặc điểm này, bạn hiểu vấn đề của ngành và biết cách điều chỉnh bản thân cho phù hợp với vai trò của mình.

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

• Hiểu vì sao Việt Nam có lợi thế lớn về gia công phần mềm nhờ nguồn nhân lực trẻ, dồi dào.
• Nhận ra áp lực cạnh tranh chi phí và yêu cầu về trình độ, khả năng học nhiều lĩnh vực.
• Biết ba yếu tố cốt lõi cần quản lý trong dự án: tiến độ, chất lượng, chi phí.

─── NỘI DUNG CHÍNH

▸ 1. Linh hoạt về nguồn nhân lực và cạnh tranh chi phí

Việt Nam làm gia công phần mềm nhiều nhờ nguồn nhân lực trẻ, dồi dào trong ngành công nghệ thông tin. Khi khách hàng cần 3–5 người, công ty Việt Nam tìm được nhanh hơn nhiều so với thị trường Nhật. Đi kèm là cạnh tranh chi phí rất gắt: cùng một báo giá, luôn có công ty khác báo thấp hơn. Điều này tiết kiệm cho khách hàng nhưng đòi hỏi người làm phải giỏi — nếu không giỏi rất dễ bị sa thải.

▸ 2. Học nhiều lĩnh vực và được đào tạo bài bản

Vì đi gia công chứ không tự sáng tạo sản phẩm, yêu cầu khách hàng trải rộng nhiều lĩnh vực — lúc làm y tế, lúc làm ngân hàng. Người làm phải học từng lĩnh vực trong quá trình làm việc. Nhân viên cũng được đào tạo về bảo mật và các kỹ thuật cơ bản, rồi học thêm phần liên quan tới dự án.

▸ 3. Quản lý tiến độ, chất lượng, chi phí

Ngoài hướng đến sản phẩm, gia công còn phải cân nhắc chi phí. Ví dụ một tính năng tốt cho dự án nhưng chi phí rất cao, trong khi sản phẩm chưa vận hành, thì thường người ta chọn phương án làm vừa đủ để delivery thay vì phương án tốt nhất. Việc quản lý xoay quanh ba yếu tố: tiến độ, chất lượng, chi phí. Kinh nghiệm quản lý dự án và đội nhóm rất quan trọng vì nhu cầu thị trường thay đổi liên tục, đòi hỏi PM phải giỏi và linh động.

Chương 3 · Bài 3

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

Bài học định nghĩa dự án là gì và giới thiệu các yếu tố cốt lõi cần quản lý trong một dự án phần mềm. Điểm mấu chốt: một dự án luôn là nỗ lực tạm thời để tạo ra sản phẩm/dịch vụ duy nhất, có thời gian bắt đầu và kết thúc rõ ràng, nằm trong một phạm vi xác định.

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

• Nắm được định nghĩa dự án theo nghĩa chuẩn: nỗ lực tạm thời, kết quả duy nhất.
• Nhận diện bốn yếu tố cần quản lý: cost, quality, time và scope.
• Biết áp dụng tư duy này để đánh giá một việc có thực sự là "dự án" hay không.

─── NỘI DUNG CHÍNH

▸ 1. Bốn yếu tố cần quản lý

Giảng viên dùng hình tam giác gồm bốn yếu tố:

• Cost — chi phí dự án: máy móc, phần mềm phục vụ dự án, và nhiều nhất trong gia công là chi phí lương.
• Quality — chất lượng cần được quản lý khi dự án hình thành.
• Time — thời gian thực hiện dự án.
• Scope — phạm vi dự án nằm trong giới hạn nào.

▸ 2. Định nghĩa dự án

Dự án là việc tạo ra một sản phẩm duy nhất, có thời gian để tạo ra và nằm trong một phạm vi nhất định. Đây là một nỗ lực tạm thời — mỗi dự án đều phải có thời gian nhất định và kết thúc để đạt mục tiêu. Nếu bạn nhận làm một việc mà chính mình cũng không có các định nghĩa này, không hiểu rõ về nó, thì đó không phải là dự án.

▸ 3. Ví dụ dễ hiểu: mở quán cà phê

Khi mở một quán cà phê, bạn phải định nghĩa rõ: chi phí bỏ ra bao nhiêu, thời gian thực hiện bao lâu (mấy tháng), chất lượng cà phê loại nào, và phạm vi / đối tượng khách trong khu vực nào. Tất cả những điều đó đều phải được định nghĩa rõ ràng thì mới triển khai được — tương tự như một dự án phần mềm. Giảng viên cũng dẫn tới bài blog trên website để bạn đọc thêm định nghĩa chi tiết.

Chương 3 · Bài 4

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

Bài học trình bày vòng đời của một dự án qua năm nhóm quy trình chuẩn: khởi tạo, lập kế hoạch, thực thi, theo dõi & kiểm soát, và đóng dự án. Điểm mấu chốt: Executing và Monitoring & Controlling tạo thành một vòng lặp chạy liên tục cho đến khi dự án hoàn thành và được đóng lại.

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

• Kể được năm nhóm quy trình trong vòng đời dự án theo đúng thứ tự.
• Hiểu ý nghĩa của vòng lặp giữa thực thi và kiểm soát để cứu kế hoạch khi lệch tiến độ.
• Biết vì sao khâu đóng dự án (closing) quan trọng cho tổ chức.

─── NỘI DUNG CHÍNH

▸ 1. Năm nhóm quy trình

• Initiating process — khởi tạo dự án hoặc một phase.
• Planning process — lên kế hoạch.
• Executing process — thực thi kế hoạch.
• Monitoring and Controlling process — theo dõi và kiểm soát, đưa action khi dự án chạy sai kế hoạch.
• Closing process — đóng dự án.

▸ 2. Vòng lặp thực thi – kiểm soát

Khi bắt đầu Executing, bên ngoài luôn có Monitoring and Controlling: mỗi ngày, mỗi tuần đi kiểm tra dự án có đúng tiến độ không. Nếu lệch, phải Controlling — đưa ra các action để cứu lại plan, đưa dự án về đúng kế hoạch. Vòng lặp này chạy liên tục cho tới khi kết thúc.

▸ 3. Ví dụ: dự án làm website

Khởi tạo gồm ký hợp đồng, lấy requirement khách hàng, ký với partner design, form team, cấp quyền cho PM, kick-off công bố dự án. Sau đó Planning cho các phase design, coding, testing. Review xong thì Executing — chạy dự án và kiểm tra tiến độ hằng ngày/hằng tuần, Controlling khi cần.

▸ 4. Ý nghĩa của khâu đóng dự án (Closing)

Khi đóng dự án, thường back up toàn bộ dữ liệu và bàn giao về công ty (ví dụ dự án mất bao lâu, làm như thế nào) để có history data. Dữ liệu này giúp tổ chức tham khảo, cải tiến (improve) và phán đoán các dự án tương tự về sau. Closing còn là chốt chặn thông báo cho tất cả các bên liên quan biết dự án đã kết thúc, đồng thời nhìn nhận và đánh giá lại dự án.

Chương 3 · Bài 5

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

Bài học giới thiệu các mô hình phát triển phần mềm hay dùng nhất trong gia công: Waterfall, V-Model và Scrum (Agile). Điểm mấu chốt: mỗi mô hình có ưu/nhược riêng, và trong thực tế bạn thường phải kết hợp nhiều mô hình (hybrid) để quản lý dự án cho suôn sẻ.

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

• Hiểu nguyên lý của mô hình Waterfall và V-Model.
• Nắm cách vận hành cơ bản của Scrum: Sprint, các vai trò và các sự kiện chính.
• Biết vì sao và khi nào nên kết hợp Waterfall với Scrum trong dự án outsourcing.

─── NỘI DUNG CHÍNH

▸ 1. Waterfall và V-Model

Waterfall (thác nước): làm xong một phase mới sang phase tiếp theo — output của phase trước là input của phase sau, theo trình tự requirement → design → coding/development → testing → deployment → maintain. Khi có change request (CR), phải quay ngược lại phase trên để làm lại. V-Model có hình chữ V: mỗi giai đoạn testing tương ứng với một loại tài liệu ở giai đoạn thiết kế. Mô hình này vẫn được dùng khi khách hàng đã chốt scope rõ ràng và muốn đi theo Waterfall.

▸ 2. Scrum (Agile)

Agile ví như ngôn ngữ lập trình, còn Scrum như một framework dựng trên Agile. Scrum sinh ra để đáp ứng thay đổi liên tục (thời buổi VUCA), với tiêu chí welcome to change — chấp nhận thay đổi khi cần. Cơ chế:

• Time box: mỗi Sprint kéo dài 2–4 tuần.
• Product Owner liệt kê các item vào Product Backlog, họp với team và Scrum Master để chốt việc cần làm.
• Trong Sprint: Sprint Planning, họp team mỗi ngày, cuối Sprint tổng kết trình bày, rồi Retrospective để rút kinh nghiệm và cải tiến cho Sprint sau.
• Trong Sprint không thay đổi tùy tiện, quality không được giảm, backlog có thể refine, scope phải xác nhận liên tục với Product Owner.

Về vai trò: team member có quyền điều hành cao nhất, Scrum Master chỉ hỗ trợ/hướng dẫn (không quyết định), Product Owner quyết định về sản phẩm.

▸ 3. Kết hợp mô hình (Hybrid)

Trong thực tế, bạn có thể kết hợp: giai đoạn báo giá dùng Waterfall, khi thực thi từng giai đoạn nhỏ dùng Scrum — gọi là hybrid. Do nhân sự dự án thường không đồng đều về trình độ, người quản lý phải chọn mô hình phù hợp cho từng tình huống. Vì vậy Scrum Master ở đây thường chính là PM, mang vai trò coaching và leader nhiều hơn là quản lý thuần túy.

Chương 3 · Bài 6

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

Bài học tổng hợp một danh sách thuật ngữ cơ bản, thông dụng mà QC/Tester gặp hằng ngày trong gia công phần mềm, kèm truy cập qua link/QR. Điểm mấu chốt: đây là bộ từ vựng nền tảng để bạn đọc tài liệu, trao đổi với khách hàng và theo được các bài học sau; không cần thuộc hết ngay mà nắm ý nghĩa và tra lại khi cần.

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

• Hiểu nhóm thuật ngữ quản lý dự án: scope, time, cost, quality, PDCA, schedule.
• Nắm nhóm thuật ngữ tài liệu thiết kế và loại hợp đồng.
• Làm quen nhóm thuật ngữ kiểm thử và bug thường dùng trong công việc QC.

─── NỘI DUNG CHÍNH

▸ 1. Nhóm quản lý dự án

• Scope: phạm vi công việc (ví dụ design, coding, testing/unit test, gửi test case, test report cho khách hàng).
• Time / Cost / Quality: thời gian, chi phí (đo bằng man-month, man-day) và chất lượng của function/dự án.
• PDCA (Plan – Do – Check – Action): công cụ để nâng cao chất lượng và productivity — lên kế hoạch, thực thi, kiểm tra định kỳ, rồi có action recover khi lệch.
• Master schedule / Detail schedule: lịch trình tổng thể (overview) và lịch trình chi tiết từng ngày.

▸ 2. Nhóm tài liệu thiết kế và hợp đồng

Các mức tài liệu: High Level Design (overview), Function/Basic Design (thiết kế cơ bản các chức năng), Detail Design / Programming Design (chi tiết, liên kết database, cách validate — giúp developer code). Các loại hợp đồng: Fixed Price (làm trọn gói một cục tiền), ODC (Offshore Development Center — tính tiền theo tháng, theo output), Body Shopping (khách thuê nhân lực và tự quản lý trực tiếp).

▸ 3. Nhóm kiểm thử và bug

• Norm: con số tiêu chuẩn; nếu chỉ số vượt/dưới ngưỡng thì đang có vấn đề (ví như chỉ số xét nghiệm máu).
• Các loại test: UT (Unit Test), IT (Integration Test), UAT (User Acceptance Test — khách hàng thực hiện); test case, test report; LOC / KLOC (line of code, K = ngàn).
• Kỹ thuật: test coverage, blackbox / whitebox / graybox, load testing, sanity testing.
• Bug: phân theo giai đoạn (bug UT / IT / UAT); bug UAT còn gọi là leak (rò rỉ do test không hết). Khi xử lý bug cần tìm root cause, đưa ra corrective action, làm regression (kiểm tra hồi quy). Phân biệt severity (mức nghiêm trọng) và priority (mức ưu tiên) — hai từ dễ nhầm.

Đây là danh sách thường dùng nhất; trong quá trình học, gặp thuật ngữ nào cần bổ sung bạn có thể trao đổi để giảng viên cập nhật thêm.

Chương 3 · Bài 7 (phần 1)

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

Bài học (phần 1) giải thích hệ thống quản lý dự án là gì và điểm qua các công cụ phổ biến. Điểm mấu chốt: bất kỳ công cụ nào giúp bạn quản lý được time, cost, quality đều được xem là một hệ thống quản lý dự án — từ file Google Sheets, Excel cho đến một tấm bảng trắng.

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

• Hiểu định nghĩa hệ thống quản lý dự án theo ba yếu tố time, cost, quality.
• Biết các công cụ thương mại phổ biến và giới hạn của bản miễn phí.
• Nắm lý do khóa học chọn Redmine (open source) để thực hành.

─── NỘI DUNG CHÍNH

▸ 1. Hệ thống quản lý dự án là gì?

Một dự án gồm các yếu tố time, cost, quality. Một hệ thống quản lý dự án đầy đủ là hệ thống quản lý được tất cả các yếu tố trên. Bạn có thể quản lý bằng Excel, Google Sheets, thậm chí bằng một tấm bảng trắng — miễn công cụ đó giúp bạn theo dõi được time, cost, quality thì đều được xem là hệ thống quản lý dự án.

▸ 2. Các công cụ phổ biến và giới hạn bản miễn phí

Giảng viên liệt kê một số công cụ: Atlassian (Jira), Asana, Monday, Trello. Với các hệ thống cho dùng free, thường bạn không quản lý được đầy đủ cả time, cost, quality — nhà cung cấp giới hạn tính năng để bạn phải mua tài khoản thì mới mở khóa full tính năng.

▸ 3. Redmine — công cụ miễn phí mã nguồn mở

Giảng viên giới thiệu Redmine, một open source miễn phí nhưng phải tốn công dựng. Khóa học đã dựng sẵn một Redmine để bạn thực hành; bạn có thể click vào link để truy cập. Khi cần thực hành, bạn đăng ký một form để được cấp tài khoản. Giảng viên cũng có một khóa học riêng về Redmine, và ở cuối phần này sẽ click vào Redmine cùng form đăng ký để minh họa (nội dung chi tiết ở phần 2).

Chương 3 · Bài 7 (phần 2)

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

Phần 2 đi vào demo trực tiếp hệ thống Redmine của khóa học và hướng dẫn đăng ký tài khoản để thực hành. Điểm mấu chốt: bạn sẽ được cấp quyền project manager (PM) trên một dự án Redmine mẫu để tự tay quản lý issue, bug, Q&A và theo dõi tiến độ.

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

• Hình dung được giao diện Redmine và các thông tin nó quản lý.
• Biết cách đăng ký form để được cấp tài khoản thực hành.
• Hiểu mình sẽ được cấp quyền PM để thao tác trên dự án demo.

─── NỘI DUNG CHÍNH

▸ 1. Demo hệ thống Redmine

Trong dự án demo của khóa học, khi vào Redmine bạn thấy được issue của dự án gồm những gì, cùng các tab để quản lý. Redmine quản lý cả thời gian (Gantt), thống kê số lượng bug, CR, ticket, tracker. Vào phần setting để config, mở các module cần thiết như forum, document... Càng tùy chỉnh nhiều trên Redmine, bạn càng quản lý dự án chặt hơn.

▸ 2. Đăng ký tài khoản thực hành

Trong hệ thống có nhiều đường link, trong đó có form đăng ký. Bạn click vào form, đăng nhập (login), nhập thông tin rồi submit. Sau đó giảng viên nhận được thông báo và tạo tài khoản cho bạn.

▸ 3. Quyền thực hành trên dự án

Bạn sẽ thực hành trên tài khoản dự án Redmine với quyền project manager (PM), để tự thực hiện việc quản lý trên dự án đó. Nếu cần góp ý hoặc thêm gì, bạn có thể liên hệ giảng viên để được hướng dẫn thêm.

Chương 3 · Bài 8

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

Bài học cho bạn một cái nhìn tổng quan về những công cụ, hệ thống mà một QC/Tester phải thao tác hằng ngày, để biết cần tập trung học phần nào. Điểm mấu chốt: QC phải sử dụng thành thạo nhiều công cụ, và quan trọng là chúng cần tích hợp (integration) với nhau để thông tin được cập nhật kịp thời.

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

• Biết các nhóm công cụ chính mà QC/Tester phải thao tác.
• Xác định được thứ tự ưu tiên học: bảng biểu, hệ thống quản lý dự án, kênh trao đổi, nơi lưu trữ.
• Hiểu vì sao việc tích hợp giữa các hệ thống là mấu chốt trong quản lý dự án.

─── NỘI DUNG CHÍNH

▸ 1. Bảng biểu: Google Sheets / Excel

Đây là công cụ đầu tiên và dùng nhiều nhất. Bạn thao tác trên tài liệu rất nhiều: viết test case, thực thi test case, quản lý số liệu test case... đều nằm trên Google Sheets/Excel. Vì vậy phải học kỹ dạng bảng biểu này.

▸ 2. Hệ thống quản lý dự án và kênh trao đổi

• Hệ thống quản lý dự án (demo là Redmine): log bug, Q&A với khách hàng, cập nhật status bug — tất cả nằm ở đây.
• Kênh trao đổi thông tin: Gmail, WhatsApp, Zalo, Skype... để trao đổi với khách hàng.
• Nơi lưu trữ file: file server hoặc SVN — nói tới SVN thì bạn phải học SVN.

Giảng viên nhấn mạnh: biết một công cụ là một chuyện, làm được (thực hành, biết cách lưu trữ và quản lý) là chuyện khác — mọi thứ đều phải học chứ không tự nhiên nhìn vào là biết.

▸ 3. Mấu chốt: các hệ thống phải tích hợp với nhau

Điều quan trọng nhất là tất cả các công cụ này cần integration với nhau: khi một cái cập nhật thì cái khác biết. Ví dụ khi khách hàng update một ticket trên Redmine, phải có notification đến hệ thống chat để bạn biết ngay và xử lý kịp thời. Đó là key trong quá trình vận hành. Người QC cần hiểu và thao tác được hết tất cả những phần này thì mới làm được dự án. Giảng viên có các khóa học riêng về Google Sheets và Redmine để bạn tham khảo thêm.

Chương 3 · Bài 9

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

Bài học giới thiệu các môi trường phát triển thường dùng trong gia công phần mềm: dev, test, staging và production (honban). Điểm mấu chốt: môi trường test phải tách biệt với môi trường development, và bên gia công nên hạn chế tối đa việc đụng vào môi trường production vì chứa dữ liệu thật của khách hàng.

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

• Phân biệt được bốn loại môi trường và vai trò của từng môi trường.
• Hiểu luồng đưa sản phẩm từ dev → test → staging → production.
• Nắm nguyên tắc an toàn: tách biệt môi trường test và tránh thao tác trên production.

─── NỘI DUNG CHÍNH

▸ 1. Bốn môi trường thường gặp

Thường có bốn môi trường, tùy budget của khách hàng mà có khi chỉ dựng hai:

• Development (dev): dành cho developer xây dựng sản phẩm.
• Test: dành cho tester kiểm thử (unit test, integration test), dùng database riêng của môi trường test.
• Staging: môi trường gần giống production, nơi khách hàng test — gần với thực tế nhất.
• Production (honban): môi trường vận hành thật, chứa data thật của khách hàng.

▸ 2. Luồng đưa sản phẩm qua các môi trường

Developer làm xong ở môi trường dev thì deploy lên môi trường test; tester focus vào môi trường test để kiểm thử. Xong hết thì đưa lên staging — khách hàng test (mình có thể test phụ một phần). Khi ổn hết mới đưa lên production/honban.

▸ 3. Nguyên tắc an toàn khi thao tác

• Bên gia công chỉ nên làm ở môi trường development/test, không nên đụng vào production/honban. Nếu khách hàng đưa môi trường honban thì phải hỏi thật kỹ, vì trong đó có data thật, rất nguy hiểm.
• Môi trường test phải tách biệt với môi trường development. Gộp chung dev và test là sai: khi test bạn làm "đủ thứ trò", nếu chỉ một môi trường sẽ rất khó kiểm soát sản phẩm đang ở đâu — ví dụ log một bug lên thì khó biết bug thuộc version nào. Vì vậy môi trường test luôn phải có và phải tách riêng.

Chương 3 · Bài 10

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

Bài học giới thiệu ba khối cơ bản của hầu hết phần mềm: client, server, database, và cách chúng trao đổi dữ liệu với nhau. Điểm mấu chốt: client gửi request qua Internet đến server, server truy vấn database rồi trả response về client — hiểu được luồng này, bạn biết khi lỗi xảy ra thì nên nghi ngờ ở đâu.

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

• Phân biệt được vai trò của client, server và database trong một hệ thống.
• Hình dung được luồng request – xử lý – response giữa ba khối.
• Biết dùng khái niệm API để giải thích cách client truy cập dữ liệu bên trong server.

─── NỘI DUNG CHÍNH

▸ 1. Ba khối cơ bản

• Database: nơi lưu trữ dữ liệu, thường ở dạng bảng có cột và dòng — ví dụ MySQL, SQL Server, Firebase. Một file Google Sheet lưu thông tin cũng có thể xem như một dạng lưu trữ để dễ hình dung.
• Server (máy chủ): nơi chứa database và file storage, chịu trách nhiệm xử lý và trả kết quả.
• Client: thiết bị gửi yêu cầu — laptop, mobile, tablet, iPad — truy cập vào server qua Internet.

▸ 2. Luồng request – response

Client gửi request qua Internet đến server. Server gọi database để lấy dữ liệu, xử lý rồi trả response về client. Nếu kết quả trả về không đúng, thường là do phần xử lý ở server hoặc dữ liệu ở database/file lưu trữ có vấn đề — đây là hướng để lần theo khi truy lỗi.

▸ 3. API — lớp giao tiếp bên ngoài

Giảng viên ví hệ thống như một ngôi nhà: đồ đạc bên trong là database, còn phần vỏ bên ngoài để nhận thông tin chính là API. Người dùng chỉ nhìn thấy lớp vỏ; khi gọi đến API, nó "mở cửa" vào trong truy cập dữ liệu rồi trả kết quả ra, chứ người ngoài không thấy được bên trong.

▸ 4. Góc nhìn của Tester

Với người test, cần xác định sản phẩm phải cài và chạy được trên các thiết bị nào, rồi kiểm tra kết quả trả về có đúng không. Khi response sai, hiểu kiến trúc client – server – database giúp bạn khoanh vùng nguyên nhân thay vì đoán mò.

Chương 3 · Bài 11

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

Bài học liệt kê những khái niệm nền tảng mà một Tester cần nắm khi làm việc với website: frontend, server, backend, database. Điểm mấu chốt: nắm đúng thuật ngữ và cách gọi thống nhất giúp bạn làm việc nhóm trơn tru, tránh hiểu sai nhau khi trao đổi với Developer và khách hàng.

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

• Phân biệt được frontend, backend, server và database trong một website.
• Hiểu vai trò của API như "cầu nối" để frontend gọi vào phần xử lý bên trong.
• Biết website frontend chính là các browser như Chrome, Firefox, Safari, Edge, Opera.

─── NỘI DUNG CHÍNH

▸ 1. Bốn khái niệm cần nắm

• Frontend: phần bạn nhìn thấy — giao diện, layout, "lớp sơn" của ứng dụng.
• Backend: phần xử lý logic ẩn bên trong, nhận yêu cầu qua API rồi xử lý.
• Database: nơi chứa dữ liệu thô, cốt lõi của hệ thống.
• Server: khu vực bao trọn cả backend, API và database.

▸ 2. Ví dụ ngôi nhà

Nhìn từ ngoài vào, nước sơn và layout của ngôi nhà là frontend; đồ đạc bên trong là database; mỗi dụng cụ có chức năng riêng được gọi qua API. Toàn bộ nội bộ bên trong — backend, API và database — hợp thành server.

▸ 3. Ví dụ quán ăn

Bạn là client vào quán, nhìn menu (frontend) và gọi món — đây là một request. Người phục vụ nhập yêu cầu qua màn hình máy (giao diện giống API). Phía sau, nhà bếp chế biến, xào nấu chính là backend; nguyên liệu thô như thịt, xúc xích là các record trong database. Món ăn hoàn thành được đem ra phục vụ ở frontend. Cả khu vực từ máy tính đến bếp gộp lại là server.

▸ 4. Vì sao phải thống nhất thuật ngữ

Với người khác ngành, học các khái niệm này ban đầu khá khó. Nhưng nếu không thống nhất cách gọi và cách hiểu, làm việc nhóm sẽ rất dễ hiểu lầm nhau. Khi nghe nói "website frontend", bạn cần hình dung ngay đó là các browser phía giao diện. Làm nhiều rồi bạn sẽ quen, và nên tìm hiểu sâu thêm từng phần sau bài học này.

Chương 3 · Bài 12

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

Bài học nối tiếp phần website, chỉ ra rằng kiến trúc của ứng dụng mobile về cơ bản giống web, chỉ khác nhau ở phần client. Điểm mấu chốt: với mobile, client là app chạy trên hệ điều hành (chủ yếu Android và iOS), còn backend, server và database thì tương tự như web.

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

• Hiểu điểm khác biệt giữa mobile và web nằm chủ yếu ở phần client.
• Nhớ hai hệ điều hành chính cần lưu ý khi test mobile: Android và iOS.
• Biết ánh xạ các khái niệm frontend, backend, server, database từ web sang mobile.

─── NỘI DUNG CHÍNH

▸ 1. Điểm khác biệt: phần client

Với web, client là các trình duyệt. Với mobile, client là app bạn bật lên trên hệ điều hành của thiết bị. Hiện có hai nền tảng chính là Android và iOS (ngoài ra còn một số hệ điều hành khác nhưng không phổ biến bằng). Hai nền tảng này khác nhau, nên đó là phần cần chú ý khi kiểm thử.

▸ 2. Frontend, backend và database

• Frontend của mobile chính là app hiển thị trên hệ điều hành mà người dùng thao tác.
• Backend API và server thì giống hệt như bên web, gần như không khác gì.
• Database cũng có thể là web server, Firebase hoặc nhiều loại khác. Bài học chỉ nêu vài loại cơ bản hay gặp; thực tế có rất nhiều loại database tùy hệ thống.

▸ 3. Ghi nhớ theo ngữ cảnh test

Khi nghe "test về web", bạn phải nhớ ngay tới các trình duyệt. Khi nghe "test về mobile", bạn phải nhớ tới các hệ điều hành như Android, iOS — rồi xác định đâu là frontend, đâu là backend, đâu là database. Khóa học dừng ở mức khái niệm cơ bản để tạo nền tảng; muốn đi sâu từng loại database hay từng nền tảng thì cần tìm hiểu thêm theo chuyên ngành.

Chương 3 · Bài 13

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

Bài học tổng kết cả chương 3, hệ thống lại những khái niệm nền tảng bạn đã đi qua để làm cơ sở cho các chương chuyên sâu sau này. Điểm mấu chốt: mục tiêu của các chương đầu là hình thành khái niệm và cách hiểu chung, chứ chưa đi sâu — nắm chắc phần này rồi bạn mới học tiếp thuận lợi.

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

• Ôn lại toàn bộ khái niệm nền tảng của chương một cách có hệ thống.
• Phân biệt được các cặp khái niệm dễ nhầm như công ty gia công / công ty sản phẩm, QA / QC.
• Nhớ được các loại môi trường, mô hình phát triển và kiến trúc cơ bản của phần mềm.

─── NỘI DUNG CHÍNH

▸ 1. Loại hình công ty và vị trí QA / QC

• Công ty gia công (dịch vụ): khách yêu cầu gì làm nấy. Công ty sản phẩm: tự develop, feedback, maintain rồi đưa sản phẩm ra thị trường.
• QA đảm bảo quy trình của toàn công ty và dự án, đứng độc lập để đánh giá. QC kiểm tra trực tiếp sản phẩm, xem mức độ hoàn thiện tới đâu.

▸ 2. Dự án, quy trình và mô hình phát triển

• Dự án gồm time, cost, quality, tạo ra một sản phẩm/dịch vụ duy nhất trong một thời điểm nhất định.
• Quy trình dự án: initiating → planning → executing → monitoring & controlling → closing.
• Mô hình phát triển: waterfall, V-model và Scrum.

▸ 3. Công cụ quản lý và môi trường

• Hệ thống quản lý: Trello, Jira, và Redmine (công cụ miễn phí được dùng để thực hành — có form đăng ký để giảng viên tạo tài khoản).
• Các môi trường: dev, test, staging và honban (production) — mỗi môi trường có mục đích riêng.

▸ 4. Kiến trúc cơ bản

Nhắc lại kiến trúc phần mềm gồm client, server, database. Với website còn có API, frontend, backend; client là các browser như Firefox, Chrome. Mobile cũng theo mô hình tương tự. Đây là hành trang khái niệm để bước vào các chương chuyên sâu tiếp theo.

Chương 4 · Bài 1

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

Bài học mở đầu chương 4, giới thiệu tổng quan các loại tài liệu thiết kế thường gặp trong dự án gia công phần mềm (outsourcing) và vai trò của chúng với QC / Tester. Điểm mấu chốt: nắm được 5 loại tài liệu cơ bản giúp bạn biết mỗi loại phục vụ ai và dùng để viết loại test nào.

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

• Kể tên 5 loại tài liệu thiết kế cơ bản trong dự án outsourcing.
• Hiểu tài liệu nào giúp Developer code và Tester viết unit test, tài liệu nào để viết integration test.
• Biết rằng tên gọi tài liệu có thể khác nhau nhưng ý nghĩa cốt lõi thì tương tự.

─── NỘI DUNG CHÍNH

▸ 1. Năm loại tài liệu cơ bản

1. SRS (Software Requirement Specification): tài liệu đặc tả yêu cầu — phần mềm cần có những gì.
2. Basic Design: mô tả các chức năng, nội dung, tính năng chính.
3. Detailed Design / Function Design / Programming Design: tài liệu mang tính chi tiết để Developer code và Tester test được.
4. Database Design: thiết kế cơ sở dữ liệu gồm các bảng, cột.
5. Common: các quy định chung như rule coding, rule testing, message list.

▸ 2. Gắn với mô hình V-model

Hình dung theo V-model: từ tài liệu chi tiết (Function/Programming/Detailed Design), Developer code được và Tester viết unit test trên đó. Còn Basic Design là để dành viết integration test. Nhờ vậy mỗi tài liệu tương ứng với một mức kiểm thử khác nhau.

▸ 3. Lưu ý về tên gọi và ý nghĩa

Tên gọi các tài liệu này có thể khác nhau giữa các dự án, nhưng về ý nghĩa thì bạn hiểu theo ba nhóm: một loại đặc tả yêu cầu, một loại cho người dùng sử dụng, và một loại để Developer / Tester code và test. Trong ngành outsourcing, các bài sau sẽ đi chi tiết vào từng loại; ở bài này bạn chỉ cần nắm bức tranh tổng quan trước.

Chương 4 · Bài 2

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

Bài học đi sâu vào Basic Design — tài liệu thiết kế cơ bản mô tả tổng thể một hệ thống ở mức dễ đọc. Điểm mấu chốt: Basic Design cho bạn bức tranh chung về chức năng, kiến trúc và giao diện, và trong ngành outsourcing thị trường Nhật, đây là loại tài liệu bạn gặp thường xuyên hơn cả SRS.

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

• Nắm được các thành phần chính có trong một tài liệu Basic Design.
• Phân biệt được Basic Design với SRS và biết khi nào dự án dùng loại nào.
• Hiểu vì sao Tester cần đọc kỹ tài liệu này trước khi bắt tay vào dự án.

─── NỘI DUNG CHÍNH

▸ 1. Các thành phần của Basic Design

Một tài liệu Basic Design cơ bản thường gồm:

• Mô tả chức năng chính của hệ thống (ví dụ login, search, chỉnh sửa user).
• Kiến trúc hệ thống.
• Thiết kế cơ sở dữ liệu.
• Thiết kế giao diện người dùng và các ràng buộc liên quan tới thiết kế.
• Các thành phần có sẵn: quy định về thư viện, framework, công cụ hỗ trợ.

Giảng viên minh họa bằng một tài liệu sample truy cập qua link / QR code kèm trong slide.

▸ 2. Basic Design và SRS

SRS mô tả yêu cầu chi tiết và đầy đủ hơn, nhưng trong ngành outsourcing hiếm dự án có SRS. Thông thường dự án dùng Basic Design. Nếu một dự án đã có SRS thì thường lại không có Basic Design, và chỉ kèm thêm tài liệu Detailed Design. Vì vậy link SRS trong bài chỉ để tham khảo; trọng tâm giảng viên muốn trình bày vẫn là Basic Design.

▸ 3. Lưu ý khi đọc tài liệu thực tế

Khi làm nhiều dự án, bạn sẽ gặp nhiều thuật ngữ do khách hàng hay công ty tự quy định — đôi khi là tên tiếng Nhật khác với cách hiểu tiếng Việt. Điều quan trọng là đọc vào để hiểu tài liệu đang ở level nào rồi tiếp tục dự án. Về cơ bản, Basic Design quy định thiết kế giao diện, cách sử dụng dữ liệu, kiến trúc hệ thống và mô tả chức năng chính — nên bắt buộc phải đọc kỹ để hiểu rõ hệ thống.

Chương 4 · Bài 3

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

Bài học trình bày Detailed Design — tài liệu thiết kế chi tiết mà Developer dựa vào để code và Tester dựa vào để viết unit test. Điểm mấu chốt: đây là tài liệu mô tả tới tận từng control, từng luồng xử lý và cách ánh xạ dữ liệu xuống database, nên nó thường rất lớn và rất rõ ràng.

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

• Hiểu Detailed Design chi tiết ở mức nào so với Basic Design.
• Nhận biết các thành phần thường có trong tài liệu này (cover, history, danh sách màn hình, control).
• Biết vì sao dựa vào Detailed Design mà Tester có thể viết unit test.

─── NỘI DUNG CHÍNH

▸ 1. "Chi tiết" nghĩa là gì

Detailed Design (còn gọi là Programming Design hoặc Function Design) mô tả các control trên màn hình, các luồng xử lý, mỗi màn hình có bao nhiêu logic, người dùng tương tác lên button hay textbox thì validation ra sao. Với thiết kế API, nó mô tả bộ tham số, mapping cơ sở dữ liệu (mỗi field lưu vào database thế nào), cùng logic nghiệp vụ bên dưới. Tài liệu bao trùm cả UI, đầu vào – đầu ra và mức xử lý.

▸ 2. Cấu trúc một tài liệu mẫu

Tài liệu thường có sheet cover (bìa) và sheet history ghi nội dung thay đổi, ngày và person in charge. Tiếp theo là danh sách tất cả màn hình; mỗi màn hình mô tả loại control, cách hiển thị, cách xử lý, liên kết với database, kiểu dữ liệu (String, Integer…), và field là Input hay Output. Thực tế tài liệu rất lớn — một màn hình có thể trải hàng chục sheet.

▸ 3. Vai trò với Developer và Tester

Đây là tài liệu để Developer đọc, hiểu và code được. Dựa trên nó, Tester thực hiện unit test: validate từng trường, kiểm tra cách lưu database ở từng field.

▸ Lưu ý quan trọng: chỉ có Basic Design là chưa đủ

Nếu dự án chỉ có Basic Design thì Developer rất khó hiểu để code. Vì vậy phải làm tài liệu chi tiết như Detailed Design thì đội phát triển mới triển khai được — đây là điểm cần nhớ khi chuẩn bị tài liệu cho một dự án.

Chương 4 · Bài 4

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

Bài học giới thiệu các tài liệu bổ trợ ngoài Basic Design và Detailed Design, tập trung vào hai loại quan trọng: tài liệu định nghĩa database và message list. Điểm mấu chốt: đây là những tài liệu dùng chung, giúp cả đội thống nhất về cấu trúc dữ liệu và các thông báo hệ thống.

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

• Đọc hiểu một tài liệu định nghĩa database (bảng, trường, kiểu dữ liệu, khóa chính).
• Nắm được cấu trúc tối thiểu của một message list và cách message code được dùng trong code.
• Hiểu vì sao tùy tính chất dự án mà số lượng tài liệu bổ trợ sẽ khác nhau.

─── NỘI DUNG CHÍNH

▸ 1. Tài liệu định nghĩa database

Với dự án thị trường Nhật, file database thường ghi rất chi tiết từng bảng: có những trường nào, logic name (tên tiếng Nhật) và physical name (tên tiếng Anh, tên lưu trên database), kiểu dữ liệu, trường nào là khóa chính, có default hay tự động tăng không. Ngoài ra có thể kèm sheet ER / ERD thể hiện mối quan hệ giữa các bảng. Thông thường khách gửi kèm luôn script để tạo database; nếu không có script, đội Developer phải tự code script SQL để tạo.

▸ 2. Tài liệu message list

Message list liệt kê tối thiểu:

• Phân loại message: information, error, warning…
• Message code: mã dùng trong code thay cho việc ghi thẳng nội dung. Khi nhiều chức năng cùng cần một thông báo, lập trình viên chỉ gọi mã (ví dụ I007) là ra đúng message đó.

Vì hệ thống thường đa ngôn ngữ, message được define sẵn để lập trình nhiều ngôn ngữ cùng lúc. Comtor có thể dịch message từ tiếng Anh sang tiếng Nhật; Developer copy nội dung tương ứng bỏ vào code rồi chạy.

▸ 3. Tài liệu theo tính chất dự án

Mỗi dự án define ra bộ tài liệu để xử lý. Tối thiểu thường cần Basic Design, Detailed Design, message list, database. Nếu cần thêm phần kỹ thuật, đội sẽ tạo thêm tài liệu kỹ thuật riêng. Tùy tính chất dự án mà xác định cái gì bắt buộc phải có và cái gì được tạo thêm để hỗ trợ.

Chương 4 · Bài 5

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

Bài học tổng kết chương 4 về các tài liệu thiết kế, đồng thời chia sẻ kinh nghiệm cách phân loại tài liệu và lý do vì sao một dự án cần nhiều loại tài liệu khác nhau. Điểm mấu chốt: mỗi tài liệu tồn tại là để phục vụ một đối tượng đọc cụ thể, và việc chia nhỏ tài liệu còn giúp bảo mật ý tưởng, nghiệp vụ.

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

• Phân loại được tài liệu theo tính chất: chi tiết, dùng chung (Common), hay cho người dùng.
• Hiểu vì sao tài liệu tồn tại theo đối tượng đọc (user, Developer).
• Nắm được lý do dự án lớn chia nhỏ Detailed Design để bảo mật nghiệp vụ.

─── NỘI DUNG CHÍNH

▸ 1. Ôn lại các loại tài liệu

Chương này đã đi qua: các loại tài liệu trong phần mềm, một sample Basic Design, một sample Detailed Design, và các tài liệu khác như Database, Message List. Ở mức cơ bản, bấy nhiêu là đủ; một số dự án còn tạo thêm tài liệu như hướng dẫn setup source, hướng dẫn tạo test case…

▸ 2. Cách phân biệt tài liệu

• Tài liệu chi tiết (kết nối database, thuộc tính từng trường) giúp Developer code được — đó là Detailed Design / Programming Design / Function Design.
• Tài liệu cần thống nhất nhiều bên như Database, Message List là Common Document, tạo ra để dùng chung. Mẹo: cái gì cần thống nhất với nhau thì luôn nên tạo tài liệu Common.
• Tài liệu cho người dùng đọc thường là Basic / High Level Design.

▸ 3. Vì sao có nhiều loại tài liệu

Mỗi tài liệu phục vụ một đối tượng: user đọc Basic Design dễ hơn, Developer đọc Detailed Design dễ hơn. Trong gia công phần mềm, bên nhận thường nhận từ Basic Design rồi làm ra Detailed Design, hoặc nhận thẳng Detailed Design.

▸ 4. Chia nhỏ tài liệu để bảo mật

Khách hàng thường không share logic nghiệp vụ chính, chỉ share phần chi tiết đủ để code. Hệ thống lớn được chia thành nhiều Detailed Design cho từng màn hình, giao cho nhiều dev ở nhiều nơi (Trung Quốc, Malaysia, Việt Nam). Mỗi dev chỉ làm phần của mình, không ghép được toàn cục; phần liên kết do khách hàng hoặc BrSE đảm nhiệm. Nhờ vậy vừa chia việc, vừa tránh đánh cắp ý tưởng — nên đôi khi bạn chỉ hiểu màn hình mình phụ trách chứ không nắm tổng quan cả hệ thống.

Chương 5 · Bài 1

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

Bài mở đầu chương 5 giới thiệu 5 loại kiểm thử hay dùng nhất trong ngành gia công phần mềm, thay vì liệt kê hết vô số loại có trên mạng. Điểm mấu chốt: người mới nên bắt đầu ở mức khái niệm cơ bản, rồi học chi tiết dần qua on-the-job training và mentor — học quá sâu ngay từ đầu dễ bị "ngộp".

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

• Phân biệt được kiểm thử hộp trắng, hộp đen và hộp xám.
• Hiểu mục đích của performance testing và security testing.
• Biết một công cụ security testing miễn phí là OWASP ZAP.

─── NỘI DUNG CHÍNH

▸ 1. Hộp trắng, hộp đen, hộp xám

• Hộp trắng (white box): kiểm tra sâu bên trong, nhìn thấy source code và các hàm chạy thế nào, rồi kiểm tra ở mức mã nguồn.
• Hộp đen (black box): không thấy được ruột bên trong, chỉ kiểm tra đầu vào và đầu ra.
• Hộp xám (gray box): sự kết hợp cả hộp đen lẫn hộp trắng trong một phương pháp kiểm thử.

▸ 2. Performance testing

Kiểm thử hiệu năng đo sức chịu đựng của phần mềm theo nhiều hình thức: nhiều user truy cập cùng lúc, hoặc dồn nhiều request từ một function, để xem hiệu suất của website / phần mềm ra sao.

▸ 3. Security testing

Kiểm thử bảo mật đánh giá độ an toàn thông tin bằng cách giả lập tấn công chính trang web của mình. Thường dùng công cụ scan để phát hiện lỗ hổng, ví dụ OWASP ZAP — công cụ có cả bản tính phí và miễn phí. Ngoài ra một số trang web trên mạng cũng hỗ trợ chạy thử phần security testing.

▸ 4. Lời khuyên khi học

Trước khi deliver sản phẩm, bắt buộc phải chạy thử các loại kiểm thử này để biết phần mềm ổn tới đâu. Với người mới, hãy nắm khái niệm cơ bản trước, sau đó tìm hiểu và thực hành thêm; các link tham khảo trong blog của giảng viên giúp bạn đào sâu khi cần.

Chương 5 · Bài 2

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

Bài học giới thiệu 4 giai đoạn testing trong ngành gia công phần mềm: Unit Testing, Integration Testing, System Testing và User Acceptance Testing (UAT). Điểm mấu chốt: trong môi trường outsourcing, bạn chủ yếu làm Unit Testing và Integration Testing; UAT là việc của khách hàng, còn System Testing thì rất ít khi gặp.

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

• Phân biệt được 4 giai đoạn testing và thứ tự từ đơn vị nhỏ đến tổng thể.
• Biết giai đoạn nào là phần việc chính của một tester trong công ty gia công.
• Hiểu vì sao UAT phải do end user / khách hàng thực hiện, không phải bên gia công.

─── NỘI DUNG CHÍNH

▸ 1. Bốn giai đoạn testing

• Unit Testing: kiểm thử ở đơn vị nhỏ nhất — ví dụ chỉ một màn hình login. Ví như kiểm tra chức năng của riêng một căn phòng trong nhà.
• Integration Testing: kiểm thử sự liên đới giữa các phần — ví dụ luồng từ màn hình login sang màn hình danh sách user. Ví như xem các phòng phối hợp với nhau ra sao.
• System Testing: khi dự án có nhiều hệ thống tích hợp với nhau (ví dụ phải kết nối tới một database hoặc một system bên ngoài).
• User Acceptance Testing (UAT): khách hàng / end user nghiệm thu sản phẩm cuối.

▸ 2. Phần việc thật của tester trong outsourcing

Trong công ty gia công, bạn thường làm nhiều nhất là Unit Testing và Integration Testing. System Testing ít khi bên gia công nhận. UAT thì để dành cho khách hàng.

▸ 3. Lưu ý: ai làm UAT?

Người approve, nghiệm thu sản phẩm cuối cùng phải là khách hàng / end user. Trong mô hình outsourcing, một công ty IT khác order cho bạn thì chính họ là người thực hiện UAT. Nếu có ai bảo bạn "làm UAT" thì điều đó là sai với vai trò của bên gia công.

Chương 5 · Bài 3

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

Bài học tóm tắt 7 nguyên lý kiểm thử phần mềm — những đúc kết kinh điển giúp tester hiểu đúng bản chất công việc. Điểm mấu chốt: kiểm thử chỉ chứng minh sự hiện diện của lỗi chứ không chứng minh phần mềm không còn lỗi, và kiểm thử càng sớm càng tiết kiệm chi phí.

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

• Nắm được 7 nguyên lý kiểm thử và ý nghĩa thực tế của từng nguyên lý.
• Hiểu vì sao "test cho hết bug" là bất khả thi và lỗi thường gom thành nhóm.
• Ý thức được tầm quan trọng của việc phát hiện lỗi sớm qua định luật Heinrich.

─── NỘI DUNG CHÍNH

▸ 1. Bảy nguyên lý kiểm thử

1. Kiểm thử chỉ cho thấy sự hiện diện của lỗi, không chứng minh phần mềm hết lỗi.
2. Kiểm thử toàn bộ (hết bug) là bất khả thi — còn code, còn kiểm thì còn khả năng có bug.
3. Kiểm thử sớm giúp tiết kiệm thời gian và tiền bạc — "phòng cháy hơn chữa cháy".
4. Lỗi gom thành nhóm: bug thường tập trung vào một màn hình, thậm chí vào nhóm người viết ra phần đó.
5. Nghịch lý thuốc trừ sâu: lặp lại một bộ test mãi sẽ không tìm ra lỗi mới — phải thay đổi cách nghĩ và cách kiểm.
6. Kiểm thử phụ thuộc ngữ cảnh: môi trường, database, version… khác nhau thì kết quả khác nhau.
7. Không có phần mềm hết lỗi tuyệt đối — phần mềm còn dùng thì còn update, còn lỗi.

▸ 2. Liên hệ định luật Heinrich

Định luật Heinrich (tỷ lệ 1 – 29 – 300) trong an toàn lao động: 300 sự cố cận nguy sẽ kéo theo 29 sự cố ít nghiêm trọng và 1 tai nạn rất nghiêm trọng. Áp vào phần mềm: nếu giai đoạn đầu không phát hiện và xử lý lỗi nhỏ, đến giai đoạn sau hậu quả càng nặng.

▸ 3. Vì sao phải kiểm thử kỹ

Giảng viên lấy ví dụ phần mềm ngân hàng: một bug khi rút tiền ATM có thể khiến người dùng bị trừ tiền mà không rút được, thậm chí bị nuốt thẻ. Đây là minh họa cho việc lỗi bị bỏ qua có thể gây hậu quả rất nghiêm trọng, nên kiểm thử kỹ là điều bắt buộc.

Chương 5 · Bài 4

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

Bài học giới thiệu 7 thông tin cơ bản cần có trong một tài liệu test case, theo cách làm thực tế và tối giản nhất của giảng viên. Điểm mấu chốt: mỗi test case phải có ID duy nhất để về sau đối chiếu được test case nào tìm ra bug — từ đó biết test case có chất lượng hay không.

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

• Biết một test case tối thiểu cần những cột / thông tin nào.
• Hiểu vì sao test case ID phải là duy nhất và cần note vào bug.
• Đọc hiểu một template test case tham khảo (category, summary, status, person in charge…).

─── NỘI DUNG CHÍNH

▸ 1. Bảy thông tin cơ bản của test case

1. Mã (ID) test case — duy nhất cho mỗi test case.
2. Nội dung test case — test cái gì, mô tả các bước step by step.
3. Expected result — kết quả mong muốn (input vào, output ra, validation ra sao).
4. Trạng thái — Not yet (chưa test) hay đã test xong.
5. Ghi chú — nếu có bug thì note lại bug ID vào đây.
6. Người thực hiện.
7. Các thông tin quản lý kèm theo (ngày test, ngày retest…).

▸ 2. Lưu ý quan trọng: test case ID

Test case ID giúp người kiểm tra số liệu biết được mỗi test case tìm ra bao nhiêu bug, tức đánh giá được chất lượng test case. Thực tế thường gặp: tester chạy đúng test case lại không ra bug, còn chạy theo cách mình hiểu thì lại ra bug. Nếu không note test case ID vào bug, bạn không biết test case của mình có chất lượng hay không. Vì vậy test case ID phải có và phải duy nhất.

▸ 3. Đọc một template test case tham khảo

Một template mẫu thường có: category của test case, phần summary tổng hợp số lượng, đối tượng test (ví dụ UI), nội dung test case, các bước step by step (điều kiện — bước 1, 2, 3, 4), status, person in charge, ngày, ngày retest và bug ID. Bạn có thể tô màu, group lại cho gọn gàng hơn, nhưng về tối thiểu chỉ cần đủ những thông tin trên.

Chương 5 · Bài 5

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

Bài học chỉ ra 4 tiêu chí để đánh giá một tài liệu test case là chuẩn — đầy đủ và có thể quản lý được. Điểm mấu chốt: viết được test case chưa đủ; một tài liệu chuẩn còn phải có số liệu và đúng format thì mới quản lý và thống kê được.

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

• Biết 4 tiêu chí để tự kiểm tra một tài liệu test case đã "đủ chuẩn" hay chưa.
• Hiểu vì sao cần kiểm soát tổng số lượng test case và trạng thái của chúng.
• Nắm các yêu cầu về format: font, ô A1, sheet cover, sheet history.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao cần chuẩn hóa tài liệu test case

Nhiều bạn biết viết test case nhưng khi được hỏi "một file test case thế nào là đầy đủ" thì không trả lời được, vì nghĩ chỉ cần viết xong và báo xong là đủ. Thực tế khi đi làm, "xong" còn phải kèm số liệu để người khác quản lý được.

▸ 2. Bốn tiêu chí của tài liệu test case chuẩn

1. Thông tin đầy đủ — không còn test case bị outdated, mọi thông tin cần có đều có.
2. Kiểm soát được số lượng — biết tổng số test case (ví dụ 500, 400, 30…), và trong quá trình test đã OK bao nhiêu, còn lại bao nhiêu.
3. Trạng thái test case ghi đầy đủ — ví dụ khi chưa test thì tất cả để Not yet.
4. Format đúng chuẩn — font chữ, font size, màu sắc giữa các sheet phải thống nhất; đưa con trỏ về ô A1; mỗi file phải có sheet cover và sheet history.

▸ 3. Ghi nhớ

Một tài liệu test case chuẩn = thông tin đầy đủ + có số lượng + trạng thái rõ ràng + format thống nhất. Thiếu bất kỳ tiêu chí nào thì tài liệu vẫn chưa được coi là chuẩn.

Chương 5 · Bài 6

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

Bài học liệt kê các thông tin cơ bản cần ghi cho một bug, giới thiệu vòng đời của bug và phân biệt hai khái niệm dễ nhầm là severity và priority. Điểm mấu chốt: ghi bug đầy đủ để thống kê, phân loại và ưu tiên xử lý, đồng thời truy được root cause thay vì chỉ chữa phần ngọn.

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

• Biết một bug cần ghi những trường thông tin cơ bản nào.
• Hiểu vòng đời của bug qua các trạng thái từ khi tạo đến khi đóng.
• Phân biệt được severity (mức nghiêm trọng) và priority (độ ưu tiên).

─── NỘI DUNG CHÍNH

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

1. Tên bug.
2. Mô tả bug.
3. Severity — mức độ nghiêm trọng.
4. Loại lỗi và nguyên nhân gây ra bug.
5. Phase — bug thuộc giai đoạn nào (ví dụ Unit Test).
6. Hành động khắc phục.
7. Bước tái hiện (kèm hình ảnh / video / log làm bằng chứng).

Việc phân loại lỗi giúp tìm đúng người xử lý: bug logic liên quan nghiệp vụ thì tìm BA; bug layout / kỹ thuật thì tìm đội technical. Để tìm nguyên nhân cốt lõi, giảng viên gợi ý dùng phương pháp 5 Why — hỏi "tại sao" nhiều lần để truy về root cause rồi sửa gốc, khi đó bug sẽ giảm.

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

Một bug thường bắt đầu ở trạng thái New, sau đó được assign cho người khác fix; fix xong thì chuyển sang retest. Trường hợp bug không được sửa có thể rơi vào các trạng thái như reject (không phải bug), refer (chuyển chỗ khác) hoặc duplicate. Khi log bug lên hệ thống quản lý, phần mô tả (subject, summary, recognition, steps, pre-condition…) có thể lấy lại từ file test case.

▸ 3. Phân biệt severity và priority

Đây là hai trường hay gây nhầm lẫn nhất:

• Severity — mức độ nghiêm trọng, thường có 5 mức: Trivial, Minor, Major, Critical, Blocker. Hệ thống sập, mất dữ liệu thì là critical; chức năng không hoạt động thì là major.
• Priority — độ ưu tiên xử lý (ví dụ cao / trung bình).

Hai trường này độc lập nhau: một bug có thể severity major (chức năng không chạy) nhưng priority trung bình nếu được xếp vào bản cập nhật sau; ngược lại bug cần sửa ngay thì đặt priority cao.

Chương 5 · Bài 7

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

Bài học giải thích Evidence — bằng chứng ghi lại kết quả thực tế của việc kiểm thử. Điểm mấu chốt: Evidence dùng để xác minh rằng bạn đã test và test ra kết quả gì; nó không làm tăng chất lượng sản phẩm, nên trong outsourcing nếu deal được với khách hàng thì có thể không cần chụp để tiết kiệm effort.

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

• Hiểu Evidence là gì và có thể ở dạng nào (ảnh, video, log file).
• Biết ý nghĩa của Evidence trong việc xác minh và xử lý sự cố.
• Cân nhắc được khi nào nên / không nên tốn công chụp Evidence.

─── NỘI DUNG CHÍNH

▸ 1. Evidence là gì

Evidence là việc ghi lại kết quả thực tế khi kiểm thử để có bằng chứng về kết quả, hành vi của hệ thống. Cách chụp chính xác là ghi lại màn hình từ bước bắt đầu đến bước kết thúc. Evidence có thể là:

• Hình ảnh chụp màn hình.
• Video ghi lại thao tác.
• Log file — với các phần chạy ngầm (batch) không có màn hình thì log chính là Evidence.

▸ 2. Vì sao cần Evidence

• Xác minh bạn đã thực hiện kiểm thử và cho ra kết quả gì.
• Trong outsourcing, công ty order có thể dựa vào Evidence của bạn để đánh giá kết quả thay vì phải test lại hoặc phải tin vào mỗi bản báo cáo.
• Khi phát hiện bug, người khác xem lại Evidence để hiểu bạn đã test thế nào và tình huống phát sinh ra sao, nhờ đó giải quyết vấn đề nhanh hơn.

▸ 3. Lưu ý: Evidence không tăng chất lượng

Evidence chỉ là bằng chứng đã kiểm tra, bản thân nó không nâng chất lượng sản phẩm — muốn tăng chất lượng thì nên dành thời gian test thêm. Chụp Evidence còn tốn thêm effort (test một round, log bug, retest rồi lại chụp là mất thêm thời gian). Vì vậy trong outsourcing, nếu deal được với khách hàng, giảng viên khuyên có thể thỏa thuận không cần chụp Evidence.

Chương 5 · Bài 8

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

Bài học điểm qua bộ công cụ tối thiểu đủ để làm vị trí QC / Tester. Điểm mấu chốt: bạn chỉ cần nắm vài công cụ cơ bản — Excel / Google Sheet, một hệ thống log bug, và một công cụ chụp Evidence — là đủ để bắt đầu làm nghề, chưa cần đến công cụ kiểm thử tự động.

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

• Biết bộ công cụ tối thiểu cần học cho vị trí QC / Tester.
• Hiểu vì sao chỉ cần thành thạo một hệ thống log bug là đủ.
• Biết tài khoản và template thực hành nào được khóa học cung cấp.

─── NỘI DUNG CHÍNH

▸ 1. Công cụ quản lý test case: Excel / Google Sheet

Dùng Excel hoặc Google Sheet để quản lý thông tin test case. Chỉ cần học vài công thức cơ bản là đủ dùng. Bạn có thể dùng luôn tài khoản Gmail của mình để làm việc trên Google Sheet.

▸ 2. Hệ thống log bug

Chỉ cần biết một trong các hệ thống: Jira, Bugzilla, Redmine hoặc tương tự. Hiểu được ý nghĩa của một hệ thống thì khi chuyển sang hệ thống khác cũng giống nhau. Khóa học cấp phát tài khoản Redmine để bạn thực hành log bug.

▸ 3. Công cụ chụp Evidence và công cụ nâng cao

Dùng công cụ chụp màn hình như Snagit để chụp Evidence. Công cụ kiểm thử tự động là mức nâng cao — người mới chuyển sang nghề chưa cần đến. Tất cả công cụ, template và tài khoản thực hành nói trên đều đã được chia sẻ sẵn trong folder khóa học; bạn chỉ cần học đúng bộ công cụ này là đủ dùng khi đi làm.

Chương 5 · Bài 9

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

Bài học tổng kết toàn bộ Chương 5 — kiến thức cơ bản về kiểm thử phần mềm và chia sẻ kinh nghiệm quản lý dữ liệu test case và bug. Điểm mấu chốt: ngoài việc test, bạn nên thống kê số liệu theo từng ngày để tính được năng suất làm việc của mình.

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

• Hệ thống lại các khái niệm chính đã học trong Chương 5.
• Biết cách quản lý dữ liệu test case và bug theo từng ngày.
• Hiểu vì sao thống kê số liệu là nền tảng để tính năng suất.

─── NỘI DUNG CHÍNH

▸ 1. Ôn lại các kiến thức Chương 5

• Các loại kiểm thử trong phần mềm: Blackbox, Whitebox, Greybox, Stress Testing, Security Testing.
• Các giai đoạn testing trong outsourcing: unit test, integration test, system test, user acceptance test.
• 7 nguyên lý kiểm thử — ví dụ nghịch lý thuốc trừ sâu, và phần mềm còn dùng thì còn bug.
• Thông tin cơ bản của test case: ID, mô tả, trạng thái, người test, ngày test.
• Thông tin cơ bản của bug: tiêu đề, mã màn hình, mô tả các bước.
• Evidence: bằng chứng chụp / record lại khi test, và các công cụ hỗ trợ như Excel, Google Sheet, Snagit.

▸ 2. Kinh nghiệm quản lý dữ liệu test case và bug

Nên có form / mẫu hoặc một nơi để thống kê theo từng ngày: mỗi ngày làm được bao nhiêu test case, test được bao nhiêu, tốn bao nhiêu thời gian, phát sinh bao nhiêu bug. Nếu chưa biết dùng công cụ, bạn có thể ghi ra giấy cũng được — đó là cách quản lý dữ liệu cơ bản nhất.

▸ 3. Từ số liệu đến năng suất

Sau khi ghi lại số liệu, bạn tính tổng và chia để ra được năng suất làm việc. Đây là nền tảng cho các bài sau, nơi giảng viên sẽ hướng dẫn cụ thể cách tính năng suất. Lưu ý: Evidence không làm tăng chất lượng, nhưng quản lý tốt dữ liệu test case và bug thì giúp bạn đánh giá được hiệu quả công việc.

Chương 6 · Bài 1

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

Bài học giới thiệu dự án demo dùng xuyên suốt quá trình thực hành, thông qua file báo giá / proposal estimation của dự án. Điểm mấu chốt: trước khi bắt tay vào test, bạn nên đọc phần overview để nắm được scope, timeline, cost và điều kiện chấp nhận sản phẩm.

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

• Hình dung được một dự án demo cơ bản để thực hành trong khóa học.
• Biết một file báo giá / proposal estimation thường gồm những thông tin gì.
• Biết cần nắm những gì (scope, timeline, cost, quality) khi mới vào một dự án.

─── NỘI DUNG CHÍNH

▸ 1. Cấu trúc một file báo giá dự án

File demo (proposal estimation) thường mở đầu bằng trang bìa (mã dự án, tên dự án, phiên bản; ở thị trường Nhật thì tên bằng tiếng Nhật), tiếp theo là:

• Sheet history — lịch sử thay đổi.
• Sheet overview — tổng thể dự án: phạm vi công việc, ngôn ngữ lập trình, máy chủ / nền tảng / trình duyệt, các đợt phát triển và người thực hiện, các giả định (assumption) và điều kiện ràng buộc.
• Các giai đoạn phải hoàn thành, phần việc của khách hàng và của mình, kênh giao tiếp.

▸ 2. Điều kiện ràng buộc và kế hoạch thanh toán

Trong phần giả định có các điều kiện ràng buộc: nếu trong quá trình làm phát hiện điều gì khác biệt so với thỏa thuận thì có thể báo giá lại. File báo giá còn có thể kèm kế hoạch thanh toán. Một số công ty gộp dự án và báo giá vào một file, số khác tách riêng phần dự án và phần tiền.

▸ 3. WBS và những gì cần nắm khi vào dự án

File thường có thêm sheet rã nhỏ từng phần công việc — có công ty gọi là phụ lục hợp đồng, có công ty gọi là WBS — trong đó ghi rõ từng chức năng, tổng số ngày công và các chi phí khác. Khi vào một dự án, bạn nên đọc overview để nắm: scope (phạm vi), timeline (dự kiến khi nào hoàn thành), cost (chi phí), và phần quality (điều kiện chấp nhận sản phẩm) — để hiểu tổng quan dự án và phần việc của mình.

Chương 6 · Bài 2

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

Bài học giới thiệu 3 tài liệu của dự án demo: một tài liệu mô tả màn hình (Basic Design) và hai dạng template test case. Điểm mấu chốt: bài này tập trung giới thiệu hình thức / template của tài liệu (dạng dọc theo cột và dạng matrix), chưa đi vào nội dung chi tiết.

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

• Biết dự án demo có những tài liệu nào và truy cập chúng qua link / QR code.
• Phân biệt được tài liệu Basic Design và Detailed Design.
• Nhận ra hai dạng template test case: dạng dọc theo cột và dạng matrix.

─── NỘI DUNG CHÍNH

▸ 1. Tài liệu mô tả màn hình (Basic Design)

Tài liệu thứ nhất mô tả 3 màn hình: màn hình login, màn hình danh sách user, màn hình chỉnh sửa user. Đây là tài liệu Basic Design (thiết kế cơ bản) — chỉ mô tả màn hình sẽ action như thế nào để người đọc hiểu chức năng. Nó không đi sâu vào chi tiết kỹ thuật như lấy dữ liệu từ bảng database nào — phần đó thuộc Detailed Design.

▸ 2. Template test case dạng dọc (theo cột)

Dạng thứ nhất hiển thị test case theo từng cột: kiểm tra từng mục về điều kiện là gì, kết quả là gì, rồi đến trạng thái, người tạo, ngày tạo. Mỗi màn hình làm một bộ test case riêng, sau đó có thêm một sheet UI để tổng hợp lại phần màn hình hiện tại.

▸ 3. Template test case dạng matrix

Dạng thứ hai là matrix: đánh dấu Maru (dấu tròn) cho từng mục cần kiểm — ví dụ kiểm màu sắc, position của các element, rồi độ dài của element. Nếu độ dài element không hiển thị giống UI thiết kế thì coi như có bug. Khi kết quả OK thì đánh dấu và ghi mã, ngày retest. Dạng matrix giúp đánh dấu nhanh gọn hơn so với dạng dọc theo cột.

Chương 7 · Bài 1

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

Bài học mở đầu chương Unit Testing với định nghĩa dễ hiểu nhất: đây là hình thức kiểm thử ở mức đơn vị của mã nguồn, độc lập với phần còn lại của hệ thống, để đảm bảo mỗi đơn vị hoạt động đúng như thiết kế. Điểm mấu chốt cần nhớ: Unit Test mang tính mức độ thấp, tập trung vào các thành phần nhỏ nhất, và kiểm tra từng màn hình riêng lẻ chứ không ghép nối các màn hình với nhau.

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

• Hiểu định nghĩa Unit Testing theo cách đơn giản, dễ hình dung.
• Phân biệt được "kiểm thử độc lập từng đơn vị" với việc test cả luồng hệ thống.
• Biết những gì cần kiểm tra ở phạm vi một màn hình đơn lẻ.

─── NỘI DUNG CHÍNH

▸ 1. Định nghĩa Unit Testing

Unit Testing là kiểm thử ở mức đơn vị của mã nguồn, độc lập với phần còn lại của hệ thống, nhằm bảo đảm mỗi đơn vị đạt đúng thiết kế. Nó ở mức độ thấp và hướng vào các thành phần nhỏ của phần mềm, chứ không nhìn toàn cục.

▸ 2. Kiểm thử độc lập từng màn hình

Lấy ví dụ bài tập 3 màn hình quen thuộc — login, list user, chỉnh sửa user — Unit Test nghĩa là kiểm tra từng màn hình riêng lẻ, không kết hợp. Với màn hình login, bạn chỉ tập trung: nhập username, password có đúng không, độ dài bao nhiêu, ký tự thế nào, validation ra sao. Sang màn hình list thì cũng chỉ soi riêng màn hình đó.

▸ 3. Phạm vi kiểm tra ở đơn vị nhỏ nhất

Ở mỗi màn hình, bạn kiểm tra tới đơn vị nhỏ nhất: từng textbox nhập vào đã có validation chưa, có đúng thiết kế chưa, màu sắc, layout, tất cả mọi thứ hiển thị. Luôn tự nhắc mình đang làm việc ở phạm vi một màn hình duy nhất, không phải cả danh sách màn hình. Đây chính là tinh thần "đơn vị" của Unit Test.

▸ 4. Tài liệu tham khảo thêm

Giảng viên đính kèm một bài blog để bạn đọc mở rộng về Unit Testing. Phần lý thuyết ở bài này cố tình giữ ngắn gọn, vì nội dung chi tiết và phần thực hành sẽ được đào sâu ở các bài tiếp theo trong chương.

Chương 7 · Bài 2

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

Bài học giới thiệu khái niệm POV (Point Of View) — tập hợp các quan điểm test dùng làm khung định hướng khi viết test case cho một dự án. Điểm mấu chốt: SmartITSoft cung cấp sẵn một POV mẫu, và công việc của Tester là dựa trên bộ mẫu đó để lọc, điều chỉnh và thống nhất cho phù hợp với dự án của mình, thay vì phải nghĩ ra mọi quan điểm từ con số không.

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

• Hiểu POV (Point Of View) là gì và vai trò của nó trong việc test.
• Biết SmartITSoft có sẵn một POV mẫu để tái sử dụng cho dự án.
• Nắm được ý nghĩa của việc lọc và đánh dấu các quan điểm phù hợp với dự án.

─── NỘI DUNG CHÍNH

▸ 1. POV (Point Of View) là gì?

POV là bộ các quan điểm mà đội test sẽ áp dụng khi kiểm thử một dự án — ví dụ nhóm quan điểm liên quan tới verify layout / giao diện, quan điểm về chức năng đăng nhập, v.v. Khi một người mở file POV ra, họ nhìn thấy ngay dự án này cần tập trung test vào những phần nào. Nhờ vậy, một thành viên mới vào dự án cũng nhanh chóng hình dung được bức tranh tổng thể về việc cần kiểm thử.

▸ 2. POV mẫu của SmartITSoft

SmartITSoft chia sẻ một POV mẫu liệt kê sẵn nhiều quan điểm test thường gặp. Đây là điểm khởi đầu để bạn không phải xây dựng lại từ đầu. Với dự án cụ thể, bạn mở POV mẫu ra và lưu thành một bản mới (chẳng hạn POV số 2) để chỉnh sửa riêng cho dự án.

▸ 3. Lọc quan điểm theo dự án

Việc đầu tiên là filter toàn bộ danh sách quan điểm: quan điểm nào có tồn tại trong dự án thì đánh dấu để giữ lại và sẽ được test; quan điểm nào không áp dụng thì bỏ qua. Nếu thấy thiếu, bạn bổ sung thêm quan điểm mới. Kết quả là một POV phản ánh đúng phạm vi test của dự án, làm nền tảng cho bước viết test case sau này.

Chương 7 · Bài 3

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

Bài học hướng dẫn tự tạo một POV hoàn chỉnh cho dự án, thay vì chỉ dùng POV có sẵn. Điểm mấu chốt: quy trình đi từ đọc hiểu thông tin dự án → đưa ra quan điểm → dựa trên POV có sẵn để điều chỉnh → họp team thống nhất → tạo POV. POV chỉ liệt kê quan điểm test ở mức tổng quan cho từng màn hình, không đi vào chi tiết từng bước, và phải được cả team đồng thuận thì mới có giá trị.

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

• Nắm được các bước tạo POV cho một dự án cụ thể.
• Biết cách liệt kê quan điểm test cho từng màn hình theo mã màn hình.
• Hiểu vì sao POV cần được cả team review và thống nhất.

─── NỘI DUNG CHÍNH

▸ 1. Các bước tạo POV

Trình tự thực hiện: (1) đọc thông tin dự án để hiểu nghiệp vụ; (2) đưa ra các quan điểm test của riêng bạn; (3) dựa trên POV có sẵn để điều chỉnh cho nhanh; (4) họp với team để thảo luận; (5) thống nhất rồi tạo ra POV cho dự án. Hiểu dự án trước, rồi mới tinh chỉnh trên nền có sẵn.

▸ 2. Liệt kê quan điểm theo từng màn hình

Mở bài tập 3 màn hình, ứng với mỗi màn hình có mã riêng (SCR01 login, SCR02 list user…) và một tính năng khác nhau. Với màn hình login, bạn liệt kê các quan điểm như: đăng nhập thành công, đăng nhập thất bại; trong "thất bại" tổ hợp các trường hợp đúng username / sai (size) password, đúng password / sai username… Kết quả kỳ vọng ghi kèm: thất bại thì hiển thị thông báo lỗi, thành công thì vào được màn hình bên trong.

▸ 3. Chỉ ghi quan điểm, không ghi chi tiết

Lưu ý quan trọng: ở POV bạn chỉ liệt kê quan điểm, không viết chi tiết như test case. Cách tổ chức (đúng/sai, tổ hợp trường hợp) tùy bạn, miễn nêu được những gì sẽ test trên màn hình đó.

▸ 4. Phân công và review theo nhóm

Trong đội có nhiều Tester, mỗi bạn tạo POV cho một màn hình để tiết kiệm thời gian (Tester 1 làm login, Tester 2 làm list user…). Sau đó cả nhóm họp lại, trình bày và review, ai cần bổ sung thì bổ sung, để ra được một POV chung. Nhờ tài liệu này, người mới vào dự án hiểu nhanh hơn và cả team test đồng nhất quan điểm.

Chương 7 · Bài 4

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

Bài học hướng dẫn thực hành viết Unit Test Case cho một bài tập login mẫu gồm 3 màn hình (đăng nhập, list user, chỉnh sửa user). Điểm mấu chốt: mỗi test case đều được viết bám theo POV (Point Of View) và luôn theo thứ tự Layout → Hiển thị → Chức năng, chỉ kiểm thử ở đơn vị từng màn hình (đúng tinh thần Unit Test).

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

• Biết cách dùng file POV để làm khung viết test case cho từng màn hình.
• Viết được test case theo thứ tự Layout → hiển thị mặc định → chức năng.
• Phân tích nghiệp vụ màn hình và bao phủ các trường hợp hợp lệ / không hợp lệ / biên.

─── NỘI DUNG CHÍNH

▸ 1. Chuẩn bị: template và bài tập 3 màn hình

Tải template test case (qua link/QR, request quyền nếu cần). Bài tập gồm: màn hình login (SCR01) — username, password, đăng nhập, nhập lại; màn hình list user — tìm kiếm, phân trang, edit, sort; màn hình chỉnh sửa user — cập nhật / nhập lại (reset).

▸ 2. Viết test case bám theo POV

Mở file POV (Point Of View) làm khung. Bắt đầu từ tiêu chí POV 101 — verify layout / giao diện (menu, submenu, button, check button, màu sắc, textbox có đúng thiết kế không). Với mỗi màn hình, viết theo thứ tự: Layout → hiển thị mặc định → chức năng cơ bản.

▸ 3. Bao phủ trường hợp cho màn hình login

Sau layout, kiểm thử từng field: giá trị hợp lệ / không hợp lệ, ký tự 2 byte / 1 byte, ký tự không phải Unicode, ký tự đặc biệt, khoảng trắng, thông báo lỗi đúng chưa; nút nhập lại có reset không; nút đăng nhập vào đúng màn hình bên trong không.

▸ 4. Phân tích nghiệp vụ màn hình list user

Với màn hình list, xác định nghiệp vụ chính: tìm kiếm (theo họ tên / email / user), phân trang, edit, sort. Test trường hợp bình thường (OK) trước, rồi các trường hợp nhiều kết quả → phân trang, đổi cấu hình số record/trang.

▸ Mẹo quan trọng: các tình huống dễ bỏ sót

Chú ý những case hay quên: đang ở trang 3 mà xóa một user thì hệ thống quay về trang 1 hay giữ trang 3, và dữ liệu trang sau có được "đôn" lên không — phải quy định rõ trong test case. Lưu ý: vì đang test unit ở đơn vị màn hình, chưa test luồng qua lại giữa các màn hình (phần đó để dành cho Integration Test).

Chương 7 · Bài 5

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

Bài học hướng dẫn thực thi (chạy) file Unit Test Case đã viết và biến nó thành Unit Test Report. Điểm mấu chốt: cần phân biệt rõ Test Case (chỉ có nội dung test, chưa có kết quả) với Test Report (đã điền trạng thái, người test, ngày test, bug ID). Cả quá trình xoay quanh một vòng lặp: test → thấy lỗi → log bug → dev fix → retest → đóng, và luôn giữ lại bug ID để truy vết.

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

• Phân biệt được Unit Test Case và Unit Test Report.
• Hiểu flow thực thi test và ghi nhận kết quả cho từng test case.
• Biết vì sao phải giữ lại bug ID và bổ sung ngày retest.

─── NỘI DUNG CHÍNH

▸ 1. Test Case khác Test Report ở điểm nào?

Unit Test Case là các test case bạn đã ghi ra nhưng chưa có kết quả đánh giá. Khi bạn đã điền trạng thái, cách test, ai test, test ngày nào, bug ID bao nhiêu… thì nó trở thành Unit Test Report. Nguyên tắc này áp dụng tương tự cho Integration Test Case và Integration Test Report.

▸ 2. Quy trình thực thi và log bug

Chạy phần mềm / website lên rồi test lần lượt. Khi phát hiện lỗi, vào hệ thống log bug ghi nhận lại, kèm ảnh evidence (bằng chứng tại thời điểm lỗi) để đội developer hiểu. Developer fix xong sẽ báo bug đã resolved; Tester lên test lại, thấy OK thì đóng bug.

▸ 3. Giữ lại bug ID và ngày retest

Khi đóng bug, không xóa bug ID — vẫn để lại để mọi người biết test case này từng phát sinh bug đó. Thông thường test case có thêm cột ngày retest, nằm sau ngày test đầu tiên; retest thấy OK thì đánh trạng thái good. Ghi nhớ flow: điền thông tin → retest → gắn bug ID → điền lại trạng thái OK.

▸ 4. Những điểm cần nhấn mạnh

Hai điều cốt lõi cần nhớ: Test Case và Test Report khác nhau ở chỗ đã điền kết quả hay chưa, và cách ghi nhận thông tin thực thi. Phần thao tác trên hệ thống log bug đã được demo ở bài trước nên bài này chỉ giải thích lại ý nghĩa cho bạn nắm chắc.

Chương 7 · Bài 6

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

Bài học giải thích vì sao và bằng cách nào log bug lên hệ thống quản lý (như Redmine, hoặc file Google Sheet mô phỏng theo Redmine). Điểm mấu chốt: khi số lượng bug lớn tới hàng trăm, không có hệ thống quản lý thì không thể theo dõi được bug thuộc loại lỗi gì và đang ở trạng thái nào. Mỗi bug đều đi qua một vòng đời — log bug → sửa lỗi → deploy → test lại → đóng bug — nên cần công cụ để quản lý.

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

• Hiểu lý do phải log bug lên hệ thống quản lý thay vì ghi rời rạc.
• Nắm được các trường thông tin cơ bản của một bug.
• Biết ý nghĩa của việc liên kết bug ID với test case ID.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao cần hệ thống quản lý bug

Khi dự án phát sinh rất nhiều bug, hệ thống quản lý giúp bạn biết mỗi bug thuộc loại lỗi gì và đang ở trạng thái nào. Mỗi bug có một vòng đời: log bug → sửa lỗi → deploy → test lại (retest) → đóng bug. Không có công cụ quản lý thì cả vòng đời này không thể kiểm soát. Bài học minh họa trên Redmine và trên một template Google Sheet được dựng cho giống Redmine.

▸ 2. Các trường thông tin của một bug

Một bug (tracker = bug) trong template gồm các trường cơ bản như: bug ID, subject, description, status (ví dụ New), priority và severity. Trong đó priority có các mức Low, Normal, High, Urgent, Immediate; severity có Critical, Major, Minor, Trivial. Các giá trị này được đưa vào dạng combo box để dễ chọn khi nhập.

▸ 3. Ghi nhận bug kèm evidence

Mỗi bug cần mô tả rõ test step, kết quả thực tế và kết quả mong muốn (ví dụ: vào màn hình login, nút login bị lỗi không bấm được; mong muốn là bấm được nút login), kèm ảnh chụp evidence của layout tại thời điểm lỗi. Mức priority/severity chọn theo mức độ nghiêm trọng — lỗi khiến không vào được hệ thống thì đặt ưu tiên cao.

▸ 4. Liên kết bug ID với test case ID

Sau khi log bug và nhận về mã bug ID, bạn điền ID này vào file test case; đồng thời gắn kèm test case ID (UTC ID) để hai bên tham chiếu lẫn nhau. Nhờ liên kết này, ai nhìn vào cũng biết bug thuộc test case nào. Nếu không có hệ thống chuyên dụng, dùng file bug được share quyền cho các bên cùng log cũng là một cách khả thi.

Chương 7 · Bài 7

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

Bài học hướng dẫn làm báo cáo tổng hợp sau khi thực thi xong Unit Test Case (UTC). Điểm mấu chốt: một báo cáo Unit Testing cần nêu rõ tổng số test case, số đã thực hiện, số còn lại, số bug tìm thấy, số bug đã xử lý và số còn lại, kèm một nhận định về chất lượng sản phẩm. Đừng đợi làm xong toàn bộ mới báo cáo — nên báo cáo theo ngày hoặc theo từng cụm màn hình / cụm tính năng.

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

• Biết những thông tin cần có trong một báo cáo Unit Testing.
• Dùng được COUNTIF và INDIRECT để tổng hợp trạng thái test tự động.
• Biết cách tổng hợp số liệu bug từ Redmine hoặc Google Sheet vào báo cáo.

─── NỘI DUNG CHÍNH

▸ 1. Các thông tin cần có trong báo cáo

Một báo cáo cơ bản gồm: tổng số test case (ví dụ 300), số đã thực hiện và số còn lại; số bug đã tìm thấy (ví dụ 50), số bug đã xử lý (ví dụ 30) và số còn lại (20). Kèm theo là một nhận định chất lượng — sản phẩm đang tốt hay chưa tốt, có xu hướng lỗi logic tập trung ở một số màn hình nào không.

▸ 2. Báo cáo theo giai đoạn, đừng đợi tới cuối

Nếu có 300 test case mà đợi làm xong hết mới báo cáo thì quá muộn. Nên báo cáo mỗi ngày, hoặc theo từng cụm màn hình / cụm tính năng logic, tùy cách bạn phân chia.

▸ 3. Tổng hợp trạng thái bằng COUNTIF và INDIRECT

Từ các trạng thái đã điền trong file test case, bạn tạo một sheet summary. Dùng hàm COUNTIF để đếm số test case theo từng trạng thái (ví dụ đếm trạng thái NG). Để công thức chạy động theo tên sheet, kết hợp hàm INDIRECT với ô chứa sheet name — chỉ cần điền tên sheet là bảng tự tổng hợp status của từng sheet.

▸ 4. Tổng hợp số liệu bug

Với số lượng bug (tổng, đã fix, còn lại), bạn lên Redmine hoặc file Google Sheet để tổng hợp trạng thái. Ví dụ tạo hai bug, một cái để resolved một cái vẫn new, thì suy ra tổng số bug là hai, đã xong một, còn lại một. Cuối cùng lập một bảng tính để ra báo cáo. Lưu ý mẫu báo cáo cụ thể còn tùy theo quy trình của công ty và dự án.

Chương 7 · Bài 8

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

Bài học tổng kết chương Unit Testing, hệ thống lại toàn bộ những gì đã học: từ lý thuyết Unit Testing, cách log bug, làm báo cáo, cho tới Point Of View (POV). Điểm mấu chốt: nhắc bạn ghi nhớ Unit Test là kiểm thử ở đơn vị nhỏ nhất, và chia sẻ một kinh nghiệm thực chiến — cách ứng dụng POV vào dự án gấp, thiếu tài liệu bằng cách biến POV thành checklist rồi test luôn.

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

• Hệ thống lại được toàn bộ kiến thức trọng tâm của chương.
• Nhớ được các cách log bug và các thông tin cần tổng hợp khi báo cáo.
• Biết hướng xử lý khi gặp dự án gấp, không có tài liệu đầy đủ.

─── NỘI DUNG CHÍNH

▸ 1. Ôn lại Unit Testing

Chương này đã đi qua Unit Testing là gì và cách thực hiện. Điều cần khắc cốt: Unit Test là kiểm thử ở đơn vị nhỏ nhất — từng màn hình riêng lẻ. Bạn nên xem lại cả phần lý thuyết lẫn phần thực hành để nắm chắc.

▸ 2. Log bug và báo cáo cho stakeholder

Bài đã demo cách log bug trên nhiều công cụ mà thực tế hay dùng: Excel, Google Sheet, Redmine — thậm chí có công ty dùng cả PowerPoint. Kèm theo là cách làm báo cáo tổng hợp cho các stakeholder khác nhau: team lead nhận báo cáo thế nào, khách hàng nhận báo cáo thế nào, và những thông tin cần tổng hợp.

▸ 3. POV và POV mẫu của SmartITSoft

Bạn đã học Point Of View (POV) là gì, cách dùng POV trong dự án và cách kết hợp POV vào việc viết test case. Giảng viên cũng đã chia sẻ POV mẫu của SmartITSoft để bạn tái sử dụng.

▸ 4. Kinh nghiệm cho dự án gấp

Với dự án gấp, thiếu tài liệu mà vẫn phải giao cho khách hàng nhanh, có một hướng làm rút gọn: không làm đầy đủ POV và test case tách rời, mà biến POV thành checklist rồi test luôn. Giảng viên để sẵn link video tham khảo cho cách làm này. Nếu có chỗ chưa hiểu, bạn có thể vào group khóa học để hỏi trực tiếp.

Chương 8 · Bài 1

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

Bài học mở đầu chương Integration Testing với định nghĩa: đây là loại kiểm thử nhằm kiểm tra các thành phần khác nhau của hệ thống có hoạt động cùng nhau chính xác hay không khi được tích hợp. Điểm mấu chốt cần phân biệt: Unit Test soi đơn vị từng màn hình, còn Integration Test soi flow (luồng) nghiệp vụ chạy qua nhiều màn hình — nó không tập trung vào chi tiết từng màn hình mà chỉ quan tâm luồng nghiệp vụ có đúng không.

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

• Hiểu định nghĩa Integration Testing một cách dễ hình dung.
• Phân biệt rõ "đơn vị màn hình" (Unit) và "flow màn hình" (Integration).
• Nhận ra một dự án ít màn hình vẫn có thể có rất nhiều flow cần test.

─── NỘI DUNG CHÍNH

▸ 1. Định nghĩa Integration Testing

Integration Testing là loại kiểm thử phần mềm nhằm kiểm tra xem các thành phần khác nhau của hệ thống có hoạt động cùng nhau một cách chính xác hay không khi tích hợp. Hiểu đơn giản, đây là việc ghép nhiều unit test lại để chạy thử toàn bộ một luồng.

▸ 2. Test theo flow, không test từng màn hình

Ví dụ luồng đi từ màn hình đăng ký → màn hình danh sách: bạn test nguyên cái flow chạy qua các màn hình đó có đúng không. Cần nhớ hai khái niệm tách bạch: một bên là đơn vị màn hình (Unit Test), một bên là flow màn hình (Integration Test). Integration Test không tập trung vào việc test từng màn hình ra sao, mà chỉ soi luồng nghiệp vụ có chính xác không.

▸ 3. Một dự án — nhiều flow

Một dự án có thể chỉ có 4 màn hình nhưng lại có rất nhiều flow khác nhau đi qua các màn hình đó. Mỗi luồng như vậy chính là đối tượng của Integration Test. Đây là ý nghĩa cốt lõi của Integration Testing. Nếu chưa rõ, bạn có thể tìm thêm từ khóa "integration testing" kèm website của giảng viên để đọc mở rộng.

Chương 8 · Bài 2

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

Bài học giới thiệu khái niệm screen flow (luồng màn hình) — công cụ giúp bạn hình dung nghiệp vụ của dự án đi qua các màn hình như thế nào. Điểm mấu chốt: screen flow là thứ bắt buộc phải làm trước khi viết Integration Test, vì có nắm được luồng thì mới test được luồng. Bài cũng giới thiệu công cụ vẽ miễn phí draw.io và nhấn mạnh tầm quan trọng của mã màn hình khi làm cho thị trường nước ngoài.

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

• Hiểu screen flow là gì và vì sao phải làm trước khi viết Integration Test.
• Biết dùng công cụ draw.io để vẽ luồng màn hình.
• Nắm được tại sao mỗi màn hình cần có mã màn hình (screen code).

─── NỘI DUNG CHÍNH

▸ 1. Screen flow là gì và vì sao quan trọng

Screen flow mô tả luồng nghiệp vụ đi qua các màn hình. Khi làm Integration Testing, bạn phải hình dung được nghiệp vụ chạy ra sao, nên screen flow là bước rất cần thiết — giảng viên còn bắt buộc team làm nó trước tiên khi bắt đầu dự án. Nếu chưa rõ luồng, cả team phải họp lại để cùng tìm cách vẽ ra.

▸ 2. Đọc một screen flow mẫu

Ví dụ một luồng đơn giản: qua màn hình login → màn hình danh sách user → màn hình edit; edit xong quay lại danh sách. Trường hợp xóa thì bấm nút, hiện confirm: nếu xác nhận thì xóa trong database rồi trả về danh sách; nếu không thì quay lại danh sách. Các khối hình thể hiện màn hình, còn khối rẽ nhánh thể hiện quyết định (điều kiện).

▸ 3. Vẽ bằng công cụ draw.io

draw.io là công cụ online miễn phí để vẽ flowchart / screen flow. Bạn chọn nơi lưu diagram (Google Drive hoặc thiết bị), chuyển sang layout màu sáng cho dễ nhìn, rồi dùng kho shape phong phú: đặt màn hình đầu tiên, rê chuột kéo mũi tên sang màn hình kế, thêm hình quyết định cho các nhánh yes/no. Vẽ xong có thể export ra nhiều định dạng và share cho khách hàng.

▸ 4. Lưu ý quan trọng: luôn ghi mã màn hình

Điều giảng viên nhấn mạnh nhất: trên mỗi khối phải ghi tên màn hình kèm mã màn hình (ví dụ SCR01). Khi làm cho thị trường nước ngoài, nhất là thị trường Nhật, developer hoặc tester không biết tiếng Nhật sẽ rất khó tra cứu nếu thiếu mã; dùng mã màn hình giúp mọi người dễ tìm và dễ nhớ nhất.

Chương 8 · Bài 3

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

Bài học là phần thực hành tạo screen flow bằng draw.io cho một bài tập gồm các màn hình login, đăng ký, list, delete và edit. Điểm mấu chốt: trước khi vẽ trên máy, hãy phác họa trên giấy để hình dung luồng; luôn đặt mã màn hình lấy từ tài liệu (thiếu thì bổ sung và request); và mỗi luồng nghiệp vụ (tạo user, chỉnh sửa user…) được vẽ thành một flow riêng để sau này viết test case dễ hơn.

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

• Biết quy trình thực hành vẽ một screen flow từ tài liệu dự án.
• Biết gán mã màn hình (SCR01, SCR02…) cho từng màn hình.
• Vẽ được các flow nghiệp vụ cơ bản như tạo user và chỉnh sửa user.

─── NỘI DUNG CHÍNH

▸ 1. Chuẩn bị: phác họa trên giấy trước

Mở draw.io, đặt tên file (ví dụ SCR01 screen flow user), chọn chế độ màu tối hoặc sáng tùy thích. Giảng viên khuyến cáo: trước khi vẽ trên phần mềm, hãy lấy giấy bút phác họa ý tưởng và luồng màn hình — thói quen phác thảo trên giấy trắng giúp hình dung rõ trước khi số hóa.

▸ 2. Đối chiếu tài liệu và gán mã màn hình

Đối chiếu bài tập với tài liệu dự án. Tài liệu có login, danh sách user, chỉnh sửa user nhưng thiếu màn hình đăng ký — khi tài liệu thiếu thì bạn request bổ sung. Gán mã màn hình lấy từ tài liệu: SCR01 login, SCR02 list, SCR03 edit user; các màn hình thêm vào để minh họa như SCR04 (đăng ký), SCR05. Nếu tài liệu chưa có mã thì tự bổ sung.

▸ 3. Vẽ flow số 1 — tạo user

Với vai trò admin: login vào SCR01, sang SCR02 list, bấm nút register để vào SCR04 đăng ký. Tại màn hình đăng ký dùng một khối điều kiện cho hai nhánh: bấm submit thì đăng ký, bấm reset thì quay lại màn hình list. Đó là một flow hoàn chỉnh đi từ login qua list tới dialog xác nhận.

▸ 4. Vẽ flow số 2 — chỉnh sửa user

Tương tự, admin login rồi vào list, nhưng ở đây bấm nút edit để tới SCR03 edit user và nhập thông tin. Đây là ví dụ cơ bản; thực tế luồng có thể ngoằn ngoèo hơn tùy nghiệp vụ dự án. Khi đã dựng được các flow màn hình rõ ràng như vậy, việc viết test case cho Integration Test trở nên dễ dàng hơn nhiều.

Chương 8 · Bài 4

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

Bài học hướng dẫn thực hành viết Integration Test Case (IT) cho bài tập mẫu gồm ba màn hình (login → danh sách user → edit user). Điểm mấu chốt: khác với Unit Test kiểm thử từng màn hình riêng lẻ, IT kiểm thử cả một luồng nghiệp vụ đi qua nhiều màn hình, nên trước khi viết bạn nên vẽ screen flow để nhìn rõ các step.

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

• Biết dùng screen flow làm cơ sở để hình dung và viết test case IT.
• Viết được một test case IT theo cấu trúc: mô tả luồng, các step, kết quả mong đợi.
• Phân biệt được xóa vật lý và xóa luận lý khi kiểm tra kết quả trong database.

─── NỘI DUNG CHÍNH

▸ 1. Vẽ screen flow trước khi viết

Kinh nghiệm của giảng viên: trước khi viết IT, hãy vẽ screen flow của bài tập (login → list → edit) để thấy rõ luồng nghiệp vụ đi qua mấy màn hình và mỗi step ra sao. Có luồng rồi mới mở file test case lên viết.

▸ 2. Viết test case theo luồng nghiệp vụ

Mỗi test case IT được đặt tên theo luồng, ví dụ Flow 1 — check luồng login vào màn hình list. Với từng flow, ghi rõ các step tuần tự và kết quả mong đợi:

• Flow 1: đăng nhập thành công → vào màn hình list → search một user tồn tại → click button vào màn hình edit → kết quả: vào được màn hình edit.
• Flow xóa user: đăng nhập → vào list → search → click Delete → xác nhận trên popup → kết quả: xóa được user đã chọn.

Một luồng đơn giản như bài tập này thường chỉ cần khoảng mười đến hai chục test case IT là đủ.

▸ 3. Lưu ý quan trọng: xóa vật lý và xóa luận lý

Khi test chức năng xóa, đừng chỉ nhìn giao diện. Trong thực tế, hệ thống thường xóa luận lý: bật một cờ (ví dụ `is_delete = 1`) để record không hiển thị nhưng vẫn còn trong database, thay vì xóa vật lý (mất hẳn dữ liệu). Các hệ thống lớn như ngân hàng hầu như không xóa vật lý. Vì vậy test case nên ghi rõ bước vào database xác nhận, và việc xóa theo kiểu nào phải bám theo requirement hoặc hỏi khách hàng.

Chương 8 · Bài 5

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

Bài học hướng dẫn cách đọc và thực thi Integration Test Case, đồng thời phân biệt rõ test case và test report. Điểm mấu chốt: khi bạn điền trạng thái test, ngày test và bug ID vào file, nó không còn là test case nữa mà đã trở thành test report.

─── 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.
• Biết cách tổ chức cột để test trên nhiều môi trường mà không duplicate sheet.
• Biết vì sao phải giữ lại bug ID để tracking sau khi bug đã được fix.

─── NỘI DUNG CHÍNH

▸ 1. Từ test case thành test report

Test case chỉ là nội dung mô tả. Khi bạn điền trạng thái test (pass/fail), ngày test, và nếu fail thì log bug lên hệ thống rồi ghi ticket bug ID vào file, thì lúc đó nó trở thành test report. Đây là điểm dễ nhầm mà bạn cần nhớ.

▸ 2. Mẹo quan trọng: test nhiều môi trường thì thêm cột, đừng duplicate sheet

Nhiều người khi test trên nhiều trình duyệt (Chrome, Firefox, Edge...) lại nhân bản (duplicate) sheet cho mỗi môi trường. Đây là cách nên tránh: mỗi lần cập nhật test case, bạn phải sửa lại tất cả sheet. Thay vào đó, hãy thêm cột cho từng môi trường. Với mỗi môi trường chỉ cần ba thông tin:

1. Trạng thái của môi trường đó.
2. Cột note hoặc issue / bug ID 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 thêm cột tester riêng. Cách này giúp dữ liệu không bị duplicate và dễ bảo trì.

▸ 3. Giữ lại bug ID để tracking

Khi bug được fix, bạn deploy và test lại, đánh dấu trạng thái thành OK. Tuy nhiên không xóa bug ID đã ghi. Giữ lại bug ID để sau này trace được: test case nào đã tìm ra bug đó, ngày xưa màn hình từng có lỗi gì. Lý tưởng nhất là trong bug cũng ghi thêm test case ID; nếu không kịp thì tối thiểu phải giữ liên kết qua bug ID ở field tương ứng.

Chương 8 · Bài 6

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

Bài học hướng dẫn log bug của Integration Test lên hệ thống quản lý Redmine. Thao tác cơ bản giống như log bug Unit Test đã học trước đó (tạo ticket, mô tả step by step, tái hiện lỗi), nhưng có hai điểm lưu ý riêng vì IT liên đới nhiều màn hình với nhau.

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

• Biết tạo ticket bug và chọn đúng loại (type) là integration test case.
• Biết mô tả đầy đủ luồng màn hình khi log bug IT.
• Biết cách chuẩn bị và đính kèm test data để người khác tái hiện được bug.

─── NỘI DUNG CHÍNH

▸ 1. Tạo ticket và chọn đúng loại integration test case

Trên project demo, bạn tạo một ticket như bình thường. Điểm khác biệt nằm ở chọn loại (type) cho ticket là integration test case. Các phần còn lại (mô tả step by step, cách tái hiện lỗi) đều làm giống như khi log bug Unit Test.

▸ 2. Mô tả đầy đủ luồng màn hình

Vì IT là sự liên đới giữa các màn hình, khi mô tả ticket bạn phải ghi rõ cả luồng màn hình, ví dụ đi từ màn hình A tới màn hình B. Đẹp nhất là đính kèm test case để người đọc biết luồng đi từ đâu tới đâu. Đây là điểm giúp người fix bug hiểu đúng bối cảnh phát sinh lỗi.

▸ 3. Lưu ý quan trọng: đính kèm test data

Do IT liên đới nhiều màn hình, đôi khi cần một bộ data thì mới tái hiện được ticket. Nếu thiếu bộ data này, người khác không thể dựng lại lỗi. Vì vậy:

• Nếu cần một bộ dữ liệu để test, hãy export ra (ví dụ file CSV) rồi đưa bộ dữ liệu đó lên hệ thống Redmine.
• Nếu không có, phải link tới version / server mà bạn đã test, ghi rõ bản version bao nhiêu để người khác nắm được.

Unit Test cũng cần để ý test data, nhưng với IT thì phần này quan trọng hơn nhiều vì lỗi phụ thuộc vào dữ liệu chạy qua nhiều màn hình.

Chương 8 · Bài 7

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

Bài học hướng dẫn cách làm báo cáo sau khi thực thi xong Integration Test. Báo cáo IT có phần giống báo cáo Unit Test (tổng số lượng, xu hướng bug), nhưng phải bổ sung thêm số liệu về màn hình và luồng nghiệp vụ đã test. Điểm mấu chốt: IT rất quan trọng vì nó phản ánh đúng cách người dùng thật sự sử dụng cả hệ thống.

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

• Biết những số liệu cần đưa vào báo cáo IT: số màn hình, số luồng, tiến độ mỗi luồng.
• Nhận diện được các màn hình "xương sống" hay gây bug liên đới.
• Hiểu vì sao IT quan trọng hơn góc nhìn từng màn hình đơn lẻ của UT.

─── NỘI DUNG CHÍNH

▸ 1. Nội dung cần có trong báo cáo IT

Ngoài tổng số lượng như báo cáo UT, báo cáo IT phải nêu rõ số chức năng, số màn hình và các luồng đã test được. Ví dụ: tổng 20 màn hình, trong đó có 5 luồng nghiệp vụ; báo cáo cho biết flow 1 đã test được bao nhiêu, flow 2 bao nhiêu, kèm xu hướng bug của phần này.

▸ 2. Chú ý các màn hình xương sống

Trong IT thường có một số màn hình mang tính nghiệp vụ chính, là xương sống của hệ thống. Những màn hình này thường bug rất nhiều và làm các màn hình khác bị liên đới bug theo. Sau khi test, bạn phải đưa ra nhận định về các màn hình liên đới đó — đây là phần quan trọng nhất của báo cáo.

▸ 3. Vì sao IT quan trọng

Unit Test chỉ quan trọng ở đơn vị từng màn hình, còn IT bao phủ cả một luồng nghiệp vụ. Người dùng thật không dùng một màn hình đơn lẻ mà dùng cả hệ thống, đi từ màn hình này sang màn hình kia — đó chính là phần mà IT kiểm thử. Về cách trình bày, bạn có thể làm thống kê bằng file sheet hoặc ghi lại bằng text bình thường đều được, miễn phản ánh đủ thông tin.

Chương 8 · Bài 8

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

Bài học tóm tắt chương 8 (Integration Testing) và chia sẻ ba case study thực tế thường gặp. Điểm mấu chốt xuyên suốt: hãy tích hợp liên tục ngay trong quá trình làm, đừng dồn integration test tới cuối dự án — đó là nơi rất nhiều dự án bị "chết".

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

• Hệ thống lại các kỹ năng IT đã học: screen flow, viết test case, log bug, báo cáo.
• Hiểu vì sao tích hợp muộn khiến dự án dễ đổ vỡ.
• Nhận ra sai lầm khi chỉ tập trung UT mà bỏ quên IT.

─── NỘI DUNG CHÍNH

▸ 1. Tóm tắt chương 8

Qua chương này bạn đã học: Integration Testing là gì và cách thực hiện; screen flow và ứng dụng vào dự án; cách log bug, quản lý và phân loại bug; cách làm báo cáo tổng hợp cho stakeholder. Bạn cũng có được template mẫu của integration test case để thực hành; thực tế nên tự xây dựng hoặc tham khảo rồi chỉnh sửa lại template cho phù hợp.

▸ 2. Case study 1 — tích hợp muộn

Nếu dự án có rất nhiều màn hình (thực tế thường vài chục tới vài trăm) mà bạn đợi làm xong hết unit test rồi mới tích hợp tất cả cùng lúc, vấn đề phát sinh sẽ rất khủng khiếp và dự án dễ chết ở giai đoạn IT. Kinh nghiệm: tích hợp liên tục — làm xong vài màn hình là tích hợp ngay, phát sinh vấn đề thì xử lý luôn.

▸ 3. Case study 2 — chỉ tập trung UT

Nhiều người có mindset "UT ok thì chắc chắn IT ok". Thực tế khi tích hợp lại mới lộ ra nhiều vấn đề. Phải focus cả hai: xong UT là integration test luôn. Tối thiểu đảm bảo normal case / happy case chạy được khi tích hợp thì đã rất ổn.

▸ 4. Case study 3 — hiểu sai về lỗi logic

Nếu không tích hợp sớm, bạn sẽ không thấy các bug logic ở cấp độ cả luồng. Ví dụ test xong màn hình login tưởng đã ổn, nhưng khi tích hợp với list user / edit user mới phát sinh lỗi như: đã login mà vào list lại edit được chính user của mình. Những lỗi này chỉ lộ ra khi tích hợp — lý do phải tích hợp liên tục.

Chương 9 · Bài 1 (phần 1)

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

Đây là phần mở đầu chương 9 về đánh giá chất lượng sản phẩm phần mềm. Điểm mấu chốt: cách đánh giá trình bày trong chương này bám theo thị trường gia công (outsourcing) cho Nhật, chỉ mang tính chất tham khảo chứ không phải một chuẩn chung của toàn thế giới.

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

• Hiểu bối cảnh của chương 9: đánh giá chất lượng theo thị trường Nhật.
• Biết rằng đây là tiêu chuẩn tham khảo, không phải chuẩn thế giới bắt buộc.
• Biết cách xác định nên dùng quy chuẩn nào cho công ty của mình.

─── NỘI DUNG CHÍNH

▸ 1. Bối cảnh: đánh giá theo thị trường outsourcing Nhật

Chương 9 hướng dẫn đánh giá chất lượng sản phẩm phần mềm, tập trung vào gia công phần mềm (outsourcing), với thị trường mà giảng viên làm nhiều nhất là thị trường Nhật. Vì vậy cách đánh giá chất lượng ở đây đi theo đặc thù của thị trường Nhật.

▸ 2. Chỉ là tiêu chuẩn tham khảo

Có rất nhiều cách đánh giá chất lượng phần mềm — ví dụ dựa trên độ hài lòng của khách hàng, hoặc theo một quy chuẩn riêng nào đó. Mỗi công ty, mỗi nơi có quy chuẩn khác nhau. Do đó nội dung chương này chỉ mang tính tham khảo; nếu học đủ sâu bạn sẽ thấy không có một chuẩn thế giới nào mà ai cũng áp dụng.

▸ 3. Chọn quy chuẩn phù hợp

Nguyên tắc lựa chọn:

• Nếu công ty của bạn đã có quy chuẩn riêng, hãy focus theo quy chuẩn đó.
• Nếu công ty chưa có quy chuẩn nào, bạn có thể tham khảo quy chuẩn được giới thiệu trong chương này.

Tiêu chí đánh giá chất lượng cuối cùng còn phụ thuộc vào stakeholder, những người liên quan tới dự án, quy chuẩn của công ty và cả khách hàng. Phần chi tiết của từng chỉ số sẽ được giới thiệu ở các bài tiếp theo.

Chương 9 · Bài 1 (phần 2)

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

Bài học giải thích số NORM — bộ chỉ số tiêu chuẩn (số tiêu chuẩn) dùng để đánh giá chất lượng dự án gia công phần mềm. Điểm mấu chốt: mỗi chỉ số đều có một mức trung bình (mức cần đạt) cùng cận trên và cận dưới; khi số đo vượt ra ngoài vùng cho phép thì phải xem xét, đánh giá lại chất lượng.

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

• Hiểu các thuật ngữ nền: LOC, KLOC, UT, IT, UAT, billable / calendar effort.
• Nắm ý nghĩa của 10 metric đánh giá chất lượng dự án.
• Biết đọc cận trên / cận dưới để nhận diện khi chỉ số bất thường.

─── NỘI DUNG CHÍNH

▸ 1. Các thuật ngữ nền

Bài giới thiệu một số định nghĩa cần nhớ: OTC (hợp đồng tính tiền theo tháng) và Fixed price (chốt số tiền, lời ăn lỗ chịu); KLOC là số LOC tính theo 1000 dòng; UT / IT là unit test / integration test; UAT là kiểm thử chấp nhận của khách hàng; bug được phân theo UT bug, IT bug, UAT bug. Về effort có billable effort (số khách hàng trả) và calendar effort (số người thực tế bố trí), dùng để đo hiệu quả sử dụng nguồn lực; CDET là phiếu khảo sát độ hài lòng khách hàng.

▸ 2. Mười metric đánh giá chất lượng

Tiêu chuẩn chất lượng dự án gồm khoảng 10 chỉ số, áp cho cả dự án Fixed price và OTC (chỉ khác hệ số): Code Review, UTC Density (unit test case density), UT Bug Density, ITC Density, IT Bug Density, Acceptance Test Bug Rate, CDET Point, Efficiency và Timeline. Mỗi chỉ số được đo trên nền 1000 LOC hoặc trên đơn vị tương ứng.

▸ 3. Cách đọc cận trên, cận dưới (Control Limit)

Mỗi chỉ số có Upper Control Limit (cận trên) và Lower Control Limit (cận dưới), với mức trung bình là mức cần đạt. Ví dụ với Code Review, mức cho phép quanh 15 bug / 1000 LOC: review ra quá ít có thể là chất lượng review kém, ra quá nhiều thì source code có vấn đề. Khi một chỉ số vượt ngưỡng cân bằng của số NORM, đó là dấu hiệu phải review và đánh giá lại.

▸ 4. Điều chỉnh theo dự án

Số NORM chỉ là tiêu chuẩn tham khảo theo thị trường Nhật. Tùy tính chất dự án, các chỉ số phải được điều chỉnh và thống nhất ngay khi khởi tạo dự án. Bạn cũng không nhất thiết đánh giá cả 10 chỉ số, mà chọn những chỉ số phù hợp với kỹ thuật và bối cảnh của mình.

Chương 9 · Bài 2

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

Bài học hướng dẫn cách ước tính số lượng Unit Test Case cần viết dựa trên số dòng code (LOC) và số NORM đã học. Điểm mấu chốt: bản chất chỉ là quy tắc tam suất — lấy số LOC nhân với mức trung bình rồi chia cho 1000 là ra số test case dự kiến.

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

• Biết dùng chỉ số density (test case / 1000 LOC) làm cơ sở ước tính.
• Tính được số test case dự kiến theo LOC kế hoạch và theo LOC thực tế.
• Biết đối chiếu số thực tế với cận trên / cận dưới để phát hiện bất thường.

─── NỘI DUNG CHÍNH

▸ 1. Lấy chỉ số density từ số NORM

Từ bảng tiêu chuẩn chất lượng, bạn bóc chỉ số của unit test case density: mức trung bình là bao nhiêu test case trên 1000 LOC, kèm cận trên và cận dưới. Đây là cơ sở để quy đổi cho từng màn hình có số LOC khác nhau.

▸ 2. Quy tắc tam suất theo LOC kế hoạch và LOC thực tế

Với mỗi màn hình, LOC có hai loại: dự kiến (kế hoạch ban đầu) và thực tế (actual) sau khi code xong. Cách tính giống nhau:

1. Lấy số LOC × mức trung bình ÷ 1000 để ra số test case dự kiến.
2. Khi chưa code màn hình nào, ước tính dựa trên LOC kế hoạch.
3. Khi đã code xong, tính lại dựa trên LOC thực tế — đây mới là con số quan trọng để đánh giá.

Số test case bạn thực sự viết ra khi thực thi có thể nhiều hoặc ít hơn con số dự kiến này.

▸ 3. Đối chiếu với cận trên, cận dưới

Sau khi có số test case thực tế, đối chiếu với vùng cho phép quanh mức dự kiến theo LOC thực tế. Nếu số thực tế vẫn nằm trong khoảng cận trên – cận dưới thì ổn; nếu vượt ngưỡng (ví dụ độ chênh quá mức cho phép) thì màn hình đó có vấn đề, cần xem lại. Cuối cùng, việc đánh giá chất lượng luôn dựa trên số thực tế, còn số kế hoạch chỉ mang tính ban đầu.

Chương 9 · Bài 3

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

Bài học hướng dẫn cách ước tính số lượng bug của Unit Test dựa trên số dòng code (LOC), sử dụng chỉ số bug density. Điểm mấu chốt: cách làm hoàn toàn giống bài tính số test case — vẫn là quy tắc tam suất, chỉ đổi đơn vị đo từ test case sang bug.

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

• Biết dùng chỉ số bug density (bug / 1000 LOC) làm cơ sở ước tính.
• Tính được số bug dự kiến theo LOC kế hoạch và theo LOC thực tế.
• Biết đối chiếu số bug thực tế với vùng cho phép để đánh giá chất lượng màn hình.

─── NỘI DUNG CHÍNH

▸ 1. Lấy chỉ số bug density từ số NORM

Thay cho unit test case density ở bài trước, lần này bạn dùng bug density (UT bug): mức trung bình là bao nhiêu bug trên 1000 LOC, kèm cận trên và cận dưới với độ chênh lệch cho phép (ví dụ khoảng 50%). Đây là chỉ số đo bug trên LOC.

▸ 2. Quy tắc tam suất cho bug

Cách tính đồng nhất với bài số test case:

1. Lấy số LOC × mức bug trung bình ÷ 1000 để ra số bug dự kiến.
2. Khi chưa code, ước tính theo LOC kế hoạch; có thể làm tròn (round up / round down) cho gọn.
3. Khi đã code xong, tính lại theo LOC thực tế — đây là con số dùng để đánh giá.

▸ 3. Đối chiếu số bug thực tế với vùng cho phép

Sau khi thực thi test và ghi nhận số bug thực tế, so với mức dự kiến theo LOC thực tế cùng biên độ cho phép. Nếu số bug nằm trong ngưỡng (ví dụ dưới cận trên) thì ổn; nếu vượt xa mức dự kiến thì màn hình đó có khả năng chất lượng có vấn đề, cần xem lại. Tóm lại, cả bài này lẫn bài tính số test case đều dựa trên cùng một quy tắc tam suất, và kết luận về chất lượng luôn căn cứ vào số liệu thực tế chứ không phải con số kế hoạch ban đầu.

Chương 9 · Bài 4

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

Bài học hướng dẫn cách ước lượng số lượng Integration Test Case dựa vào LOC (Line Of Code). Cách tính về bản chất giống bài Unit Test Case, nhưng khác ở điểm mấu chốt: Integration Test là tích hợp, nên bạn tính tổng toàn bộ các màn hình thay vì tính riêng lẻ từng màn hình.

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

• Hiểu vì sao Integration Test Case được tính trên tổng LOC của cả nhóm màn hình.
• Biết cách ước lượng số test case dự kiến từ LOC và mật độ test case (test case density).
• Biết đối chiếu số test case thực tế với cận trên / cận dưới để giải trình khi vượt.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao tính theo tổng thay vì từng màn hình

Khác với Unit Test (tính riêng từng màn hình), Integration Test tích hợp nhiều màn hình lại. Vì vậy khi ước lượng, bạn lấy tổng LOC của toàn bộ các màn hình liên quan, chứ không tách rời từng cái. Đây là điểm khác biệt quan trọng nhất cần nhớ ở phần IT.

▸ 2. Công thức ước lượng test case theo LOC

Nguyên tắc: lấy tổng số LOC nhân với mật độ test case trung bình (integration test case density) rồi chia cho 1000 (vì mật độ tính trên mỗi 1000 LOC). Kết quả cho ra số test case dự kiến, bạn làm tròn lên. Có thể ước lượng theo LOC dự kiến (kế hoạch) và LOC thực tế (actual) để có hai mốc so sánh.

▸ 3. So sánh với cận trên và giải trình

Sau khi có số test case ước lượng, bạn xác định cận trên bằng cách nhân với tỷ lệ dao động cho phép (ví dụ +20%). Nếu số test case bạn viết thực tế vượt cận trên, bạn cần giải trình lý do vì sao vượt. Đây là cách kiểm soát để số lượng test case nằm trong vùng hợp lý so với quy mô code.

▸ Mẹo quan trọng: rút theo nhiệm vụ

Trong ví dụ minh họa, giảng viên chỉ dùng 3 màn hình đơn giản để bạn hiểu cách tính. Thực tế, bạn có thể rút theo từng nhiệm vụ (task) để tra ra số lượng cho đúng với phạm vi công việc, thay vì gộp chung tất cả.

Chương 9 · Bài 5

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

Bài học hướng dẫn ước lượng số lượng bug của Integration Test dựa vào LOC (Line Of Code). Cách tính tương tự bài Unit Test nhưng dùng bug density và tính tổng cho toàn bộ màn hình. Điểm mấu chốt: so sánh số bug thực tế với cận trên (upper control limit) và cận dưới (lower control limit) để phát hiện mình đang tìm thiếu hay đủ bug.

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

• Ước lượng số bug dự kiến của Integration Test từ tổng LOC và bug density.
• Xác định lower / upper control limit để biết bug thực tế nằm trong hay ngoài vùng cho phép.
• Áp dụng quy tắc tam suất để quy đổi giữa LOC, test case và bug khi thiếu dữ liệu.

─── NỘI DUNG CHÍNH

▸ 1. Ước lượng bug theo bug density

Bạn lấy tổng LOC nhân với bug density trung bình rồi chia cho 1000 để ra số bug dự kiến. Tính cho cả LOC dự kiến và LOC thực tế (actual). Công thức giống hệt bài Unit Test, chỉ thay hệ số bằng công thức bug của IT và luôn tính tổng các màn hình.

▸ 2. So sánh với cận trên và cận dưới

Từ số bug trung bình, tính lower control limit (nhân với 80%, tức trừ 20%) và upper control limit. Nếu số bug thực tế bạn tìm được thấp hơn cận dưới, rất có thể bạn đang tìm thiếu bug — cần kiểm tra lại hoặc giải thích nguyên nhân. Đây là cách dùng con số để tự soi chất lượng công việc test.

▸ 3. Quy tắc tam suất khi thiếu dữ liệu

Nếu không có LOC mà chỉ có số test case (hoặc ngược lại), bạn dùng quy tắc tam suất để quy đổi. Ví dụ khi biết 1000 LOC tương ứng một số test case và một số bug nhất định, bạn có thể suy ra: từ số test case tính ra số bug, từ số test case suy ra LOC, và từ LOC suy ngược ra số test case cần có. Nhờ đó bạn phát hiện được mình đang thiếu bao nhiêu test case hay bug so với quy mô thật của dự án.

Chương 9 · Bài 6

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

Bài lý thuyết này làm rõ khái niệm bug trong ngành gia công phần mềm và cách bug được phân loại theo từng giai đoạn. Điểm mấu chốt: mọi lỗi đều là bug — kể cả lỗi tài liệu — và trong thực tế, vị trí QC thường đảm nhận cả phần Unit Test ở mức UI dù về lý thuyết đó là việc của developer.

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

• Hiểu định nghĩa "lỗi là bug" và biết bug xuất hiện ở những giai đoạn nào.
• Phân biệt bug theo giai đoạn (coding, review code, UT, IT, ST, UAT) và phân loại mịn hơn.
• Nắm được vai trò thực tế của QC trong luồng design → coding → testing.

─── NỘI DUNG CHÍNH

▸ 1. Mọi lỗi đều là bug, kể cả bug tài liệu

Tất cả những gì là lỗi trong dự án gia công đều được gọi là bug. Ngay cả tài liệu bị sai format hay sai logic cũng là bug tài liệu, và được đo đạc như bug lập trình. Đây là điều đầu tiên cần nhấn mạnh.

▸ 2. Phân loại bug theo giai đoạn

Bug xuất hiện ở nhiều giai đoạn: bug coding, bug review code, bug UT (Unit Test), bug IT (Integration Test), bug ST (System Test), bug UAT (User Acceptance Test). Trong mỗi giai đoạn, người ta còn phân loại mịn hơn — ví dụ bug Unit Test có thể là bug layout, bug logic, hay bug hard code. Khi log bug, bạn phân loại để phục vụ phân tích chất lượng.

▸ 3. Vị trí của QC trong luồng dự án

Dự án gia công đi từ design → coding → testing. QC/tester tập trung ở giai đoạn testing, gồm Unit Test và Integration Test (System Test ít làm hơn). Unit Test có hai dạng: test bằng code và test trên UI (UI testing). QC trong ngành gia công chủ yếu làm UI testing — test trên layout, giao diện — chứ không dùng code để test.

▸ Lưu ý về trách nhiệm Unit Test

Về định nghĩa chuẩn, Unit Test là việc của developer. Nhưng thực tế trong ngành gia công, phần Unit Test mức UI thường bị đẩy xuống cho QC đảm nhận. Vì vậy bạn cần biết để chủ động focus vào phần này khi đi làm.

Chương 9 · Bài 7

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

Bài học hướng dẫn quy trình đánh giá chất lượng sản phẩm dựa vào số NORM. Điểm mấu chốt: bạn thống kê số liệu thực tế, so với số NORM lấy từ Project Plan (không phải NORM của công ty), tìm điểm chênh lệch, rồi nhận định — nhưng luôn kèm quan điểm của người thực hiện trước khi quyết định có cần hành động hay chỉ cần giải trình.

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

• Nắm quy trình 5 bước đánh giá chất lượng theo số NORM.
• Biết vì sao phải lấy số NORM từ Project Plan chứ không phải từ NORM công ty.
• Biết đối chiếu output thực tế với cận trên / cận dưới để phát hiện thừa hoặc thiếu.

─── NỘI DUNG CHÍNH

▸ 1. Quy trình đánh giá theo số NORM

Các bước gồm: thống kê số liệu hiện tại theo các tiêu chí của số NORM; lấy số NORM từ Project Plan; so sánh kế hoạch với thực tế để tìm điểm chênh lệch; nhận định chất lượng theo số NORM; và cuối cùng review lại kèm quan điểm người thực hiện để ra quyết định.

▸ 2. Vì sao lấy số NORM từ Project Plan

Số NORM ban đầu là của công ty, nhưng khi dự án start, cả nhóm họp lại và hiệu chỉnh số NORM đó cho phù hợp, rồi ghi vào Project Plan. Vì vậy khi đánh giá, bạn phải lấy đúng số NORM đã hiệu chỉnh trong Project Plan, chứ không dùng số NORM gốc của công ty.

▸ 3. So sánh output với cận trên / cận dưới

Với mỗi màn hình, bạn so số liệu thực tế (theo actual) với vùng cho phép quanh số NORM: nếu vượt cận trên là dư, nếu dưới cận dưới là thiếu, nằm trong vùng là tạm ổn. Khi làm bảng thống kê, bạn viết công thức IF ELSE để tự động đánh giá thừa / thiếu / ổn cho từng dòng.

▸ Lưu ý: quan điểm của người thực hiện

Con số chỉ là điểm khởi đầu. Nếu một màn hình bị đánh giá "thiếu" nhưng thực chất nghiệp vụ của nó đơn giản nên ít test case / ít bug là hợp lý, người review có thể chấp nhận và bỏ qua, không cần action mà chỉ cần giải trình. Đây chính là bước cuối, giúp việc đánh giá sát thực tế thay vì máy móc theo số.

Chương 9 · Bài 8

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

Bài học hướng dẫn cách đánh giá chất lượng qua việc phân loại bug. Trong quá trình log bug, bạn gắn cho mỗi bug các thuộc tính (loại, màn hình, giai đoạn, nguyên nhân...), rồi thống kê và vẽ chart để tìm ra xu hướng. Điểm mấu chốt: nhìn vào biểu đồ phân bố bug, bạn đọc được cách team đang làm việc hợp lý hay có vấn đề.

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

• Biết những trường thông tin cần gắn cho mỗi bug khi log (QC activity, loại bug, nguyên nhân...).
• Dùng hàm COUNTIF để thống kê số lượng bug theo từng tiêu chí.
• Đọc xu hướng từ chart để nhận xét chất lượng theo giai đoạn và theo nguyên nhân.

─── NỘI DUNG CHÍNH

▸ 1. Phân loại bug khi log

Khi tester hoặc developer log bug, họ xác định các trường như: QC activity, điểm phát hiện, loại bug (defect type), nguyên nhân gây ra bug (category), màn hình... Chính những trường này là cơ sở để về sau thống kê và phân tích bug theo nhiều chiều.

▸ 2. Thống kê bằng COUNTIF và vẽ chart

Cách lập bảng thống kê rất đơn giản: dùng hàm COUNTIF đếm số bug theo từng tiêu chí — ví dụ COUNTIF theo QC activity (Unit Test, Integration Test), theo defect type, theo category — rồi SUM lại và vẽ chart. Mỗi chiều phân tích cho ra một biểu đồ riêng.

▸ 3. Đọc xu hướng để nhận xét chất lượng

Từ chart, bạn đọc xu hướng. Ví dụ nếu bug tập trung nhiều ở giai đoạn Unit Test rồi giảm dần qua Integration Test và các giai đoạn sau, đó là dấu hiệu tốt — bug được bắt sớm. Ngược lại, nếu bug ở Integration Test vẫn cao, chứng tỏ giai đoạn UT có vấn đề. Tương tự, phân tích theo loại bug (layout, logic, hard code) và theo nguyên nhân (careless, misunderstand, performance...) giúp bạn thấy dự án đang yếu ở đâu.

▸ Lưu ý: phân tích trước, nhận xét sau

Trình tự bắt buộc là phân tích và vẽ chart trước, nhận xét xu hướng sau. Việc đọc chart chỉ mới là bước nhận định; các hành động cải thiện cụ thể sẽ được trình bày ở bài tiếp theo.

Chương 9 · Bài 9

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

Sau khi đã phân tích chất lượng (theo số NORM, nguyên tắc 20-80, theo phân loại bug), bài học tổng hợp các phương án cải thiện ứng với từng tình huống thường gặp. Điểm mấu chốt: mỗi loại vấn đề — thiếu/dư test case, thiếu/nhiều bug, khách hàng claim, lỗi logic — có một cách xử lý riêng, và với lỗi khó phải đào tới root cause thay vì fix vội.

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

• Nhận diện các tình huống chất lượng thường gặp và chọn đúng phương án xử lý.
• Biết dùng group review / upper review, 5 why và root cause đúng chỗ.
• Hiểu khi nào cần tổ chức một đợt quality test như một dự án riêng.

─── NỘI DUNG CHÍNH

▸ 1. Vấn đề về test case và bug

Nếu sản phẩm thiếu test case, dư test case, hoặc chất lượng test case chưa tốt, bạn review lại test case để tối ưu — bằng group review (nhiều người) hoặc upper review (người nhiều kinh nghiệm). Nếu thiếu bug, cần bổ sung test case hoặc bổ sung quan điểm test. Nếu quá nhiều bug, phải họp lại điều tra xu hướng, vì có thể bug đang nằm lệch khỏi test case hoặc lan ra nhiều màn hình.

▸ 2. Khách hàng claim và lỗi logic

Khi sản phẩm bị khách hàng claim, dùng phương pháp 5 why để truy nguyên nhân rồi giải quyết bằng root cause. Khi gặp lỗi logic khiến chức năng không chạy, đừng fix ngay — hãy phân tích kỹ nghiệp vụ, làm rõ toàn bộ bức tranh, rồi mới bắt tay sửa.

▸ 3. Quality test khi nội bộ ok nhưng khách hàng chê

Nếu mọi đánh giá nội bộ (số NORM, các mặt khác) đều ok mà khách hàng vẫn thấy chất lượng kém, cần thực hiện quality test. Đây là khái niệm bao trùm nhiều việc: bổ sung quan điểm, bổ sung test case, đổi phương pháp test... Đôi khi phải lập cả một chiến lược quality test quy mô như một dự án mới.

▸ Lưu ý: chọn action phù hợp thực tế

Mục tiêu của các phương án là để bạn biết cách giải thích và ra action phù hợp cho từng tình huống. Thực tế rất đa dạng, nên hãy xem đây là các case study tham khảo và vận dụng linh hoạt.

Chương 9 · Bài 10

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

Bài tổng kết chương, ôn lại toàn bộ kiến thức về số NORM, cách tính test case / bug theo LOC, và đánh giá chất lượng, đồng thời chia sẻ những case study thực tế về các lỗi hay gặp trong ngành gia công phần mềm. Điểm mấu chốt: nhiều lỗi nghiêm trọng lại xuất phát từ những vấn đề rất cơ bản — nhất là "không hiểu nhưng vẫn cứ làm".

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

• Hệ thống lại kiến thức cả chương về số NORM, LOC, test case, bug và cải thiện chất lượng.
• Nhận diện ba nhóm vấn đề chất lượng thường gặp trong dự án gia công.
• Hiểu vì sao tester biết tiếng Nhật là một lợi thế lớn khi kiểm soát chất lượng.

─── NỘI DUNG CHÍNH

▸ 1. Ôn lại kiến thức cả chương

Chương này đã trình bày: số NORM và khái niệm chất lượng dựa trên số NORM; cách tính Unit Test Case và bug theo LOC; cách tính Integration Test Case; đánh giá chất lượng dựa vào số NORM và dựa vào phân loại bug; cùng các phương án cải thiện chất lượng.

▸ 2. Lỗi cơ bản: "không hiểu nhưng vẫn làm"

Một loại lỗi rất nổi tiếng là làm khi chưa hiểu cốt lõi vấn đề. Developer khó nắm hết mọi trường hợp và logic của khách hàng, nên đôi khi chỉ hiểu sơ đã làm; test cũng không ra hết bug vì chỉ phủ được một phần. Với dự án khó về nghiệp vụ, giải pháp là thêm người BA / phân tích, và tester biết tiếng Nhật sẽ đọc tài liệu rõ hơn, kiểm tra chắc hơn.

▸ 3. Hai vấn đề chất lượng hay gặp khác

Thứ nhất, sản phẩm thường chỉ chạy tốt happy case (trường hợp thường), còn ở tình huống phức tạp hoặc exception thì hay lỗi. Thứ hai, vấn đề chất lượng thường bị phát hiện muộn — nội bộ không bắt được, tới gần lúc giao khách mới lộ bug. Nguyên nhân gồm dự án đổ về nhanh, công ty outsource load người không kịp, và tài liệu từ khách hàng ban đầu chưa đầy đủ nên vừa làm vừa hiểu.

▸ Lưu ý: cái khó nằm ở cái cơ bản

Kinh nghiệm rút ra là các vấn đề thực chất không quá phức tạp, nhưng cái khó chính là những điều cơ bản lại không được xử lý triệt để.

Chương 10 · Bài 1

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

Bài học giới thiệu HORENSO — kỹ thuật báo cáo và trao đổi thông tin nền tảng khi làm việc với người Nhật, ghép từ ba từ: HOUKOKU (báo cáo), RENRAKU (liên lạc), SOUDAN (thảo luận). Điểm mấu chốt: HORENSO là giao tiếp hai chiều "cho đi và nhận lại", và quy tắc vàng là tin càng xấu thì báo cáo càng sớm.

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

• Hiểu ba thành phần của HORENSO và vì sao nó quan trọng trong dự án với khách Nhật.
• Biết cách báo cáo đúng chuẩn: trung thực, chủ động, theo format 5W2H, kèm số liệu.
• Nắm những điều cấm kỵ khiến người Nhật không hài lòng khi trao đổi công việc.

─── NỘI DUNG CHÍNH

▸ 1. HOUKOKU — Báo cáo

Báo cáo khi nhận ủy thác và khi hoàn thành công việc. Quy tắc: báo cáo trung thực, tin xấu báo càng sớm, báo cáo trước khi được hỏi (đợi bị hỏi là đã muộn), trình bày theo format 5W2H và luôn có số liệu rõ ràng. Có báo cáo giữa kỳ (việc dài hạn), báo cáo định kỳ (daily, weekly), báo cáo khi hoàn thành sớm/đúng/trễ hạn, và báo cáo ngay khi có rủi ro.

▸ 2. RENRAKU — Liên lạc

Là việc chia sẻ thông tin với người liên quan và phản hồi thông tin nhận được từ khách hàng, team hay stakeholder. Liên lạc tốt là xác định đúng trình tự và phạm vi (ai qua email, ai qua chat), xác nhận mình hiểu đúng, và chủ động, nhanh chóng, đúng đối tượng.

▸ 3. SOUDAN — Thảo luận

Khi gặp vấn đề không tự giải quyết được, hãy tìm ý kiến hỗ trợ, phát huy sức mạnh tập thể để tìm tiếng nói chung. Khi bàn bạc phải tôn trọng ý kiến mọi người, và buổi thảo luận cần có người đủ kinh nghiệm để ra quyết định. Có thể tiến hành qua chat, mail, video meeting hay gặp trực tiếp; nên đưa nhận định và giải pháp của mình trước để mọi người cùng hiểu.

▸ Lưu ý: những điều cấm kỵ với người Nhật

Chậm trễ và lỗi đơn giản đều không được chấp nhận. Báo cáo phải kèm số liệu (ví dụ tiến độ test case 500/1000 = 50%). Tránh nói "tôi không biết" rồi dừng lại — thay vào đó hãy hẹn đi tìm hiểu rồi feedback. Đặc biệt, báo cáo sau khi sự việc đã xảy ra (như nhân viên nghỉ đầu tháng mà cuối tháng mới báo, hoặc đợi trễ deadline mới báo) là điều cấm kỵ.

Chương 10 · Bài 2

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

Bài học giới thiệu bốn loại báo cáo cơ bản trong dự án phần mềm: Daily, Weekly, Monthly và Issue Report. Điểm mấu chốt: với người mới đi làm, Daily Report mỗi ngày là bắt buộc và rất cần thiết — dù dự án không yêu cầu, bạn vẫn nên tự báo cáo để người quản lý biết bạn đã làm gì.

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

• Phân biệt bốn loại báo cáo cơ bản và biết mỗi loại dùng khi nào.
• Hiểu vì sao báo cáo hằng ngày quan trọng với người mới đi làm.
• Biết Issue Report được lập tức thời khi có sự cố phát sinh.

─── NỘI DUNG CHÍNH

▸ 1. Daily Report — Báo cáo hằng ngày

Mỗi ngày bạn báo cáo cho dự án và cho người quản lý trực tiếp. Đừng nghĩ không báo cáo là "sướng" — nếu không báo cáo, người ta không biết bạn đã làm gì trong ngày. Dù team lead không yêu cầu, bạn vẫn nên bỏ ra khoảng 5 phút viết lại nội dung công việc trong ngày rồi post lên nhóm hoặc gửi riêng người giao việc.

▸ 2. Weekly và Monthly Report

Weekly Report rất cần thiết khi giao tiếp với khách hàng: nên thỏa thuận báo cáo hằng tuần để tổng hợp kết quả cả tuần; trong nội bộ team/group cũng nên có buổi báo cáo tuần. Monthly Report (báo cáo tháng) trong dự án phần mềm thường ít làm hơn — chủ yếu vẫn là weekly và daily; nếu có thì đôi khi thành báo cáo quý (3 tháng) hoặc 6 tháng một lần. Cấp quản lý / lãnh đạo cao thường báo cáo theo tuần/tháng thay vì hằng ngày, vì vấn đề của họ không giải quyết trong một ngày.

▸ 3. Issue Report — Báo cáo sự cố

Khi có bất kỳ sự cố phát sinh cần xử lý ngay, bạn lập Issue Report tức thời. Ví dụ: sản phẩm đã go live mà bỗng phát sinh bug ảnh hưởng tiến độ hoặc khiến user không dùng được hệ thống — lúc đó phải làm báo cáo sự cố ngay.

▸ Lưu ý: các báo cáo khác tùy tình huống

Ngoài bốn loại cơ bản, dự án còn có thể có báo cáo phân tích bug, báo cáo chi phí, tiến độ... Những loại này được tạo tùy tình huống, còn bốn loại trên là nền tảng cần nắm.

Chương 10 · Bài 3

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

Bài học hướng dẫn bạn tự tay dựng một template Unit Test Case bằng Excel từ đầu: thiết kế sheet test case, tạo combo box trạng thái, rồi làm một sheet summary thống kê tự động số lượng test case theo từng trạng thái. Điểm mấu chốt: dùng hàm COUNTIF kết hợp INDIRECT để một công thức chạy đúng cho nhiều sheet UTC khác nhau mà không phải sửa tay.

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

• Dựng được template test case với các cột chuẩn: test case ID, tên, precondition, các bước, kết quả, trạng thái, người test, ngày test.
• Tạo combo box trạng thái và một sheet config lưu các giá trị (Not yet, Đang test, OK, Not good, Pending, Cancel).
• Làm sheet summary đếm test case tự động cho từng sheet bằng COUNTIF và INDIRECT.

─── NỘI DUNG CHÍNH

▸ 1. Cấu trúc file test case chuẩn

Một file test case luôn bắt đầu bằng ba sheet quen thuộc: sheet cover (bìa), sheet record of change / history, rồi mới tới sheet test case (UTC). Sheet test case gồm các cột: test case ID (phải duy nhất), tên/nội dung cần check, precondition (điều kiện tiên quyết), các bước thực hiện, kết quả, trạng thái, người test và ngày test.

▸ 2. Tạo trạng thái và combo box

Tạo một sheet riêng (ví dụ sheet 99 config) để liệt kê các trạng thái: Not yet (chưa test), đang test, OK/Pass, Not good/Fail, Pending (tạm hoãn), Cancel (hủy). Giảng viên lưu ý trạng thái tùy tính chất từng dự án, không nhất thiết giống nhau; nhiều nơi bỏ trạng thái "testing" mà dùng "đang đợi feedback". Đặt test case ID theo màn hình, ví dụ SCR01 cho màn hình số 1.

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

Ở sheet summary, copy dải trạng thái theo chiều ngang bằng Transpose. Dùng COUNTIF trên cột trạng thái (cột E) với điều kiện là ô trạng thái tương ứng để đếm. Vấn đề: công thức chỉ chạy đúng cho một sheet. Giải pháp là bọc tên sheet bằng hàm INDIRECT, biến tham chiếu sheet thành biến (ghép chuỗi bằng hai dấu nháy và `&`, cố định cột). Nhờ đó chỉ cần kéo/copy công thức là mỗi dòng tự đếm đúng cho UTC1, UTC2, UTC3…

▸ Mẹo quan trọng: mở rộng sang template Matrix

Cùng cách trên, bạn có thể tạo template dạng Matrix — trông phức tạp hơn nhưng bản chất chỉ là kẻ thêm cột, thêm dòng. Sau khi có template, việc còn lại chỉ là quy định quy tắc đặt tên và bắt đầu viết test case.

Chương 10 · Bài 4

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

Bài học làm lại template Unit Test Case ở bài trước, lần này trên Google Sheets thay vì Excel. Bạn sẽ thấy cách chuyển cùng một cấu trúc test case sang môi trường online, tạo drop-down trạng thái bằng Data validation, rồi dựng sheet summary đếm test case bằng COUNTIF kết hợp INDIRECT — đúng tinh thần như bản Excel nhưng với thao tác đặc thù của Google Sheets.

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

• Dựng được template test case trên Google Sheets với đủ các sheet cover, history, summary và UTC.
• Tạo drop-down list chọn trạng thái bằng Data validation từ một range cho sẵn.
• Thống kê test case tự động cho nhiều sheet bằng COUNTIF và INDIRECT.

─── NỘI DUNG CHÍNH

▸ 1. Dựng cấu trúc file trên Google Sheets

Mở Google Sheets, đổi tên file và tạo bố cục quen thuộc: sheet cover, sheet thứ hai (history), sheet summary, rồi sheet test case (01/UTC). Thêm một sheet 99 config chứa các trạng thái: Not yet, Fixing, OK, Not good, Pending, Cancel. Sheet test case gồm các cột: test case ID, test case name (nội dung check), precondition, các bước thực hiện, kết quả, trạng thái, người, ngày, ghi chú.

▸ 2. Tạo drop-down trạng thái bằng Data validation

Chọn cột trạng thái, vào Data → Data validation → Add rule, chọn kiểu Drop-down (from a range) rồi trỏ tới range trạng thái trong sheet config. Sau khi tạo, mỗi ô trạng thái sẽ có danh sách chọn. Nếu muốn ẩn mũi tên drop-down làm dải màu mờ, chỉnh lại tùy chọn hiển thị arrow. Định dạng và tô màu cho bảng cho dễ đọc, rồi copy nội dung test case mẫu từ file cũ sang.

▸ 3. Sheet summary và hàm đếm

Ở sheet summary, dùng chuột phải Paste special → Transpose để trải dải trạng thái theo hàng ngang. Dùng COUNTIF trên cột E (cột trạng thái) với giá trị điều kiện được cố định cột bằng F4. Để một công thức chạy đúng cho nhiều sheet, duplicate sheet test case thành UTC2 rồi bọc tham chiếu sheet bằng hàm INDIRECT: biến tên sheet thành biến (hai dấu nháy kép ghép với ô tên sheet, ví dụ B5, cố định cột). Nhờ vậy khi giá trị trong UTC2 thay đổi thì số liệu ở summary tự cập nhật theo.

Chương 10 · Bài 5

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

Bài học giới thiệu một công cụ định dạng tài liệu bằng VBA do chính giảng viên viết, dùng để format nhanh file Excel test case cho gọn gàng, chuẩn chỉnh. Điểm mấu chốt: học viên khóa này được cấp quyền dùng miễn phí — chỉ cần tải công cụ từ folder khóa học, cài đặt, và dùng các nút định dạng có sẵn trên menu thay vì canh chỉnh thủ công.

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

• Biết công cụ định dạng tài liệu Excel bằng VBA của SmartITSoft làm được những gì.
• Biết cách tải công cụ từ folder khóa học và cài đặt để dùng miễn phí.
• Biết định dạng nhanh file test case bằng các nút trên menu công cụ.

─── NỘI DUNG CHÍNH

▸ 1. Công cụ định dạng tài liệu bằng VBA

Đây là bộ công cụ format Excel giúp định dạng tài liệu nhanh chóng. Sau khi cài, công cụ xuất hiện ngay trên menu của Excel, gồm nhiều tính năng như: định dạng tài liệu, chỉnh zoom, đưa con trỏ về ô A1, và nhiều thao tác định dạng khác. Mục tiêu là giúp file trông chỉnh chu, thống nhất mà không tốn công canh chỉnh từng chỗ bằng tay.

▸ 2. Cách cài đặt và sử dụng

Trong tài liệu hướng dẫn có sẵn phần cách cài đặt và cách sử dụng từng hàm/tính năng. Giảng viên có một video hướng dẫn riêng demo chi tiết từng nút — vì công cụ có khá nhiều tính năng nên bạn nên xem video đó để nắm hết cách dùng. Trong khóa học, khi bạn cài đặt và truy cập qua web, giảng viên sẽ cấp quyền để bạn dùng công cụ miễn phí.

▸ 3. Tải công cụ từ folder khóa học

File nguồn (source) để tải nằm ở folder công cụ của khóa học. Bạn lên folder đó, tải file định dạng Excel về, và dùng mật khẩu giải nén được cung cấp kèm theo. Sau khi truy cập qua web, giảng viên cấp quyền cho bạn tải và sử dụng công cụ này.

Chương 10 · Bài 6

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

Bài học giới thiệu một công cụ đếm số lượng test case do SmartITSoft xây dựng. Ngoài việc đếm test case, công cụ còn có thể lấy giá trị ở bất kỳ ô nào từ nhiều file khác nhau và gom lại về một chỗ. Điểm mấu chốt: khi bạn quản lý nhiều file test case, thay vì mở từng file cộng tay, công cụ này lấy số liệu tự động — và học viên được dùng miễn phí.

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

• Hiểu công cụ đếm test case của SmartITSoft dùng để làm gì.
• Biết cách lấy giá trị từ nhiều file test case về một bảng tổng hợp.
• Biết cách tải công cụ từ folder khóa học để dùng miễn phí.

─── NỘI DUNG CHÍNH

▸ 1. Công cụ đếm test case làm được gì

Công cụ vừa đếm số lượng test case, vừa có thể lấy giá trị của một ô bất kỳ trong nhiều file khác nhau. Ví dụ khi bạn có bốn file test case, mỗi file chứa một số lượng test case cố định, công cụ giúp gom hết số liệu của cả bốn file về cùng một nơi để nhìn tổng quan.

▸ 2. Cách sử dụng tính năng get data

Dùng tính năng get data của công cụ: bạn khai báo tên sheet cần lấy, chỉ định dòng và cột chứa giá trị, công cụ sẽ quét và lấy hết các giá trị từ những file đó ra cho bạn xem trong một bảng. Nhờ vậy bạn tổng hợp được số lượng test case của nhiều file, nhiều loại chỉ trong một thao tác.

▸ 3. Tải công cụ và xem video giới thiệu

Giảng viên có một video giới thiệu công cụ (truy cập qua link đính kèm) để bạn xem cách dùng trực quan. File công cụ được download miễn phí trong folder của khóa học; khi tham gia khóa, bạn được cấp quyền tải về và sử dụng.

Chương 10 · Bài 7

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

Bài học giới thiệu SQL — ngôn ngữ tiêu chuẩn để truy vấn và thao tác trên các cơ sở dữ liệu quan hệ. Vì hầu hết hệ thống phần mềm đều lưu và xử lý dữ liệu trong database, một Tester rất cần biết SQL để tự kiểm tra dữ liệu. Điểm mấu chốt: SQL là kỹ năng nền, tài liệu học đã rất phổ biến, nên bài này định hướng nguồn tự học hơn là dạy chi tiết từng câu lệnh.

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

• Hiểu SQL là gì và vì sao Tester cần biết SQL khi thao tác với database.
• Biết các nguồn học SQL cơ bản đáng tin cậy để tự học thêm.
• Biết định hướng dùng AI hỗ trợ viết câu query (được nói kỹ ở bài sau).

─── NỘI DUNG CHÍNH

▸ 1. SQL và vai trò với Tester

SQL là ngôn ngữ tiêu chuẩn để truy vấn và thao tác mọi cơ sở dữ liệu quan hệ trong hệ thống phần mềm. Do dữ liệu đều nằm trong database, việc biết SQL giúp Tester tự truy vấn, đối chiếu dữ liệu trong quá trình kiểm thử — một kỹ năng dùng khá nhiều trong role Tester. Vì kiến thức này đã rất phổ biến trên mạng, khóa học không đi sâu chi tiết mà tập trung gợi mở nguồn học.

▸ 2. Các nguồn tự học SQL cơ bản

Giảng viên gợi ý hai nguồn chính:

• W3Schools: vào phần SQL học ở mức cơ bản. Trang giải thích đầy đủ từng khái niệm, cách tạo database, cú pháp truy vấn — rất phù hợp cho người mới.
• YouTube: tìm từ khóa "SQL cơ bản", có rất nhiều người hướng dẫn để bạn tham khảo và học thêm.

▸ 3. Định hướng dùng AI hỗ trợ

Một tip quan trọng được nhắc trước cho bài sau: dùng công cụ AI để học SQL và nhờ AI viết câu query tốt hơn. Hiện nay trong lập trình, người ta dùng AI rất nhiều để gợi ý và tạo ra các câu query hợp lý. Cách hỏi AI để viết query sẽ được hướng dẫn chi tiết ở bài kế tiếp.

Chương 10 · Bài 8

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

Bài học chỉ cách dùng các công cụ AI để giải quyết vấn đề trong công việc và học tập của Tester — từ viết câu SQL query đến sinh test case. Điểm mấu chốt: một prompt tốt phải đủ bốn thành phần (bối cảnh, yêu cầu, định dạng đầu ra, ràng buộc chất lượng); nắm được công thức này, bạn dùng AI để xử lý gần như mọi bài toán chỉ với vài dòng mô tả.

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

• Biết bốn thành phần của một prompt tốt và cách viết prompt hợp lý.
• Dùng AI viết câu SQL query từ mô tả bảng và quan hệ dữ liệu.
• Dùng AI sinh nhanh bộ test case cho một màn hình rồi đưa về Excel / Google Sheets.

─── NỘI DUNG CHÍNH

▸ 1. Vì sao và dùng công cụ AI nào

AI hiện quá phổ biến và giúp giải quyết bài toán nhanh hơn, tốt hơn rất nhiều. Giảng viên chia sẻ bốn công cụ AI hay dùng nhất, sắp theo thứ tự ưu tiên, và cho biết với các bản miễn phí cũng đã đủ dùng cho công việc hằng ngày. Có thể kể tới ChatGPT, Claude, Gemini, AI Studio — bạn dùng con nào cũng cho kết quả tương tự.

▸ 2. Công thức prompt bốn thành phần

Một prompt tốt gồm bốn phần:

1. Bối cảnh: bạn là ai, mục đích là gì.
2. Yêu cầu: bạn muốn AI làm gì, ghi rõ ra.
3. Định dạng đầu ra: trả về dạng danh sách, dạng bảng, đoạn code…
4. Ràng buộc chất lượng: ví dụ dùng từ ngữ đơn giản, dễ hiểu.

▸ 3. Ứng dụng 1 — nhờ AI viết SQL query

Ví dụ: "Tôi là một Tester đang truy cập database, cần select bảng User kết nối với bảng khác (mỗi User có một role duy nhất), viết cho tôi câu SQL, cú pháp đơn giản dễ hiểu." AI sẽ trả về câu query kèm giải thích. Nếu không cần alias / bí danh, bạn yêu cầu bỏ đi để lấy SQL thuần.

▸ 4. Ứng dụng 2 — nhờ AI sinh test case

Với một màn hình cần kiểm thử (ví dụ màn hình login, có thể đính kèm ảnh màn hình), bạn ra prompt yêu cầu "tạo test case dạng bảng gồm các cột…". AI gen ra bộ test case ban đầu, thậm chí nhiều ngôn ngữ khác nhau. Bạn copy kết quả sang Google Sheets hoặc Excel để có bộ test case cơ bản, rồi mô tả prompt kỹ hơn nếu muốn chi tiết hơn.

Chương 10 · Bài 9

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

Bài học tóm tắt lại toàn bộ chương và chia sẻ kinh nghiệm thực chiến khi đi làm. Điểm mấu chốt: ngoài việc hoàn thành công việc, hai thứ quyết định cách bạn được đánh giá là báo cáo kèm số liệu và sự chỉnh chu của file bàn giao — đặc biệt khi làm với khách Nhật, cả nội dung lẫn định dạng và tên file đều được soi kỹ.

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

• Hệ thống lại những gì đã học: HORENSO, template test case, công cụ, SQL và AI.
• Biết cách báo cáo chuyên nghiệp bằng cách luôn kèm số liệu định lượng.
• Biết chú ý sự chỉnh chu của file và quy tắc đặt tên trước khi bàn giao.

─── NỘI DUNG CHÍNH

▸ 1. Nhìn lại những gì đã học

Chương này đã đi qua: kỹ thuật HORENSO (báo cáo kiểu Nhật) và cách áp dụng, các loại báo cáo dự án như daily / weekly report; thao tác dựng template Unit Test Case bằng Excel và Google Sheets; các công cụ của SmartITSoft (đếm số lượng test case, định dạng tài liệu) được tặng miễn phí cho học viên; giới thiệu SQL và cách dùng AI để học và viết query qua prompt hợp lý. Nhiều phần chỉ mang tính gợi mở, bạn nên chủ động tìm hiểu sâu thêm.

▸ 2. Case study: báo cáo phải kèm số liệu

Vấn đề cần chú ý nhất khi đi làm là báo cáo. Đừng chỉ nói "tôi xong rồi" hay "tôi làm được 50%" — người Nhật và cấp trên cần định lượng: bao nhiêu test case, bao nhiêu bug. Luôn báo cáo kèm số liệu đầy đủ để thể hiện tiến độ rõ ràng.

▸ 3. Case study: sự chỉnh chu của file bàn giao

Người ta còn đánh giá qua chính file bạn làm: nó có chỉnh chu không, con trỏ đã đưa về A1 chưa, đã zoom đồng nhất chưa. Ngoài nội dung, phần định dạng cũng phải gọn gàng. Cả tên file cũng quan trọng: phải thống nhất quy tắc đặt tên trước khi gửi sản phẩm cho khách hàng, tránh việc làm ra bảng test case đúng nhưng đặt tên sai.