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é! Show 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.
 3. BỐN BƯỚC KIỂM THỬ PHẦN MỀM CƠ BẢNAgile 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 đó:
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. #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:
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. LƯU Ý VỀ KIỂM THỬ PHI CHỨC NĂNGKhô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! |
