Các bước khi thực hiện testing 1 dự án phần mềm: Thực hiện test

Trong bài trước chúng ta đã tìm hiểu về Testcase. Bài viết này chúng ta sẽ tìm hiểu về quá trình Thực hiện kiểm tra.

1. 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.

2. 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 không 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)

Mặc dù trên lý thuyết là như vậy, tuy nhiên trên thực tế, đôi khi chúng ta phải thực hiện test mà không có tài liệu đầu vào, hay còn gọi là test chay, Test nhằm phát hiện và sửa lỗi được chút nào hay chút ấy. Sau đây là một số chú ý khi thực hiện test trong TH như vậy:

1. Khi nào chấp nhận test chay? Dự án quá gấp, không đủ thời gian cho nhóm phát triển lập tài liệu. Requirements không thể được xác lập rõ ràng

2. Làm gì để test chay có hiệu quả?

• Tích cực, mau chóng trao đổi với nhóm phát triển để nắm bắt được bài toán
• Tham khảo các sản phẩm tương tự, nếu có thể.
• Thống nhất với nhóm phát triển danh sách những vùng trọng tâm cần test
• Tranh thủ tiếp xúc với khách hàng, làm sáng tỏ những nghi vấn về yêu cầu, nghiệp vụ
• Lập checklist cho việc test, nếu kịp
• Tập trung test với cường độ cao
• Thường xuyên review mức độ khẩn cấp các lỗi.
• Làm các báo cáo ngắn và linh hoạt về tình trạng lỗi để thúc đẩy tiến độ fix lỗi.
• Tranh thủ xây dựng và tận dụng các testing checklist sẵn có

3. Test thế nào cho đủ? Càng test càng tìm ra thêm lỗi, nhất là với các hệ thống lớn. Vấn đề không phải là liệu tất cả các lỗi đã được tìm ra chưa, mà là liệu phần mềm đã đủ “tốt” để ngừng test hay chưa? Đó là một quyết định có tính “kinh tế” và là một trong những vấn đề khó nhất của testing. Tìm câu trả lời:

• Khả năng tìm được thêm lỗi nếu tiếp tục test?
• Chi phí cận biên của việc đó?
• Khả năng NSD đụng phải các bug còn sót?
• Hậu quả những bug đó với NSD? Kết luận:
• Không thể có câu trả lời chính xác mang tính công thức cho vấn đề trên
• Kinh nghiệm và cảm nhận cụ thể trong từng dự án, từng phần mềm vẫn là điều then chốt
• Tuy nhiên cần biết cần dành thời gian và nguồn lực cho những test nào trước, theo các cách sau

4. Ưu tiên phân bổ nguồn lực cho:

• Những vùng quan trọng nhất của phần mềm
• Những lỗi dễ xảy ra nhất
• Những lỗi (người dùng) dễ nhìn thấy nhất
• Những vùng phần mềm hay được dùng nhất
• Những vùng có đặc trưng riêng, khác biệt hẳn với các vùng khác của phần mềm.
• Những vùng phần mềm dễ bị ảnh hưởng nhất của các change vừa có (khi regression test).
• Những loại lỗi khó fix nhất
• Những loại lỗi mà tester biết rõ nhất
• Những loại lối mà tester biết lờ mờ nhất
• Positive test trước, negative test sau.

5. Ưu tiên sắp xếp test theo quality dimension:

• Số 1: thường là Function testing, và phải bao quát được busines cycle của hệ thống.
• Số 2: Usability testing, chú ý test GUI, đảm bảo đúng syntax, theo standards và user friendly.
• Số 3: security testing, installation testing, …

6. Chọn lọc các test case hiệu quả:

• Dùng kỹ thuật Equivalence class partitioning, chỉ lấy một vài test case đại diện cho từng class là đủ.
• Dùng kỹ thuật Domain testing, chỉ lấy một số giá trị on và off là đủ.
• Dùng kỹ thuật Loop testing, thì chỉ một số test case cho các trường hợp đi qua vòng lặp 0 lần, 1 lần, 2 lần, x lần và số lần tối đa ± 1 là đủ.
• Tính mức ưu tiên cho mỗi test case bằng cách xây dựng “Test Coverage matrix”
• “Test Coverage matrix” map từng test case vào từng software feature
• Cần ưu tiên những test case có liên quan đến nhiều feature nhất.
• Thống kê hiệu quả của mỗi test case qua thời gian
• Thu thập số liệu về số lỗi mà mỗi test case đem lại theo từng loại phần mềm, từng khoảng thời gian
• Đào thải dần những test case đã “hao mòn hiệu quả”, tìm các test case mới thay thế.
• Đánh giá xác suất lỗi còn tiềm ẩn:- Dựng đồ thị biếu diễn số lượng lỗi đã tìm thấy trong mỗi đơn vị thời gian có thể tạo cho mỗi loại bug một đồ thị dạng này, ví dụ tạo một đồ thị dạng này cho loại lỗi về Security – High Priority)
• Đồ thị đi xuống một cách tương đối ổn định, đạt một tần suất lỗi/đơn vị thời gian tương đối thấp là dấu hiệu tốt

• Dựng đồ thị thống kế số lỗi tìm thấy trong mỗi phiên bản đã release của phần mềm Đồ thị đi xuống một cách tương đối ổn định là dấu hiệu tốt

• So sánh với mức xác suất còn lỗi sau khi release có thể chấp nhận Mức này được xác định một cách định tính, từ nhiều yếu tố mang tính business

7. Lưu kết quả Test trong Test Result và đưa ngay lên Bugtracker 7.1 Test log: Là tài liệu ghi lại theo trật tự thời gian những sự kiện test đã được thực hiện và kết quả. 7.2 Test result report là gì? Là tài liệu báo cáo kết quả thực hiện test.

• Ai làm Test result report? Tester
• Khi nào làm Test result report?
  • Sau khi thực hiện test xong một test item.
  • Sau khi test được một khoảng thời gian nào đó.
  • Sau khi test xong một lượt của toàn hệ thống hay một tiểu hệ thống.
  • Khi cần cung cấp thông tin cho người quản lý dự án
  • Khi Test leader yêu cầu
• Nội dung căn bản của Test result report
  • Giới thiệu tài liệu
  • Giới thiệu các test item mục tiêu
  • Các test case dự kiến thực hiện
  • Các test case đã thực hiện
• Kết quả chi tiết của việc thực hiện từng test case
  • Thống kê tỉ lệ test case được thực hiện và tỉ lệ pass của các test case.
  • Đưa ra các change request
  • Ghi chú về các hiện tượng cần theo dõi thêm 7.3 Test release report là gì? Là tài liệu báo cáo kết quả test của sản phẩm, đánh giá chất lượng sản phẩm đã đủ tốt để release hay chưa?
• Ai làm Test release report? Test leader
• Khi nào làm Test release report?
  • Khi ngừng test một bản sản phẩm
  • Khi cần kết luận sản phẩm có thể được release hay chưa?
  • Nội dung căn bản của Test Release Report
  • Giới thiệu tài liệu
  • Giới thiệu hệ thống được test

8. Khái quát về kết quả test:

• Đánh giá chung về hệ thống được test, kết luận release hoặc không.
• Đánh giá ảnh hường của môi trường kiểm tra
• Các nhận xét khuyến nghị

9. Kết quả test chi tiết

• Các phụ lục: thống kê số lỗi, số test case được thực hiện,…
• Xử lý các vấn đề phát sinh trong quá trình Test

Trên đây là phần tìm hiểu chung về quá trình thực hiện test và đi sâu vào chi tiết về thực hiện test mà không có tài liệu đầu vào. Chúng ta sẽ tìm hiểu về bước Log bug ở bài viết sau