日本語
EnglishTỔ CHỨC KIỂM THỬ
① Kiểm thử độc lập
Khi viết một bài văn, rất dễ để có những lỗi chính tả hoặc sai sót trong cách diễn đạt mà chính tác giả khó nhận ra. Vì vậy, để phát hiện lỗi trong văn bản, việc nhờ người khác ngoài tác giả đọc lại là rất hiệu quả. Điều này là vì những lỗi do sự thiếu tự nhiên trong cách diễn đạt hoặc sai sót do giả định có thể dễ dàng được người khác chỉ ra. Cơ chế này tương tự với mối quan hệ giữa nhà phát triển và người kiểm thử trong phát triển phần mềm. Trong phần này, chúng ta sẽ giải thích về các hình thức tổ chức kiểm thử từ góc độ quản lý kiểm thử, lợi ích và thách thức của từng hình thức, cùng với vai trò của người thực hiện kiểm thử độc lập.
Trong công việc kiểm thử của một dự án, có nhiều người tham gia với các vai trò khác nhau. Chủ yếu là người phụ trách kiểm thử thực hiện công việc này, nhưng đôi khi nhà phát triển cũng có thể tham gia kiểm thử. Ngoài ra, người sở hữu hệ thống hoặc người dùng cũng có thể tham gia vào việc kiểm thử. Khi người phụ trách kiểm thử có sự độc lập, việc phát hiện lỗi sẽ trở nên hiệu quả hơn. Ví dụ, nếu chủ sở hữu hệ thống thực hiện kiểm thử, họ có thể xác nhận phần mềm hoạt động như mong muốn; nếu người dùng tham gia kiểm thử, họ có thể đánh giá tính dễ sử dụng và tính khả thi của phần mềm.
Tuy nhiên, khi một người kiểm thử độc lập khác với người phát triển thực hiện kiểm thử, họ sẽ không bị ảnh hưởng bởi các yếu tố tâm lý như định kiến hoặc thiên kiến của nhà phát triển, từ đó có thể kiểm tra mà không bị chi phối bất cứ gì. Thêm vào đó, những nhà kiểm thử độc lập có chuyên môn sẽ tăng động lực cho việc kiểm thử và đánh giá, giúp việc thực hiện trở nên hiệu quả. Tuy nhiên, cần lưu ý rằng độc lập không đồng nghĩa với việc có sự hiểu biết sâu về đối tượng kiểm thử. Ví dụ, nhà phát triển có thể hiểu rõ cấu trúc bên trong của code và do đó có thể tìm ra nhiều lỗi ở trong code.
Hiệu quả của một đội kiểm thử độc lập sẽ khác nhau tùy vào hình thức của đội kiểm thử và mức độ kiểm thử. Do đó, quản lý kiểm thử yêu cầu việc tổ chức một đội kiểm thử có thể phát huy hiệu quả tối đa.
Dưới đây là các mức độ độc lập trong tổ chức kiểm thử, từ thấp đến cao.
Không có người kiểm thử độc lập (Trường hợp nhà phát triển chỉ kiểm thử code của chính mình)
Nhà phát triển hiểu rõ cấu trúc bên trong của phần mềm mình tạo ra hơn bất kỳ ai. Vì vậy, nếu tự mình thực hiện thiết kế kiểm thử, họ có thể phát hiện ra nhiều lỗi. Tuy nhiên, nếu họ hiểu sai thiết kế và tạo ra phần mềm, họ có thể không nhận ra lỗi đó. Ngoài ra, khi nhà phát triển kiểm thử code của chính mình, họ có thể dễ dàng bị ảnh hưởng bởi những định kiến và thiên kiến của bản thân, điều này là một thách thức.
Kiểm thử bởi các thành viên khác trong nhóm dự án (bao gồm cả việc đánh giá và kiểm thử của đồng nghiệp)
Trường hợp này ám chỉ việc các thành viên trong nhóm dự án, ngoài nhóm phát triển, thực hiện kiểm thử, hoặc các nhà phát triển kiểm thử sản phẩm của đồng nghiệp ngoài mình. Những người này là kỹ thuật viên trong cùng một dự án, nên họ hiểu rõ cấu trúc phần mềm và các yêu cầu kỹ thuật, giúp việc phát hiện lỗi trở nên hiệu quả hơn. Tuy nhiên, do bị áp lực về thời gian và chi phí, việc đảm bảo tính độc lập hoàn toàn trong kiểm thử là rất khó khăn.
Đội kiểm thử độc lập trong tổ chức (Đội kiểm thử không thuộc quản lý của dự án)
Trong trường hợp này, việc kiểm thử được thực hiện bởi một đội kiểm thử không phụ thuộc vào dự án mà nhóm phát triển đang thực hiện. Đội này ít bị ảnh hưởng bởi các yếu tố như thời gian và chi phí của dự án, do đó có thể đánh giá chất lượng phần mềm một cách khách quan hơn. Ví dụ, các phòng đảm bảo chất lượng thực hiện việc đánh giá chất lượng theo hình thức này.
Kiểm thử độc lập bởi khách hàng hoặc chuyên gia kỹ thuật
Trong mô hình này, người kiểm thử có thể là đại diện của khách hàng hoặc cộng đồng người dùng được cử đi kiểm thử, hoặc là những chuyên gia có kỹ năng đặc biệt trong một lĩnh vực cụ thể. Kiểm thử từ góc nhìn của người dùng sẽ giúp xác nhận phần mềm có đáp ứng được yêu cầu của khách hàng hay không và ít bị ảnh hưởng bởi dự án. Hơn nữa, khi chuyên gia kỹ thuật kiểm thử trong các lĩnh vực chuyên sâu (ví dụ: kiểm thử tính khả dụng hoặc bảo mật), họ có thể sử dụng các kỹ thuật cao để kiểm tra các yêu cầu chất lượng một cách hiệu quả.
Các nhà kiểm thử độc lập này có thể là thành viên của tổ chức bên ngoài, thực hiện công việc tại chỗ (insourcing) hoặc từ xa (outsourcing). Những người này thuộc các phòng ban khác hoặc công ty bên ngoài chuyên về kiểm thử, và kiểm thử từ góc nhìn khác với nhà phát triển. Tính độc lập này giúp tạo động lực rõ ràng cho việc phát hiện lỗi trong dự án phát triển phần mềm và mang lại hiệu quả cao. Đối với một số mức kiểm thử, việc thực hiện bởi những chuyên gia độc lập là điều nên làm.
Tuy nhiên, việc chỉ giao toàn bộ công việc kiểm thử cho các nhà kiểm thử là không hợp lý. Các nhà phát triển cũng nên tham gia vào việc cải thiện chất lượng sản phẩm. Đặc biệt trong kiểm thử mức độ thấp, kiến thức và kinh nghiệm của nhà phát triển có thể được phát huy hiệu quả. Cách thức tham gia của người kiểm thử sẽ khác nhau tùy theo quy trình phát triển. Trong phương pháp phát triển Waterfall, nhà phát triển sẽ tạo ra các sản phẩm theo từng giai đoạn, trong khi các nhà kiểm thử độc lập sẽ kiểm thử những sản phẩm này với chuyên môn cao. Còn trong phương pháp Agile, vì chỉ tạo ra các sản phẩm tối thiểu, nên người kiểm thử sẽ tham gia như một phần của đội ngũ phát triển. Trong trường hợp này, kiểm thử sẽ được thực hiện sau mỗi chu kỳ, kiểm tra chất lượng theo từng bước và mở rộng tính năng dần dần. Vì vậy, việc hiểu rõ vai trò của nhà kiểm thử theo từng quy trình phát triển là rất quan trọng.
Lợi ích của kiểm thử độc lập
Lợi ích của kiểm thử độc lập là việc kiểm thử từ những góc nhìn và nền tảng kỹ thuật khác nhau sẽ giúp dễ dàng phát hiện ra các loại lỗi khác nhau. Họ cũng có thể kiểm tra các giả định mà các bên liên quan đã đưa ra trong quá trình soạn thảo yêu cầu và triển khai, từ đó phát hiện lỗi sớm. Hơn nữa, những người kiểm thử độc lập không bị ràng buộc bởi cấu trúc bên trong phần mềm và có khả năng chỉ ra các vấn đề từ góc độ của người sử dụng.
Nhược điểm của kiểm thử độc lập
Mặc dù có nhiều lợi ích, nhưng kiểm thử độc lập cũng có những nhược điểm. Nếu thiếu sự hợp tác chặt chẽ với nhóm phát triển, có thể sẽ xảy ra tình trạng chậm trễ trong việc chia sẻ thông tin hoặc thậm chí là xung đột. Ngoài ra, cũng có thể gây ra lo ngại về việc giảm bớt trách nhiệm của nhà phát triển trong việc đảm bảo chất lượng phần mềm. Các nhà kiểm thử có thể bị coi là “nút thắt cổ chai” và là nguyên nhân gây chậm trễ trong việc phát hành sản phẩm. Nếu nhà kiểm thử không có đủ thông tin cần thiết, việc kiểm thử sẽ bị trì hoãn, gây ra nguy cơ tiến độ bị đình trệ.
Giải quyết các thách thức này
Để vượt qua những thách thức này, nhóm phát triển và đội kiểm thử cần hợp tác chặt chẽ và duy trì mối quan hệ làm việc chặt chẽ. Kiểm thử cần được thực hiện từ cả hai góc độ của nhà phát triển và người kiểm thử, và nếu nhà phát triển hoàn toàn không tham gia vào quá trình kiểm thử, điều này có thể dẫn đến việc giảm chất lượng và bỏ qua các lỗi, dẫn đến chậm trễ trong việc phát hành hoặc tổn thất kinh tế. Tính độc lập không có nghĩa là cách biệt về mặt vật lý, mà là cả hai bên đều có mục tiêu chung là phát triển phần mềm chất lượng cao và hợp tác hiệu quả.
Trong phát triển phần mềm, nếu chúng ta tận dụng được lợi ích của kiểm thử độc lập trong khi hiểu và giải quyết được các nhược điểm, thì sẽ tạo ra một quy trình kiểm thử hiệu quả hơn.
② Nhiệm vụ của Quản lý Kiểm thử
Quản lý kiểm thử chịu trách nhiệm toàn bộ quy trình kiểm thử, phát huy khả năng lãnh đạo để giám sát các hoạt động kiểm thử và dẫn dắt dự án đến thành công. Vai trò này có thể được đảm nhận bởi các chuyên gia quản lý kiểm thử, cũng như các quản lý dự án, quản lý phát triển, quản lý đảm bảo chất lượng, và nhiều nhân sự khác.
Nhiệm vụ chính của quản lý kiểm thử là xây dựng kế hoạch kiểm thử cho toàn bộ dự án, giám sát các hoạt động kiểm thử dựa trên kế hoạch đó, và điều chỉnh khi cần thiết. Khi quy mô dự án lớn, để giảm bớt gánh nặng, nhiều nhóm kiểm thử có thể được tổ chức, với mỗi nhóm được lãnh đạo bởi một trưởng nhóm kiểm thử. Trong một số trường hợp, người lãnh đạo có thể được chọn từ các thành viên trong nhóm kiểm thử.
Nhiệm vụ chính của trưởng nhóm kiểm thử bao gồm: xây dựng và đánh giá các chính sách và chiến lược kiểm thử của tổ chức, lập kế hoạch dựa trên hiểu biết về mục tiêu kiểm thử và rủi ro của dự án, tạo và cập nhật tài liệu kế hoạch kiểm thử, điều phối với quản lý dự án và chủ sản phẩm, giám sát và báo cáo tiến độ kiểm thử, thực hiện các điều chỉnh kế hoạch và kiểm soát kiểm thử, v.v. Ngoài ra, còn có các công việc quan trọng khác như hỗ trợ triển khai hệ thống quản lý lỗi, xây dựng môi trường kiểm thử, áp dụng các chỉ số phù hợp, lựa chọn và hỗ trợ sử dụng công cụ, nâng cao kỹ năng và phát triển sự nghiệp cho các thành viên kiểm thử.
Bên cạnh đó, quản lý kiểm thử cần điều chỉnh vai trò của mình theo mô hình vòng đời phát triển phần mềm mà dự án áp dụng. Trong phương pháp phát triển Agile, một số nhiệm vụ sẽ được phân công trong nhóm, và các công việc kiểm thử hàng ngày sẽ do các thành viên trong nhóm đảm nhận. Trong khi đó, trong các tổ chức phát triển lớn, các nhiệm vụ liên quan đến nhiều nhóm hoặc các công việc nhân sự sẽ thường được quản lý kiểm thử bên ngoài tổ chức phát triển đảm nhận, và người đảm nhận vai trò này đôi khi được gọi là huấn luyện viên kiểm thử (Test Coach).
Huấn luyện viên kiểm thử sẽ giúp hỗ trợ sự phối hợp và hiệu quả trong toàn bộ tổ chức, bằng cách phân công các nhân sự có kỹ năng cần thiết từ bên ngoài hoặc dẫn dắt các cuộc họp để điều phối giữa các nhóm. Như vậy, vai trò của quản lý kiểm thử thay đổi linh hoạt tùy thuộc vào quy mô dự án và phương pháp phát triển, nhưng luôn đóng vai trò quan trọng trong việc đảm bảo chất lượng của toàn bộ quy trình kiểm thử.
③ Vai trò của Người phụ trách Kiểm thử
Các hoạt động kiểm thử như phân tích và thiết kế kiểm thử, tự động hóa kiểm thử, và thực hiện các kiểm thử đặc biệt (ví dụ: kiểm thử bảo mật, kiểm thử hiệu suất) lý tưởng là do các kỹ thuật viên chuyên môn trong từng lĩnh vực đảm nhiệm. Dựa trên các cấp độ kiểm thử và các rủi ro về chất lượng phần mềm, đôi khi các thành viên ngoài đội ngũ kiểm thử chuyên trách cũng có thể tham gia kiểm thử. Ví dụ, khi thực hiện kiểm thử hộp trắng trong kiểm thử thành phần hoặc kiểm thử tích hợp, thường sẽ do các nhà phát triển có hiểu biết sâu về cấu trúc bên trong đảm nhận. Ngoài ra, đối với kiểm thử chấp nhận của người dùng hoặc kiểm thử chấp nhận vận hành, những chuyên gia có kinh nghiệm về người sử dụng thực tế hoặc môi trường sử dụng thường sẽ thực hiện. Đối với kiểm thử chấp nhận vận hành, người chịu trách nhiệm có thể là các nhân viên vận hành hoặc quản trị hệ thống.
Các vai trò chính của người phụ trách kiểm thử bao gồm:
・Đánh giá kế hoạch kiểm thử và đóng góp vào việc cải tiến kế hoạch đó.
・Phân tích, đánh giá, và xem xét các yêu cầu, câu chuyện người dùng, tiêu chí chấp nhận, đặc tả, mô hình (cơ sở kiểm thử) để nâng cao khả năng kiểm thử.
・Xác định và tài liệu hóa các điều kiện kiểm thử, thiết lập sự truy xuất giữa các trường hợp kiểm thử, điều kiện kiểm thử, và cơ sở kiểm thử.
・Thiết kế môi trường kiểm thử và thực hiện việc thiết lập, kiểm tra (thường phối hợp với các bộ phận quản trị hệ thống hoặc quản lý mạng).
・Thiết kế và triển khai các trường hợp kiểm thử và thủ tục kiểm thử.
・Tạo và thu thập dữ liệu kiểm thử.
・Lập kế hoạch chi tiết về lịch trình thực hiện kiểm thử.
・Thực hiện các trường hợp kiểm thử, đánh giá kết quả và ghi nhận bất kỳ sự sai lệch nào nếu kết quả không như mong đợi.
・Sử dụng các công cụ thích hợp để tối ưu hóa quy trình kiểm thử.
・Tự động hóa kiểm thử khi cần thiết (đôi khi cần sự hợp tác của các nhà phát triển hoặc chuyên gia tự động hóa kiểm thử).
・Đánh giá các đặc tính phi chức năng như hiệu suất, độ tin cậy, khả năng sử dụng, bảo mật, tính tương thích và khả năng di chuyển.
・Đánh giá các trường hợp kiểm thử do các thành viên khác tạo ra.
Tùy thuộc vào đặc điểm của đối tượng kiểm thử, có thể cần đến kiến thức về thiết kế và thực hiện kiểm thử, cùng với kiến thức về hệ thống đối tượng hoặc kỹ năng chuyên môn trong lĩnh vực kinh doanh. Trong những trường hợp như vậy, sẽ hiệu quả hơn khi có các chuyên gia có kiến thức chuyên sâu về lĩnh vực đó hoặc kỹ năng chuyên môn liên quan đảm nhận vai trò này.
Kế hoạch Kiểm thử
Có người hiểu kế hoạch kiểm thử chỉ đơn giản là một lịch trình được lập dựa trên thời gian hoàn thành dự án. Mặc dù lịch trình là một yếu tố quan trọng trong kế hoạch kiểm thử, nhưng chỉ có lịch trình là không đủ. Trong phần này, sẽ được giải thích rằng kế hoạch kiểm thử không chỉ đơn thuần là việc tạo ra một lịch trình, mà còn phải làm rõ mục tiêu và cân nhắc nhiều yếu tố ràng buộc, từ đó tạo thành một kế hoạch kiểm thử thực sự.
Kế hoạch kiểm thử được xây dựng dựa trên mục tiêu của nó. Chủ yếu có hai loại kế hoạch kiểm thử: Kế hoạch kiểm thử tổng thể và Kế hoạch kiểm thử riêng lẻ. Kế hoạch kiểm thử riêng lẻ có thể được lập cho từng cấp độ kiểm thử (ví dụ như kế hoạch kiểm thử hệ thống hoặc kế hoạch kiểm thử chấp nhận) hoặc theo từng loại kiểm thử (ví dụ như kế hoạch kiểm thử hiệu suất hoặc kế hoạch kiểm thử bảo mật).
Kế hoạch kiểm thử tổng thể là kế hoạch quản lý nhiều cấp độ kiểm thử. Kế hoạch này có thể được trình bày như một tài liệu độc lập hoặc có thể được ghi trong phần của kế hoạch dự án. Trong khi đó, các kế hoạch kiểm thử riêng lẻ thường được xây dựng như các tài liệu độc lập cho mỗi loại kiểm thử.
Các hạng mục kiểm thử
Hạng mục kiểm thử liệt kê những đối tượng sẽ được kiểm thử. Dưới đây là các hạng mục đó:
- Hệ thống
- Hệ con (Sub-system)
- Thành phần (Component)
- Đơn vị (Unit)
- Giao diện giữa các hệ thống
- Giao diện giữa các hệ con
- Giao diện giữa các thành phần
Phạm vi Kiểm thử
Phạm vi kiểm thử ghi rõ các tính năng sẽ được kiểm thử và những tính năng không được kiểm thử. Đối với những tính năng không được kiểm thử, cần phải ghi rõ lý do tại sao chúng không được thực hiện kiểm thử.
Kiểm thử Xác nhận và Kiểm thử Hồi quy
Trong kế hoạch kiểm thử, sẽ ghi rõ các điều kiện để thực hiện kiểm thử xác nhận (Confirmation Test) và kiểm thử hồi quy (Regression Test).
・Kiểm thử xác nhận: Kiểm thử này xác nhận rằng các thay đổi đã được thực hiện đúng và phần mềm hoạt động như mong đợi.
・Kiểm thử hồi quy: Kiểm thử hồi quy thực hiện sau khi có thay đổi trong phần mềm, để đảm bảo rằng các thay đổi không ảnh hưởng đến các phần khác của hệ thống.
Kế hoạch kiểm thử có thể xử lý các kiểm thử này dưới dạng các chu kỳ kiểm thử và định nghĩa các cấp độ kiểm thử hồi quy sẽ được thực hiện sau mỗi thay đổi.
Tiến hóa của nội dung kế hoạch kiểm thử
Kế hoạch kiểm thử không phải là một tài liệu cố định mà được cập nhật và phát triển dần theo sự tiến triển của dự án. Khi dự án tiếp tục, thông tin có thể được bổ sung vào kế hoạch kiểm thử, làm cho nó ngày càng chi tiết hơn. Trong suốt quá trình thực hiện kiểm thử, cần nhận thức được sự thay đổi của các rủi ro và điều chỉnh kế hoạch (ví dụ: điều chỉnh lịch trình kiểm thử) để phản ánh những thay đổi đó.
Kế hoạch kiểm thử trong vòng đời sản phẩm
Kế hoạch kiểm thử là một hoạt động diễn ra liên tục trong suốt vòng đời của sản phẩm. Vòng đời sản phẩm bắt đầu từ giai đoạn phát triển, qua giai đoạn bảo trì, và kết thúc khi sản phẩm bị loại bỏ. Ngay cả trong giai đoạn bảo trì, các hoạt động liên quan đến kế hoạch kiểm thử vẫn tiếp tục được thực hiện để đảm bảo rằng sản phẩm duy trì chất lượng trong suốt thời gian sử dụng.
Các yếu tố cần xem xét khi lập kế hoạch kiểm tra
Khi xây dựng kế hoạch kiểm tra, cần phải xem xét nhiều yếu tố khác nhau. Ví dụ, các mục sau đây cần được xem xét:
・Chính sách và chiến lược kiểm tra của tổ chức
・Vòng đời phát triển và phương pháp đang áp dụng
・Phạm vi kiểm tra
・Mục tiêu kiểm tra
・Rủi ro
・Các yếu tố hạn chế
・Tầm quan trọng và ưu tiên
・Độ dễ dàng khi kiểm tra
・Tài nguyên sẵn có
Nếu có các mục kiểm tra được thiết kế tốn nhiều thời gian và công sức, cần phản ánh sự nỗ lực đó vào lịch trình. Hơn nữa, nếu có sự khác biệt về tầm quan trọng hoặc ưu tiên khi thực hiện các mục kiểm tra, lịch trình cũng phải được xây dựng phù hợp.
Hoạt động lập kế hoạch kiểm tra
Trong kế hoạch kiểm tra, các hoạt động sau đây sẽ được thực hiện:
・Xác định phạm vi kiểm tra
・Xác định mục tiêu kiểm tra
・Xác định các rủi ro
・Xem xét và định nghĩa phương pháp tiếp cận kiểm tra
・Xác định các yếu tố sau:
・Cái gì sẽ được kiểm tra
・Các nguồn lực con người và tài nguyên khác cần thiết cho các hoạt động kiểm tra khác nhau
・Cách thức tiến hành các hoạt động kiểm tra
・Lên lịch cho các hoạt động sau:
・Phân tích kiểm tra
・Thiết kế kiểm tra
・Thực hiện kiểm tra
・Thực hiện kiểm tra và đánh giá các tiêu chí hoàn thành
・Chọn các chỉ số (metrics) để giám sát và kiểm soát quá trình kiểm tra
・Xác định các yếu tố liên quan đến tài liệu kiểm tra:
・Mức độ chi tiết của tài liệu kiểm tra
・Các loại tài liệu kiểm tra và cấu trúc của chúng
・Các mẫu tài liệu và tài liệu mẫu sẽ sử dụng
・Xác định ngân sách cho các hoạt động kiểm tra
・Vòng đời phần mềm
※Bài test kiểm tra: