Static testing

1. Static Testing là gì?

• Static testing là hoạt động kiểm tra thủ công (hoặc sử dụng công cụ) các sản phẩm phần mềm mà không cần thực thi chúng.
• Hầu như nó được thực hiện sớm trong vòng đời phát triển phần mềm.
• Có thể thực hiện hoạt động static testing mà không cần máy tính vì sản phẩm có thể được kiểm tra mà không cần thực thi.
• Hầu hết các kỹ thuật kiểm tra tĩnh được sử dụng để kiểm tra bất kỳ dạng tài liệu nào, bao gồm source code, design, models hoặc các tài liệu đặc tả.

2. Lợi ích của Static testing

• Vì Static testing được thực hiện sớm nên nó đưa ra các phản hồi về chất lượng của sản phẩm một cách nhanh chóng.
• Các khiếm khuyết được tìm thấy ở giai đoạn đầu nên giảm chi phí và thời gian phát triển.
• Năng suất công việc có khả năng cao hơn vì effort cho việc chỉnh sửa, làm lại thấp hơn.
• Giảm chi phí và thời gian thực hiện kiểm thử
• Giảm tổn chi phí chất lượng trong suốt vòng đời phần mềm, do ít lỗi hơn trong vòng đời sau hoặc sau khi sản phẩm đã đưa vào vận hành.
• Cải thiện việc giao tiếp giữa các thành viên trong team thông qua quá trình thảo luận, đánh giá.

3. Ưu điểm của Static testing

a. Ưu điểm

So với dynamic, static testing có những đặc điểm vượt trội như:

• Xác định các khuyết điểm sớm hơn
• Tìm thấy lỗi ngay trong work product, thay vì xác định failure gây ra bởi lỗi trong work product khi phần mềm được chạy. Nói dễ hiểu, các lỗi được tìm thấy trong tài liệu là nguyên nhân gốc rễ, gây ra các lỗi chỉ được phát hiện sau khi thực thi phần mềm.
• Nhờ việc tìm thấy lỗi sớm hơn thì chi phí và thời gian tiêu tốn sẽ ít hơn nhiều.
• Có thể cải thiện được tính nhất quán và chất lượng nội bộ của sản phẩm.

b. Các lỗi điển hình được tìm thấy bởi static testing

• Requirement defect: Lỗi về tài liệu yêu cầu, như sự không nhất quán, mơ hồ, mâu thuẫn, thiếu sót, không chính xác và dư thừa trong tài liệu.
• Design defect: Lỗi thiết kế, như thuật toán không hiệu quả, cấu trúc cơ sở dữ liệu, khớp nối cao hay độ liên kết thấp.
• Coding defect: Lỗi code, như các biến có giá trị không xác định, các biến được khai báo nhưng không bao giờ sử dụng, code không thể truy cập, code bị trùng lặp.
• Deviations from standards: Độ lệch so với tiêu chuẩn như thiếu tuân thủ theo các tiêu chuẩn code.
• Incorrect interface specifications: Giao diện không chính xác.
• Security vulnerabilities : Các lỗ hỏng bảo mật, tràn bộ đệm.
• Gaps or inaccuracies: Các lỗ hỏng, không chính xác, xác định thiếu phạm vi ảnh hưởng trong test basic như các test còn thiếu cho một tiêu chí chấp nhận (acceptance criterion).
• Maintainability defect: Lỗi bảo trì, như module hóa không phù hợp, khả năng tái sử dụng kém, code phức tạp khó phân tích và dễ gây ra lỗi mới trong quá trình bảo trì và phát triển.

4. Review process and responsibility

5. Áp dụng các kỹ thuật đánh giá

Adhoc

• Là kỹ thuật thường được sử dụng cần ít sự chuẩn bị, người đánh giá được cung cấp rất ít hoặc không có hướng dẫn để thực hiện.
• Kỹ thuật này phụ thuộc nhiều vào kỹ năng của người đánh giá và có thể dẫn đến nhiều vấn đề trùng lặp được báo cáo bởi nhiều người đánh giá khác nhau.
• Người đánh giá thường sẽ đọc tài liệu một cách tuần tự, xác định và ghi lại các vấn đề phát hiện.

Checklist-based

• Là kỹ thuật đánh giá có hệ thống, theo đó người đánh giá sẽ phát hiện được các vấn đề, lỗi dựa trên danh sách kiểm tra có sẵn khi bắt đầu review.
• Danh sách kiểm tra là một bộ câu hỏi dựa trên các khiếm khuyết tiềm ẩn, có thể xuất phát từ kinh nghiệm.
• Danh sách kiểm tra phải cụ thể và phù hợp với từng sản phẩm, nó luôn được xem xét, cập nhật và duy trì thực hiện thường xuyên.
• Ưu điểm của kỹ thuật này là phạm vi bao phủ có hệ thống các lỗi điển hình và cả những lỗi được tìm thấy ngoài danh sách kiểm tra.

Scenarios and dry runs

• Là kỹ thuật đánh giá dựa trên kịch bản, người đánh giá được cung cấp các hướng dẫn có cấu trúc về các đọc qua tài liệu
• Cách tiếp cận dựa trên kỹ thuật này hỗ trợ cho việc thực hiện "dry runs"- chạy khô trên tài liệu dựa trên kết quả mong muốn.
• So với checklist, scenarios sẽ cung cấp các hướng dẫn về cách xác định các loại lỗi cụ thể hơn.
• Cũng giống như checklist, scenarios hỗ trợ người đánh giá không bị bỏ lỡ các lỗi điển hình và cả lỗi được tìm thấy ngoài danh sách.

Role-based

• Là kỹ thuật đánh giá sản phẩm từ góc độ và vai trò của các stakeholder
• Các vai trò điển hình như các loại end-users ( người dùng cuối có kinh nghiệm, thiếu kinh nghiệm, cao cấp, trẻ em, người già,...) và các vai trò trong tổ chức (quản trị viên người dùng, quản trị viên hệ thống, người kiểm tra hiệu suất,...)

Perspective-based

• Tương tự như role-based, khi áp dụng đánh giá dựa trên quan điểm, người đánh giá đảm nhận các quan điểm của các stakeholders khác nhau.
• Quan điểm của các bên liên quan điển hình như end-users, marketing, designer, tester.
• Sử dụng các quan điểm của các stakeholders khác nhau giúp cho việc đánh giá sâu sắc và ít gặp vấn đề trùng lặp giữa các reviewers.
• Kỹ thuật dựa trên quan điểm, yêu cầu người đánh giá phải cố gắng sử dụng tài liệu đang được đánh giá để hình thành sản phẩm. Ví dụ như reviewer sẽ đưa ra các kết quả mong muốn khi đọc tài liệu về một yêu cầu đặc tả để xem nó có bao gồm tất cả các thông tin cần thiết hay không.
• Checklist về kết quả mong muốn cũng được sử dụng trong kỹ thuật này.

Tham khảo:

• http://tryqa.com/what-is-static-testing/
• https://www.istqb.org/downloads/category/2-foundation-level-documents.html