NẮM VỮNG 4 BƯỚC KIỂM THỬ PHẦN MỀM CƠ BẢN

21/07/2021 49
4 buoc kiem thu phan mem co ban 2
CO-WELL Asia TESTING

Quy trình và các phương pháp quản lý dự án đóng vai trò rất quan trọng trong một dự án thành công. Trong nhiều trường hợp, bạn có thể tìm được một người hoàn hảo cho vị trí trong team, nhưng điều đó cũng sẽ không còn quan trọng nữa nếu người đó không có một quy trình xử lý tối ưu để quản lý công việc. Trong bài viết này, hãy cùng tìm hiểu 4 bước kiểm thử cơ bản trong một quy trình kiểm thử phần mềm nhé!

1. KIỂM THỬ PHẦN MỀM LÀ GÌ?

Có rất nhiều cách hiểu về Kiểm thử phần mềm. Hiểu một cách đơn giản thì Kiểm thử phần mềm (Test) là quá trình thực hiện một chương trình hay ứng dụng nào đó với mục đích tìm kiếm lỗi. Nói một cách hoa mỹ hơn. thì Kiểm thử phần mềm là quá trình xét duyệt một sản phẩm phần mềm có đạt đủ các yêu cầu về thương mại và kỹ thuật. Kiểm thử là con đường chính để kiểm định sản phẩm bạn làm ra đã đạt đủ những yêu cầu cần thiết.

Dù sử dụng bất kỳ phương pháp quản lý dự án nào, bạn cũng cần phải lên kế hoạch để thực hiện test cẩn thận cho sản phẩm. Test giúp bạn đảm bảo sản phẩm cuối cùng được vận hành đúng như mong muốn, đồng thời giảm thiểu các lỗi xảy ra sau này gây ảnh hưởng tới tài chính, danh tiếng và đôi khi là vi phạm quy định.

2. NHỮNG AI SẼ THAM GIA KIỂM THỬ PHẦN MỀM?

Khác với những quan niệm thông thường của nhiều người rằng Kiểm thử phần mềm là công việc của vị trí QA/Tester, đây là một công việc đòi hỏi sự tham gia của tất cả thành viên trong dự án. Chỉ một giai đoạn Testing dù chất lượng cũng không thể tìm kiếm hết được các lỗi bug trong sản phẩm.

Kiểm thử phần mềm cần phải trở thành một thói quen, một phần của mọi cuộc trao đổi và task mà nhóm dự án đó thực hiện.

Nếu nhìn theo cách này, mọi người trong dự án đều là những nhân tố then chốt.

  • Dev thực hiện dev testing,
  • PO (product owner) chịu trách nhiệm review copy và thực hiện test trực tiếp,
  • BA thường xuyên phải review yêu cầu của khách hàng,
  • PM và Scrum master sẽ chịu trách nhiệm theo dõi kế hoạch phát triển và có những điều chỉnh về mức độ ưu tiên các task nhằm tối ưu hóa công việc.
  • Tất cả mọi người đều có trách nhiệm thực hiện những hoạt động test bằng cách này hay cách khác.
4 buoc kiem thu phan mem co ban 3
Một vòng đời kiểm thử phần mềm cơ bản

3. BỐN BƯỚC KIỂM THỬ PHẦN MỀM CƠ BẢN

Agile hay Waterfall, Scrum hay RUP, truyền thống hay thử thách, dù dự án phát triển theo cách nào cũng đều có một quy trình nền tảng cho hoạt động kiểm thử phần mềm. Hãy cùng đến với 4 bước kiểm thử phần mềm cơ bản sau đây.

#1 Chiến lược Test và kế hoạch Test (Test Strategy và Test Plan)

Mọi dự án đều cần có chiến lược test và kế hoạch test. Những yếu tố này sẽ mô tả quy mô của phần kiểm thử trong dự án đó:

  • Phần hệ thống cần được test, và các config cụ thể
  • Các tính năng mà dự án tập trung phát triển
  • Các yêu cầu phi chức năng
  • Cách tiến hành test: kiểu truyền thống, kiểu thăm dò, kiểu automation hoặc kết hợp
  • Các quy trình then chốt cần tuân thủ: quy trình xử lý defect, phân loại defect,…
  • Tool sử dụng để log defect, tạo test case, hay để truy vết
  • Các loại tài liệu tham khảo, hoặc tài liệu cần có trong output
  • Các yêu cầu và các cài đặt môi trường test
  • Risks, dependencies và các nguy cơ rủi ro
  • Lịch trình test
  • Workflow cho việc tiếp nhận (approval workflow)
  • Entry/Exit Criteria

Và rất nhiều các yếu tố khác. Dù dự án của bạn đi theo quy trình quản lý nào đi chăng nữa thì Chiến lược test và Kế hoạch test là 2 loại tài liệu không thể thiếu. Chúng có thể được viết độc lập, nhưng cũng có thể gộp lại thành 1 bản tài liệu tổng quát.

Nếu không có hai loại tài liệu này, một dự án khó có thể trở nên hiệu quả được, ngay cả với những phương pháp quản lý linh hoạt như Agile. Lý do là việc tạo lập chiến lược và kế hoạch sẽ giúp bạn nhìn ra những mối tương quan, liên hệ giữa các bên mà bình thường bạn khó mà nhìn thấy được.

Ví dụ: trong một dự án phát triển mobile app, việc xây dựng chiến lược test sẽ giúp bạn xác định rõ hệ điều hành (hdh), phiên bản hdh, loại thiết bị mà bạn cần sử dụng để test app đó.

Có không ít dự án đã phải thay đổi đáng kể các kế hoạch ban đầu do không đầu tư nhiều thời gian vào việc xây dựng chiến lược ban đầu. Kế hoạch test có thể giúp định nghĩa entry và exit criteria nhằm phục vụ test. Điều này rất quan trọng bởi nó có thể điều hướng hoạt động cho toàn bộ team dự án. Nếu sản phẩm đưa ra chưa đạt được đến mức chất lượng yêu cầu thì nó không thể chuyển sang giai đoạn test. Tương tự, nếu đoạn code đã được test không vượt qua yêu cầu chất lượng thì nó sẽ không thể đi tiếp đến các giai đoạn khác của quá trình phát triển phần mềm.

4 buoc kiem thu phan mem co ban 4
Xây dựng Chiếc lược Test và Kế hoạch Test

#2 Thiết kế Test (Test Design)

Công việc tiếp theo cần làm đó là thiết kế một bộ test hoàn chỉnh. Bộ test là tập hợp các test case cần thiết để có thể đối chiếu hệ thống thực tế với những yêu cầu ban đầu của nó.

Bản thiết kế test là sự tập hơn những kinh nghiệm trong nhiều năm của Test manager, sự hiểu biết của tester về hệ thống và các tính năng tương ứng cũng như kinh nghiệm test thực tế. Ví dụ, nếu công ty của bạn đang phát triển sản phẩm mới ở giai đoạn đầu, việc cần được ưu tiên là kiểm tra những lỗi lớn trong các phiên bản alpha/beta, thay vì cố gắng khiến sản phẩm hoàn hảo không có bug.

Trong trường hợp này, bạn có thể sẽ hạn chế các loại kiểm thử tiêu cực (negative testing) mà tập trung nhiều hơn vào kiểm thử thăm dò (exploratory testing) và kiểm thử phá hủy (disruptive testing) để loại bỏ những bug phức tạp và nghiêm trọng. Đồng thời, bạn sẽ không muốn thực hiện những phần kiểm thức chi tiết trước khi sản phẩm của mình có hình hài cụ thể. Vì thế, bộ test ở giai đoạn đầu của vòng phát triển cần tập trung nhiều hơn và kiểm thử những phần nền tảng cơ bản.

Khi sản phẩm đã đủ yêu cầu để đến tay khách hàng. Chúng ta nên thực hiện những phần kiểm thử chuyên môn cao hơn để đảm bảo sản phẩm có ít lỗi nhất có thể, từ đó nâng cao trải nghiệm của khách hàng. Mặc khác, nếu bạn đang test một sản phẩm hay hệ thống đã tồn tại sẵn thì có thể bạn đã có trong tay một bộ test tương đối hoàn chỉnh rồi. Việc cần làm lúc này là đối chiếu bộ test với dự án hiện tại để chỉnh sửa cho phù hợp.

Khi đã có nhiều kinh nghiệm trong việc quản lý các test case, bạn có thể xây dựng một “ngân hàng test” với chất lượng cao, từ đó giảm đáng kể thời gian mà team cần đầu tư vào phần lên kế hoạch và thiết kế.

