Kiểm thử phần mềm: Các nguyên tắc cơ bản ( Phần 1)

Đây là series tóm tắt từ cuốn sách: FOUNDATIONS OF SOFTWARE TESTING ISTQB CERTIFICATION của tác giả Dorothy Graham, Erik van Veenendaal, Isabel Evans và Rex Black và một số kinh nghiệm của cá nhân trong quá trình làm việc nhằm cung cấp cho các bạn một cái nhìn tổng quan về kiểm thử phần mềm và các kiến thức cơ bản về kiểm thử, các kỹ thuật dùng trong kiểm thử và các công cụ hỗ trợ.

Phần này, mình sẽ giới thiệu các quy tắc của việc kiểm thử: tại sao cần được kiểm thử, mục đích, mục tiêu và các giới hạn của nó là gì, các nguyên tắc phải áp dụng khi kiểm thử, các quy trình mà tester phải làm theo và một số yếu tố tâm lý mà tester cần phải cân nhắc, xem xét trong khi làm việc. Sau khi đọc chương này, mọi người sẽ hiểu rõ hơn các nguyên tắc của việc kiểm thử và có thể mô tả, áp dụng thực tế các nguyên tắc đó.
Trong bài viết lần này, mình sẽ giới thiệu nội dung cơ bản đó là Kiểm thử là gì, sự cần thiết của nó và các nguyên tắc trong kiểm thử .

1. Sự cần thiết của việc kiểm thử.

1.1. Giới thiệu và bối cảnh hệ thống phần mềm

Hệ thống phần mềm là một phần không thể thiếu của cuộc sống, từ các ứng dụng kinh doanh tới các sản phẩm tiêu dùng. Phần mềm không làm việc một cách chính xác có thể dẫn đến nhiều vấn đề bao gồm việc mất tiền, thời gian, uy tín của doanh nghiệp. Vì vậy, cần kiểm tra mọi thứ, bất cứ thứ gì chúng ta tạo ra đều có thể có sai sót. kiểm thử giúp giảm thiểu các lỗi xảy ra trong hệ thống, các rủi ro tiềm ẩn có thể xảy ra.

1.2. Nguyên nhân gây ra lỗi trong các hệ thống phần mềm.

Một số nguyên nhân gây ra lỗi:

• Lỗi từ trong code, hệ thống hoặc trong tài liệu.
• Con người: thiếu kinh nghiệm, không nhận được thông tin đúng, hiểu lầm yêu cầu của hệ thống hoặc là bất cẩn, mệt mỏi, áp lực về thời gian cũng là nguyên nhân gây ra những sai sót, bởi vì những yếu tố đó ảnh hưởng đến khả năng đưa ra quyết định chính xác.
• Kỹ thuật và các quy trình nghiệp vụ phức tạp, code, cơ sở hạ tầng, thay đổi công nghệ hoặc là có nhiều tương tác với hệ thống.
• Ngoài ra, điều kiện môi trường cũng gây ra thất bại đối với một hệ thống phần mềm. ví dụ, từ trường mạnh, điện trường, hoặc ô nhiễm có thể gây ra lỗi trong phần cứng hoặc phần mềm

Vậy thì lỗi phát sinh khi nào?

Trong hình 1.1, chúng ta có thể thấy các defects(khuyết thiếu) có thể phát sinh ở những giai đoạn nào trong 4 yêu cầu đối với một sản phẩm

Hình 1.1. Các loại lỗi (error) và khuyết thiếu (defect).

• Yêu cầu 1: được triển khai chính xác, hiểu yêu cầu của khách hàng, thiết kế chính xác để đáp ứng yêu cầu đó, xây dựng đúng theo thiết kế và cung cấp các yêu cầu đó phù hợp với các thuộc tính: chức năng và phi chức năng.
• Yêu cầu 2: phần mềm được lập trình và khi xuất hiện các lỗi (error) và khuyết thiếu (defect). chúng có thể được tìm thấy và sửa chữa trong giai đoạn kiểm thử.
• Yêu cầu 3: các khuyết thiếu (defect) ở yêu cầu 3 khó xử lý hơn. phần mềm được xây dựng đúng với thiết kế nhưng có những sai sót trong khi thiết kế. Nếu chúng ta không xem lại chi tiết các yêu cầu thì sẽ không thể phát hiện ra những sai sót đó. khi phát hiện ra thì cũng khó sửa chữa vì phải sửa lại từ thiết kế.
• Yêu cầu 4: Nếu chỉ kiểm tra sản phẩm có đáp ứng thiết kế và yêu cầu không thôi thì có thể có những lỗi, sai sót tiềm ẩn. Những lỗi, sai sót mà khách hàng báo cáo trong kiểm thử chấp nhận (acceptance test) hoặc trong khi sử dụng trực tiếp có thể gây ra tổn thất rất lớn.

Chi phí của các khuyết thiếu (defect)

"A stitch in time saves nine" Các bạn có biết câu tục ngữ này có nghĩa là gì không?.
Nó có nghĩa là một mũi khâu đúng lúc thì sẽ tiết kiệm được 9 mũi khâu(xuất phát từ việc nếu 1 người bị lỗ thủng trên áo, nếu khâu vá lại ngay thì sẽ tránh khỏi việc lỗ thủng đấy sẽ bị rách to hơn và cần đến nhiều mũi khâu hơn). Câu nói trên dùng để khuyên mọi người nên xử lý một việc kịp thời, ngay và luôn, vì nếu để càng lâu thì mọi thứ càng rắc rối và mất nhiều thời gian hơn để giải quyết.

Hình 1.2. Chi phí của các lỗi(error), khuyết thiếu(defect).
Ở hình trên ta có thể thấy được những lỗi, sai sót mà được phát hiện ngay từ giai đoạn yêu cầu thì chi phí để tìm và sửa lỗi ở giai đoạn này tương đối ít. Chi phí sẽ tăng lên theo từng giai đoạn phát triển của hệ thống.

1.3. Vai trò của kiểm thử trong phát triển phần mềm, bảo trì và hoạt động.

Lỗi có thể xảy ra ở bất kỳ giai đoạn nào trong vòng đời phát triển của phần mềm. Do vậy kiểm thử rất cần thiết trong quá trình phát triển và bảo trì để xác định các sai sót, lỗi, giảm mức độ thất bại (failed) trong môi trường hoạt động và nâng cao chất lượng của hệ thống vận hành. Kiểm thử giúp tìm lỗi trong giao diện người dùng, dữ liệu đầu vào, giải thích dữ liệu đầu ra và tìm những những lỗi tiềm ẩn.

1.4. Kiểm thử và chất lượng.

Kiểm thử giúp đo lường chất lượng phần mềm dựa vào số lỗi được tìm ra, thực thi kiểm thử và độ bao phủ hệ thống.
Chất lượng là gì?

Theo bảng định nghĩa thuật ngữ của ISTQB thì chất lượng không chỉ bao gồm việc đáp ứng được những yêu cầu đã xác định mà còn đáp ứng cả nhu cầu và mong đợi của người dùng và khách hàng.
kiểm thử và chất lượng có liên quan đến nhau như nào:

• Kiểm thử có thể đo lường chất lượng của phần mềm về các khiếm khuyết được tìm thấy (cả yêu cầu chức năng và phi chức năng) và cả các đặc tính: độ tin cậy, khả năng sử dụng, tính hiệu quả, bảo trì, tính di động.
• Kiểm thử tạo độ tin cậy vào chất lượng của phần mềm nếu tìm thấy rất ít hoặc không có lỗi.
• Cải thiện chất lượng của hệ thống trong tương lai bằng cách rút ra những bài học từ những dự án trước. Hiểu được nguyên nhân gốc của các khiếm khuyết được tìm thấy trong dự án.
• Kiểm thử là một trong những hoạt động đảm bảo chất lượng.

Phân tích nguyên nhân gốc rễ là gì?

Khi phát hiện thấy lỗi, chúng ta sẽ theo dõi xem nó có bị lỗi trở lại hay không và tìm hiểu xem nguyên nhân gây ra lỗi đấy là gì.
Ví dụ: khi máy in của công ty có vấn đề với việc in bị fail nhiều lần.
mọi người mới tìm hiểu các nguyên nhân có thể gây ra lỗi ở máy in. Sau đó nhóm lại để tìm nguyên nhân cơ bản hoặc nguyên nhân gốc rễ của các vấn đề. Một số nguyên nhân tìm thấy có thể là:

• Máy in hết nguồn cung cấp (mực hoặc giấy).
• Phần mềm điều khiển in có vấn đề.
• Phòng để máy in quá nóng trong khi máy in vẫn đang hoạt động.

Nguyên nhân có thể nhìn thấy ngay được là máy in hết nguồn cung cấp( mực, giấy), điều này có thể xảy ra bởi vì:

• Không có ai chịu trách nhiệm kiểm tra giấy và mực trước khi in. Nguyên nhân gốc có thể là không có quy trình kiểm tra mực/ giấy in trước khi sử dụng.
• nhân viên không biết thay hộp mực. Nguyên nhân gốc rễ là nhân viên không được đào tạo hoặc đưa ra hướng dẫ về việc chăm sóc máy in.
• Không có nguồn cung thay thế khi máy in hết mực và giấy. Nguyên nhân gốc rễ là không có quy trình kiểm soát và đặt hàng dự trữ.

Kiểm thử giúp chúng ta phát hiện ra lỗi, những khả năng thất bại đang tiềm ẩn trong quá trình phát triển, bảo trì và hoạt động phần mềm. Tìm được nguyên nhân gốc gây ra lỗi giúp phần mềm giảm nguy cơ thất bại(failed) xảy ra trong môi trường hoạt động và nâng cao chất lượng phần mềm.

1.5. Kiểm thử bao nhiêu là đủ?

Đối với 1 phần mềm, chúng ta không thể nói được rằng nó không còn lỗi nữa, perfect rồi, bàn giao cho khách hàng thôi. Có thể những lỗi các bạn phát hiện ra, fix và ko còn hiển hiện nữa nhưng còn những lỗi tiềm tàng thì sao? Các bạn có chắc chắn rằng mình có thể cover hết được các tình huống có thể xảy ra đối với phần mềm hay không? Câu trả lời là không. Vậy thì kiểm thử như thế nào là đủ? Cái này cũng rất khó có thể xác định.

Ví dụ: trong dự án thực tế ở một màn hình có 15 trường nhập input, mỗi trường có thể có 5 giá trị. sau đó kiểm tra tất cả các giá trị kết hợp đầu vào thì có 30 517 578 125(5^15)trường hợp kiểm tra. Kiểm tra các trường với 1 chữ số với các giá trị 2,3,4 sẽ làm cho các ca kiểm thử được kỹ hơn nhưng nó không cung cấp nhiều thông tin hơn kiểm tra với giá trị 3.
Phụ thuộc vào thời gian và ngân sách chúng ta không thể kiểm tra hết tất cả các trường hợp nêu trên. Thay vào chỉ test giới hạn số lượng testcase.

Một ví dụ nữa về dự án thực tế mà công ty vừa release cho khách hàng. khi đã bàn giao cho khách hàng rồi nhưng hoạt động kiểm thử vẫn tiếp tục được thực hiện và vẫn tìm thấy trong hệ thống còn rất nhiều lỗi.
Kiểm thử bao nhiêu là đủ? chúng ta phải dựa trên việc đánh giá và quản lý rủi ro, bao gồm các rủi ro kỹ thuật và kinh doanh liên quan đến các ràng buộc sản phẩm và dự án như thời gian và ngân sách

2. Kiểm thử là gì?.

Định nghĩa:
Kiểm thử là quá trình bao gồm:

• Lập kế hoạch, chuẩn bị và đánh giá các hoạt động phần mềm và các sản phẩm.
• Kiểm thử tĩnh và kiểm thử động
• Xác định đáp ứng yêu cầu quy định.
• Chứng minh phù hợp với mục đích.
• Phát hiện các khiếm khuyết.

Hoạt động kiểm thử tồn tại trước và sau khi thực hiện kiểm thử, bao gồm các hoạt động sau:

• Lên kế hoạch và xử lý
• Lựa chọn các điều kiện kiểm thử
• Thiết kế các trường hợp kiểm thử (viết testcase)
• Kiểm tra kết quả
• Đánh giá các tiêu chuẩn hoàn thành
• Báo cáo quá trình kiểm thử
• Hoàn thành các hoạt động kiểm kết thúc kiểm thử sau một giai đoạn kiểm thử đã hoàn thành
• Đóng gói sản phẩm
• Đánh giá tài liệu ( bao gồm cả mã nguồn(souce code)
• Phân tích tĩnh.

Các mục tiêu kiểm thử thường là:

• Tìm các lỗi, các thiếu sót trong hệ thống.
• Đạt được sự tin cậy về chất lượng.
• Cung cấp thông tin để đưa ra quyết định.
• Ngăn chặn các lỗi có thể xảy ra.

Mục tiêu của kiểm thử trong các giai đoạn khác nhau

• Phát triển kiểm thử: Các khiếm khuyết được xác định và có thể được sửa chữa.
• Kiểm thử chấp nhận: Xác nhận hệ thống hoạt động như mong đợi và đạt được sự tin tưởng, phần mềm đã đáp ứng được yêu cầu.
• Bảo trì : Đảm bảo không xuất hiện các khiếm khuyết mới khi thay đổi phần mềm.
• Vận hành: Đánh giá các đặc điểm của hệ thống như độ tin cậy và tính sẵn có.

3.Các nguyên tắc trong kiểm thử

• Nguyên tắc 1: kiểm thử cho thấy sự hiện diện của lỗi:

Kiểm thử có thể cho thấy phần mềm đang có lỗi, nhưng không thể chứng minh rằng trong phần mềm không có lỗi nào. Kiểm thử được thực hiện bằng những kỹ thuật khác nhau, làm giảm xác suất lỗi chưa tìm thấy vẫn còn trong phần mềm. Vì vậy cần tìm được càng nhiều lỗi càng tốt.

• Nguyên tắc 2: Kiểm thử toàn diện là không thể:

Nguyên tắc này cho rằng kiểm thử tất cả mọi thứ một cách toàn vẹn là không thể( sự kết hợp
của tất cả input và điều kiện tiên quyết) trừ những phần mềm bao gồm ít trường hợp thì có
thể kiểm thử toàn bộ. Thay vì kiểm thử toàn bộ, việc phân tích rủi ro và dựa trên mức độ
ưu tiên chúng ta có thể tập trung việc kiểm thử vào một số điểm cần thiết và có nguy cơ
lỗi cao hơn.

• Nguyên tắc 3: kiểm thử càng sớm càng tốt:

Các hoạt động kiểm thử phần mềm nên bắt đầu càng sớm càng tốt trong phần mềm hay trong chu trình phát triển hệ thống và nên tập trung vào các mục tiêu xác định. kiểm thử phần mềm từ giai đoạn đầu sẽ giúp phát hiện bug sớm hơn.

• Nguyên tắc 4: sự tập trung của các lỗi:

Thông thường, lỗi tập trung ở một số module, thành phần chức năng chính của hệ thống. Nếu
xác định được điều này chúng ta sẽ tập trung vào tìm kiếm lỗi quanh khu vực được xác định.
Nó được coi là một trong những cách hiệu quả nhất để thực hiện kiểm tra hiệu quả.

Để hiểu rõ hơn nguyên tắc này, ta cần xem xét 3 điều sau:

Nguyên tắc tổ gián: chỗ nào có 1 vài con gián thì ở đâu đó xung quanh nó sẽ có cả tổ gián -> có rất nhiều gián -> chỗ nào có 1 vài bug thì xung quanh, gần chỗ đó sẽ có nhiều bug.

Nguyên tắc Pareto (80/20): thông thường 20% chức năng quan trọng trong một chương trình có thể gây ra đến 80% tổng số bug phát hiện được trong chương trình đó.

Kiểm thử toàn bộ là không thể(nguyên tắc thứ 2): do đó cần phải ananlysis (phân tích) + priorities (tính toán mức độ ưu tiên) để quyết định tập trung vào test chỗ nào.

=> Test kỹ chức năng quan trọng => tìm bug => test những gì liên quan và những chức năng gần nó để tìm ra bug nhiều hơn.

• Nguyên tắc 5: Pesticide paradox:

Nếu sử dụng cùng một tập các trường hợp kiểm thử liên tục, sau một thời gian các trường
hợp kiểm thử không tìm thấy lỗi nào mới. Hiệu quả của các trường hợp kiểm thử bắt đầu giảm
xuống sau một số lần thực hiện, vì vậy chúng ta phải luôn rà soát và sửa đổi các trường
hợp kiểm thử trên một khoảng thời gian thường xuyên.

• Nguyên tắc 6: kiểm thử phụ thuộc vào ngữ cảnh:

Theo nguyên tắc này thì việc kiểm thử phụ thuộc vào ngữ cảnh và chúng ta phải tiếp cận
kiểm thử theo nhiều ngữ cảnh khác nhau. Nếu bạn đang kiểm thử ứng dụng web và ứng dụng di
động bằng cách sử dụng chiến lược kiểm thử giống nhau, thì đó là sai. Chiến lược để kiểm
thử ứng dụng web sẽ khác với kiểm thử ứng dụng cho thiết bị di động của Android. Ví dụ như
một phần mềm an toàn bảo mật sẽ được test khác so với 1 website thương mại điện tử.

• Nguyên tắc 7: Absence-of-errors fallacy (không có lỗi-sai lầm):

Việc không tìm thấy lỗi trên sản phẩm không đồng nghĩa với việc sản phẩm đã sẵn sàng để
tung ra thị trường. không tìm thấy lỗi cũng có thể là do các trường hợp kiểm thử được
tạo ra chỉ nhằm kiểm tra những tính năng được làm đúng theo yêu cầu thay vì tìm kiếm
lỗi mới.
Đồng thời việc tìm ra và sửa lỗi sẽ không có tác dụng nếu như hệ thống được xây dựng mà không sử dụng được hoặc là không đáp ứng được nhu cầu mong đợi của người dùng.

Trên đây mình vừa giới thiệu khái quát về: định nghĩa, sự cần thiết cũng như là các quy tắc cơ bản của kiểm thử. Phần sau mình sẽ giới thiệu với các bạn về quy trình kiểm thử cơ bản và các yếu tố tâm lý học trong kiểm thử.

Phần tiếp theo: Kiểm thử phần mềm: Các nguyên tắc cơ bản (Phần 2)