Tìm Hiểu Quy trình kiểm tra phần mềm

Đối với một tester hiểu được quy trình kiểm tra phần mền trong quá trình sản xuất phần mền đó là rất cần thiết. Ở đây tôi muốn trình bày về những hiểu biết của mình về quy trình này. có thể tóm lược bằng bản đồ sau:

Ngoài ra cũng có một số mô hình kiểm tra phần mềm khác như:

mô hình V-model:

Mô hình hình tròn:

Mô hình TMM(TESTING MATURITY MODEL):

Chúng ta sẽ đi làm rõ các bước trong sơ đồ được nêu ra đầu tiên:

1. Lập kế hoạch: Sau khi nhận được tài liệu yêu cầu từ phía khách hàng, tùy vào quy mô project, QA sẽ lập plan nhằm chỉ định và mô tả các loại kiểm tra sẽ được triển khai và thực hiện. bản kế hoạch này sẽ chỉ rõ các loại kiểm tra, chiến lược kiểm tra, thời gian và nhân lực. Dựa trên Master plan của DEV, QA sẽ lập ra Master plan để thực hiện từng phần công việc của mình: từ tạo function list đến kết thúc quá trình test. VD đơn giản về plan:

Đối với một project có quy mô nhỏ chỉ cần 1 QA thì việc lập kế hoạch test sẽ do QA đó tự đảm bảo để kịp thời hạn giao sản phẩm, nhưng đối với một project có quy mô lớn thì người quản lí(leader) cần chú ý đến các bước lập kế hoạch:

+Xác định yêu cầu kiểm tra: chỉ định bộ phận, thành phần của phần mềm sẽ được kiểm tra, phạm vi hoặc giới hạn của việc kiểm tra. Yêu cầu kiểm tra cũng được dùng để xác định nhu cầu nhân lực.

+Khảo sát rủi ro: Các rủi ro có khả năng xảy ra làm chậm hoặc cản trở quá trình cũng như chất lượng kiểm tra. Ví dụ: nguyên nhân khách quan(môi trường, thiết bị, internet...), nguyên nhân chủ quan(kinh nghiệm và năng lực của nhân viên...)

+Xác định nhân lực,vật lực: kỹ năng, kinh nghiệm của kiểm tra viên; phần cứng, phần mềm, công cụ, thiết bị giả lập… cần thiết cho việc kiểm tra.

+Lập kế hoạch chi tiết: ước lượng thời gian, khối lượng công việc, xác định chi tiết các phần công việc, người thực hiện, thời gian tất cả các điểm mốc của quá trình kiểm tra.

+Tổng hợp và tạo các bản kế hoạch kiểm tra: kế hoạch chung và kế hoạch chi tiết.

+Xem xét các kế hoạch kiểm tra: phải có sự tham gia của tất cả những người có liên quan, kể cả trưởng dự án và có thể cả khách hàng. Việc xem xét nhằm bảo đảm các kế hoạch là khả thi, cũng như để phát hiện (và sữa chữa sau đó) các sai sót trong các bản kế hoạch.

** 2.Thiết kế test:**

Trước khi nói về việc thiết kế test tôi muốn làm rõ hai khái niệm sau: Test Case và Test Script

★Test case: là một tình huống kiểm tra chức năng của ứng dụng phần mềm hoạt động đúng hay không. Một test case bao thường bao gồm 3 phần:

+Mô tả dữ liệu đầu vào

+Hành động hoặc sự kiện: đối tượng hay dữ liệu cần thiết được sử dụng để thực hiện việc kiểm tra

+Kết quả mong đợi chứng tỏ đối tượng đạt yêu cầu. có một số mẫu test case:

test case đơn giản:kiểm tra hoạt động cơ bản của chức năng lockscreen

Test case yêu cầu chi tiết: VD: cần test độ nhạy về âm thanh và hình ảnh của video có thời gian dài được lưu trong chức năng Gallary:

★Test Script: Khi yêu cầu test tự động thì cần tạo test sript để giúp cho việc kiểm tra nhanh hoặc cho những trường hợp mà kiểm tra bằng tay sẽ rất khó khăn hoặc không khả thi. Các Test Script có thể tạo thủ công hoặc tạo tự động dùng công cụ kiểm tra tự động

★Mục đích của việc thiết kế test: Nhằm chỉ định các Test Case và các bước kiểm tra chi tiết cho phần mềm. Giai đoạn thiết kế test là hết sức quan trọng, nó bảo đảm tất cả các tình huống kiểm và giảm tối thiểu việc bỏ sót các yêu cầu kiểm tra.

★Các bước thiết kế test bao gồm:

• Dựa theo specs để estimate ra số lượng test case cần thiết phải tạo để kiểm tra được đầy đủ chức năng của phần mềm.

• Xác định và chuẩn bị môi trường phục vụ cho quá trình test:Wifi, thẻ, data đặc biệt...

•Viết test case: Mô tả các dự liệu đầu vào như là điều kiện tiền đề, cần mô tả chi tiết các bước trong nội dung kiểm tra. Thao tác này nhằm chi tiết hóa các bước của một test case, chúng bao gồm các loại dữ liệu trực tiếp, gián tiếp, trung gian, hệ thống…Một tese case đầy đủ bao giờ cũng bao gồm 3 phần:

+Điều kiện tiền đề: nêu ra các yếu tố, đối tượng cần chuẩn bị trước khi thực hiện kiểm tra(như thiết bị, môi trường, dữ liệu cần thiết để có thể tiến hành kiểm tra)

+các bước thự hiện test: mô tả chi tiết các bước kiểm tra( làm sao để một người không biết gì khi nhìn vào cũng có thể nắm bắt và thực hiện test được)

+kết quả mong muốn: với những thao tác kiểm tra

• Xem xét và khảo sát độ bao phủ của việc kiểm tra: Cần phải xem xét vào đảm bảo lượng test case tạo ra đã bảo phủ được tôi đa các trường hợp để giảm thiểu đến mức thấp nhất việc xót bug khi kiểm tra phần mềm.

• Kiểm tra Test Case: Sau khi tạo xong test case không chỉ bản thân mà còn có leader, KH review sản phẩm để đảm bảo sản phẩm đạt yêu cầu, đã bao phủ được toàn bộ chức năng. Nếu có sai xót còn chỉnh sửa kịp thời.

3.Phát triển Test Script

Mục đích: Nếu phần mềm cần kiểm tra tự động thì mới cần phải tạo test script do vậy bước này thường không bắt buộc trong các loại mức kiểm tra.

Các bước phát triển Test Script bao gồm:

• Tạo Test Script: có thể tự viết hoặc dùng công cụ hỗ trợ để tạo script một cách tự động. Tuy nhiên hầu như ta vẫn phải chỉnh sửa ít hoặc nhiều trên các script được sinh tự động để phù hợp với yêu cầu kiểm tra. Thông thường, mỗi bước kiểm tra được thiết kế trong phần thiết kế test, đòi hỏi ít nhất một Test Script. Các Test Script có khả năng tái sử dụng càng nhiều càng tốt để tối ưu hóa công việc.

• Kiểm tra Test script: xem có “chạy” tốt không nhằm bảo đảm các Test Script hoạt động đúng yêu cầu, thể hiện đúng ý đồ của các bước kiểm tra.

• Xem xét và khảo sát độ bao phủ của việc kiểm tra: bảo đảm các Test Script được tạo ra bao phủ toàn bộ các bước kiểm tra theo yêu cầu.

4.Thực hiện kiểm tra:

Mục đích: Thực hiện các bước kiểm tra đã tạo (hoặc thi hành các Test Script nếu tiến hành kiểm tra tự động) và ghi nhận kết quả.

Việc thực hiện kiểm tra được lặp đi lặp lại nhiều lần trong suốt chu trình kiểm tra, đến khi kết quả kiểm tra cho thấy đủ điều kiện để dừng hoặc tạm dừng việc thực hiện.

Quá trình thực hiện kiểm tra thường thông qua các bước sau:

• Thực hiện các bước kiểm tra: có thể thực hiện test bằng tay hay test tự động(nếu có yêu cầu). Để thực hiện kiểm tra, đầu tiên phải chuẩn bị môi trường và các dữ kiện cần thiết để tiến hành kiểm tra(gọi là điều kiện tiền đề). Việc này nhằm bảo đảm tất cả các bộ phận liên quan (như phần cứng, phần mềm, máy chủ, mạng, dữ liệu…) đã được cài đặt và sẵn sàng, trước khi chính thức bắt đầu thực hiện kiểm tra.

• Đánh giá quá trình kiểm tra: giám sát quá trình kiểm tra suôn sẻ đến khi hoàn thành hay bị lỗi, treo và dừng giữa chừng, có cần bổ sung hay sữa chữa gì không để quá trình kiểm tra được tốt hơn.

• Nếu quá trình diễn ra trơn tru, tester hoàn thành chu kỳ kiểm tra và chuyển qua bước “Thẩm định kết quả kiểm tra”

• Nếu quá trình bị lỗi, treo hoặc dừng giữa chừng, kiểm tra viên cần phân tích để xác định nguyên nhân lỗi, sau đó mô tả lỗi đó(log bug) với dev để khắc phục lỗi và lập lại quá trình kiểm tra.

• Thẩm định kết quả kiểm tra: sau khi kết thúc, kết quả kiểm tra cần được xem xét để bảo đảm kết quả nhận được là đáng tin cậy, xác định được đâu là lỗi, đâu k phải là lỗi, mức độ của các lỗi xảy ra. Nếu thực sự lỗi xảy ra do quá trình kiểm tra, sau khi log bug cho dev sửa code và nhận lại sản phẩm để kiểm tra thì cần tiến hành kiểm tra chính lỗi đó và phạm vi các vùng lân cận(VD có lỗi khi sử dụng phím back thì app bị crash, sau khi dev sửa code thì kiểm tra viên không chỉ test lỗi đó mà cần kiểm tra thêm với các phím như home, menu, tăng giảm âm lượng... lỗi có còn xảy ta không)

5.Đánh giá quá trình kiểm tra:

Mục đích: Đánh giá toàn bộ quá trình kiểm tra, bao gồm xem xét và đánh giá kết quả kiểm tra, liệt kê lỗi, chỉ định các yêu cầu thay đổi, và tính toán các số liệu liên quan đến quá trình kiểm tra (chẳng hạn số giờ, thời gian kiểm tra, số lượng lỗi, phân loại lỗi…).

Lưu ý, mục đích của việc đánh giá kết quả kiểm tra ở bước này hoàn toàn khác với bước thẩm định kết quả kiểm tra sau khi hoàn tất một vòng kiểm tra. Đánh giá kết quả kiểm tra ở giai đoạn này mang tính toàn cục và nhằm vào bản thân giá trị của các kết quả kiểm tra.

Việc đánh giá quá trình và kết quả kiểm tra được thực hiện song song với bất kỳ lần kiểm tra nào và chỉ chấm dứt khi quá trình kiểm tra đã hoàn tất.

Đánh giá quá trình kiểm tra thường thông qua các bước sau: • Phân tích kết quả kiểm tra và đề xuất yêu cầu sửa chữa: Chỉ định và đánh giá sự khác biệt giữa kết quả mong chờ và kết quả kiểm tra thực tế, tổng hợp và gửi thông tin yêu cầu sửa chữa đến những người có trách nhiệm trong dự án, lưu trữ để kiểm tra sau đó.

• Đánh giá độ bao phủ: Xác định quá trình kiểm tra có đạt được độ bao phủ yêu cầu hay không, tỷ lệ yêu cầu đã được kiểm tra

• Phân tích lỗi: Đưa ra số liệu phục vụ cho việc cải tiến các qui trình phát triển, giảm sai sót cho các chu kỳ phát triển và kiểm tra sau đó. Ví dụ, tính toán tỷ lệ phát sinh lỗi, xu hướng gây ra lỗi, những lỗi “ngoan cố” hoặc thường xuyên tái xuất hiện.

• Xác định quá trình kiểm tra có đạt yêu cầu hay không: Phân tích đánh giá để xem các Test Case và chiến lược kiểm tra đã thiết kế có bao phủ hết những điểm cần kiểm tra hay không? Kiểm tra có đạt yêu cầu dự án không? Từ những kết quả này, kiểm tra viên có thể sẽ phải thay đổi chiến lược hoặc cách thức kiểm tra.

• Báo cáo tổng hợp: Tổng hợp kết quả các bước ở trên và phải được gửi cho tất cả những người có liên quan.

Tóm lược: Trên đây là tóm tắt các bước cơ bản của một quy trình kiểm tra phần mềm. Tùy theo đặc thù của dự án, loại kiểm tra và mức độ kiểm tra, quy trình kiểm tra trong thực tế có thể chi tiết hơn nhiều, tuy nhiên các bước trên là xương sống của bất kỳ quy trình kiểm tra nào.