#3 Triển khai Test (Test Execution)

Bạn có thể thực hiện test theo nhiều cách, ví dụ như là 1 phase SIT (System Integration Test) hay UAT (User Acceptance Test) trong dự án waterfall, hay là 1 phần trong 1 sprint của Agile. Dù bằng cách nào đi chăng nữa, mục đích của cuối cùng vẫn là thực hiện một khối lượng test đủ để đảm bảo hệ thống gần như không còn bug.

Điều đầu tiên chúng ta cần chú ý đó là hiểu rõ môi trường test để có thể quyết định chiến lược test của mình. Lấy ví dụ về dự án phát triển mobile app ở trên, nếu ứng dụng của bạn cần phải liên kết với hệ thống backend lõi để hiển thị thông tin và notification cho khách hàng, thì môi trường test của bạn cần có liên kết với backend để thực hiện được những test case có giá trị. Ngoài ra, cách chúng ta thực hiện test còn phụ thuộc vào nhiều yếu tố như hệ thống cơ sở hạ tầng có sẵn, cấu trúc của team và dự án trong công ty/tổ chức của bạn.

#4 Đóng Test (Test Closure)

Sau khi đã có toàn bộ kế hoạch và tài liệu, thực thi test xong thì đã đến lúc đưa quyết định về sản phẩm đã được test. Bạn cần quan tâm đến những exit criteria để xác định 1 vòng test đã hoàn thành và sẵn sàng cho release. Dưới đây là một số những criteria phổ biến:

  • Test bao phủ 100% yêu cầu: tất cả các yêu cầu về kinh doanh và kỹ thuật đều phải được kiểm thử
  • Tỷ lệ pass tối thiểu: Thường sẽ đặt ở mức đáp ứng 90% test case
  • Tất cả các defect phải được xử lý

Việc định nghĩa các mức đạt yêu cầu đều phụ thuộc vào hoàn cảnh của từng dự án, từng doanh nghiệp và từng ngành nghề khác nhau.

Hãy luôn nhớ rằng, không một ai có thể chấp nhận sản phẩm vẫn còn những defect nghiêm trọng chưa được giải quyết khi đã bàn giao cho khách hàng, đặc biệt là khi sản phẩm đó có chứa thông tin cần bảo mật.

Cuối cùng, chúng ta nên gói gọn lại công việc test trong một bản Báo cáo test và defect. Tài liệu này sẽ cung cấp những số liệu về quá trình test như: có bao nhiêu defect thuộc dạng thấp/trung/cao? Có những tính năng nào bị ảnh hưởng? Phần nào có nhiều defect nhất?…

4 buoc kiem thu phan mem co ban 5
Quy trình quản lí dự án theo Agile

4. LƯU Ý VỀ KIỂM THỬ PHI CHỨC NĂNG

Không khó để tìm kiếm những tài liệu nói về các yêu cầu phi chức năng (Non-functional Requirements Testing), và tầm quan trọng của kiểm thử phi chức năng để dự án đạt hiệu quả và thành công. Việc thực hiện song song kiểm thử chức năng và phi chức năng sẽ giúp team nhìn ra những yêu cầu bổ sung cần có trong test case (ví dụ như: ứng dụng cần hỗ trợ đa ngôn ngữ), hay giúp hoàn thiện kế hoạch test ngay từ đầu để không xảy ra những phát sinh ở giai đoạn sau. Đừng nghĩ kiểm thử phi chức năng như một task phụ phải làm, hãy nghĩ nó như một việc cơ bản mà dự án phải cung cấp cho khách hàng.

Để kết lại, hãy luôn nhớ rằng phương pháp quản lý dự án của bạn không ảnh hưởng tới bất kỳ bước kiểm thử phần mềm nào nêu trên. Ngược lại, tuân thủ theo một quy trình test hiệu quả còn giúp tối ưu hóa hoạt động của cả dự án. Kiểm thử phần mềm chính là một phần nền tảng và cốt lõi của bất kỳ dự án phát triển phần mềm nào.

Đầu tư đúng mức cho kế hoạch test, và bạn sẽ tự tin bàn giao những sản phẩm không bug tới tay khách hàng!


Đọc thêm các bài viết về Kiểm thử phần mềm tại đây.

Follow fanpage CO-WELL Asia để cập nhật các thông tin hữu ích và thú vị.