QUY TRÌNH TỔNG QUÁT CỦA KIỂM THỬ PHẦN MỀM

Kiểm thử thực chất là một quy trình. Quá trình này bắt đầu từ việc lập kế hoạch kiểm thử, sau đó là thiết kế các trường hợp kiểm thử, chuẩn bị cho việc thực thi và đánh giá kết quả thực thi cho đến khi kết thúc hoạt động kiểm thử. Về cơ bản thì gồm các bước sau đây:

  • Lập kế hoạch và kiểm soát việc kiểm thử
  • Phân tích và thiết kế kiểm thử
  • Thực hiện kiểm thử
  • Đánh giá tiêu chí xuất và báo cáo
  • Hoạt động kết thúc kiểm thử

1  Lập kế hoạch và kiểm soát việc kiểm thử

Lập kế hoạch kiểm thử:

  • Xác định phạm vi, rủi ro và xác định những mục tiêu của việc kiểm thử.
  • Thực thi chiến lược kiểm thử.
  • Xác định cách tiếp cận kiểm thử.
  • Xác định những tài nguyên cần cho việc kiểm thử, ví dụ: Máy tính, điện thoại, hệ điều hành Windows 7, Windows 10, MacOS, Android 5.0, 6.0; IOS 12,….
  • Lập lịch thiết kế Test Cases, lịch chạy test và báo cáo Test Report.

Kiểm soát kiểm thử:

  • Đo lường và phân tích kết quả của tiến trình Review và kiểm thử phần mềm.
  • Giám sát và ghi nhận tiến độ kiểm thử, độ bao phủ kiểm thử, tiêu chí xuất để đảm bảo theo đúng kế hoạch đã đề ra trong TestPlan.
  • Cung cấp thông tin về việc kiểm thử đang diễn ra.
  • Đề suất những hành động, biện pháp khắc phục khi việc kiểm thử diễn ra không đúng theo kế hoạch ban đầu.
  • Đưa ra những quyết định điều chỉnh.

2  Phân tích và thiết kế kiểm thử

Hoạt động phân tích và thiết kế kiểm thử có các nhiệm vụ chủ yếu sau đây:

  • Rà soát các yêu cầu cần thiết trước khi tiến hành kiểm thử như tài liệu đặc tả, tài liệu thiết kế, tài liệu giao diện,…….
  • Xác định các điều kiện kiểm thử.
  • Thiết kế Test Cases.
  • Đánh giá tính khả thi trong việc kiểm thử của yêu cầu cũng như của hệ thống.
  • Chuẩn bị môi trường kiểm thử cũng như xác định các yêu cầu về cơ sở hạ tầng và các công cụ kiểm thử tương ứng.

3  Thực hiện kiểm thử

  • Phát triển và thiết lập độ ưu tiên cho các Test Cases: High, Normal, Low.
  • Kiểm tra môi trường kiểm thử xem đã có đầy đủ các thiết lập về hệ thống (Server, Windows, MacOS,…) và có đầy đủ các thiết bị (điện thoại, máy tính, máy tính bảng,..) để chuẩn bị chạy test hay chưa.
  • Tiến hành chạy Test Cases để kiểm thử phần mềm.
  • Tạo file Defect List để lưu kết quả kiểm thử, các lỗi tìm được và chuyển cho Developer sửa lỗi.
  • Tiến hành các hoạt động kiểm thử sau khi Developer sửa lỗi: kiểm thử xác nhận và kiểm thử hồi quy.

4  Đánh giá tiêu chí xuất và báo cáo

Kiểm tra xem kết quả kiểm thử đã đạt được các tiêu chí theo kế hoạch đề ra ban đầu hay chưa (ví dụ: số lượng Test Cases phải chạy và đã chạy được bao nhiêu Test Cases, độ bao phủ câu lệnh, độ bao phủ quyết định được bao nhiêu phần trăm so với kế hoạch đề ra, số lượng các chức năng chính đã kiểm thử, số lượng chức năng chưa được kiểm thử, bao nhiêu trường hợp bị hoãn lại chưa được kiểm thử,…) từ đó xác định việc kiểm thử có nên tiếp tục hay dừng lại để bàn giao phần mềm cho khách hàng.

5  Hoạt động kết thúc kiểm thử

Hoạt động kết thúc kiểm thử bao gồm các hoạt động chủ yếu sau:

  • Kiểm tra việc chuyển giao phần mềm theo kế hoạch của dự án và đảm bảo rằng tất cả các báo cáo sự cố đã được giải quyết, các lỗi đã được fix và đã được kiểm thử xác nhận và kiểm thử hồi quy.
  • Lưu trữ các Testware.
  • Chuyển giao các Testware cho đội ngũ bảo trì.
  • Đánh giá việc kiểm thử đã diễn ra như thế nào (tốt, còn hạn chế, bao phủ hết tất cả các trường hợp hay chưa,…) và phân tích bài học rút ra được từ dự án để cải tiến và làm tốt hơn trong các dự án sau này.
  • Báo cáo thống kê về các kết quả kiểm thử với bộ phận quản lý để đánh giá chất lượng của quá trình kiểm thử cũng như chất lượng của đội ngũ lập trình phần mềm.

Tâm lý kiểm thử

Trong quá trình kiểm thử phần mềm để giúp tạo ra được một phần mềm chất lượng cao, đáp ứng tốt các yêu cầu của khách hàng, Tester có thể xảy ra tranh luận với Developer về những tình huống Tester cho là Bug nhưng Developer lại không chấp nhận đó là Bug. Có thể có những lý do cho trường hợp này như: đặc tả yêu cầu không đầy đủ, hiểu sai yêu cầu, hoặc khách hàng thay đổi yêu cầu nhưng Tester hoặc Developer có một bên chưa cập nhật,…Mặc dù những tranh luận là không thể tránh khỏi, nhưng Tester và Developer cần xem xét những vấn đề dưới đây để cùng nhau đem lại sản phẩm phần mềm tốt nhất cho khách hàng:

  • Tester cần truyền đạt về những lỗi mình đã tìm được một cách trung lập, thực tế mà không chỉ trích người tạo ra lỗi đó, nhìn việc chứ không nhìn người.
  • Giải thích việc tìm và sửa lỗi trong phần mềm là giúp đội phát triển tạo ra sản phẩm phần mềm tốt nhất cho khách hàng, gia tăng uy tín của công ty chứ không phải để chỉ trích.
  • Làm việc với sự hợp tác thay vì tranh cãi. Nhắc nhở mọi người về mục đích chung là cung cấp sản phẩm tốt nhất cho khách hàng. Khi có vấn đề xảy ra thì cả đội nên cùng chung nhau giải quyết để đảm bảo dự án kịp tiến độ chứ không phải thời điểm để chỉ trích hoặc quy trách nhiệm cho cá nhân và khâu nào trong quy trình phát triển phần mềm.

Thực hiện bởi: PLT SOLUTIONS

Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *