Kiểm thử phần mềm là một quy trình thực hiện phần mềm hoặc ứng dụng để xác định các khiếm khuyết hoặc lỗi. Để kiểm tra một ứng dụng hoặc phần mềm, chúng tôi cần tuân theo một số nguyên tắc để làm cho sản phẩm của chúng tôi không có lỗi và điều đó cũng giúp các kỹ sư kiểm thử kiểm tra phần mềm bằng công sức và thời gian của họ. Ở đây, trong phần này, chúng ta sẽ tìm hiểu về bảy nguyên tắc thiết yếu của kiểm thử phần mềm

1) Kiểm thử chứng minh sự hiện diện của lỗi

Mọi ứng dụng hoặc sản phẩm được đưa vào sản xuất sau khi đủ số lượng thử nghiệm bởi các nhóm khác nhau hoặc trải qua các giai đoạn khác nhau như Kiểm tra tích hợp hệ thống, Kiểm tra sự chấp nhận của người dùng và Thử nghiệm beta, v.v.
Vậy bạn đã bao giờ thấy hoặc nghe từ bất kỳ nhóm kiểm thử nào rằng họ đã kiểm tra phần mềm đầy đủ và không có lỗi nào trong phần mềm chưa? Thay vào đó, mọi nhóm kiểm tra xác nhận rằng phần mềm đáp ứng tất cả các yêu cầu kinh doanh và nó đang hoạt động theo nhu cầu của người dùng cuối.
Trong ngành kiểm thử phần mềm, sẽ không ai nói rằng phần mềm không có lỗi , điều này hoàn toàn đúng vì việc kiểm thử không thể chứng minh rằng phần mềm không có lỗi hay không còn có lỗi.Tuy nhiên, mục tiêu của thử nghiệm là tìm ra ngày càng nhiều khuyết tật ẩn bằng các kỹ thuật và phương pháp khác nhau. Việc kiểm tra có thể tiết lộ các khiếm khuyết chưa được phát hiện và nếu không tìm thấy khiếm khuyết thì điều đó không có nghĩa là phần mềm không có lỗi.

Ví dụ : Chúng ta có thể lấy một ví dụ đơn giản ngoài thực tế. Nếu để ý, các bạn sẽ thấy được, quảng cáo về nước rửa tay Lifeboy có nói rằng bảo vệ khỏi 99.9% vi khuẩn gây bệnh nếu sử dụng loại nước rửa tay này. Điều đó chứng tỏ rõ ràng sản phẩm không thể loại bỏ hết mầm bệnh 100%. Vì vậy,có thể thấy được không có gì có thể tuyệt đối hết 100%. Áp dụng vào trong khái niệm thử nghiệm, chúng ta có thể nói rằng không có phần mềm nào là không có lỗi.

2) Kiểm thử càng sớm càng tốt

Người kiểm thử cần tham gia vào giai đoạn đầu của Vòng đời phát triển phần mềm (SDLC). Do đó có thể xác định được các khiếm khuyết trong giai đoạn phân tích yêu cầu hoặc bất kỳ khiếm khuyết nào về tài liệu. Chi phí liên quan đến việc sửa chữa những khiếm khuyết này sẽ rất ít khi so sánh với những khiếm khuyết/ lỗi được tìm thấy trong các giai đoạn sau của thử nghiệm.

Hãy xem xét hình ảnh dưới đây cho thấy chi phí sửa lỗi tăng lên như thế nào khi quá trình thử nghiệm tiến tới sản xuất trực tiếp.

Hình ảnh trên cho thấy rằng chi phí cần thiết để sửa lỗi được tìm thấy trong quá trình Phân tích yêu cầu là ít hơn và nó tiếp tục tăng khi chúng ta chuyển sang giai đoạn Kiểm thử hoặc Bảo trì.

Bây giờ câu hỏi đặt ra là nên bắt đầu thử nghiệm sớm như thế nào ?

Sau khi các yêu cầu được hoàn thành, người kiểm thử cần tham gia để phân tích và kiểm tra. Việc phân tích và kiểm tra phải được thực hiện trên các tài liệu yêu cầu, đặc điểm kỹ thuật hoặc bất kỳ loại tài liệu nào khác để nếu các yêu cầu được xác định không chính xác thì nó có thể được sửa ngay lập tức thay vì sửa chúng trong giai đoạn phát triển.

3) Kiểm thử toàn bộ là không thể

Không thể kiểm tra tất cả các chức năng với tất cả các tổ hợp dữ liệu đầu vào hợp lệ và không hợp lệ trong quá trình kiểm thử thực tế. Thay vì cách tiếp cận này, việc thử nghiệm một số kết hợp được xem xét dựa trên mức độ ưu tiên sử dụng các kỹ thuật khác nhau.
Thử nghiệm cạn kiệt sẽ cần những nỗ lực không giới hạn và hầu hết những nỗ lực đó đều không hiệu quả. Ngoài ra, các mốc thời gian của dự án sẽ không cho phép thử nghiệm quá nhiều sự kết hợp. Do đó, bạn nên kiểm tra dữ liệu đầu vào bằng các phương pháp khác nhau như Phân vùng tương đương và Phân tích giá trị cận biên,…

Ví dụ: Chúng ta có một trường đầu vào chỉ cho phép nhập bảng chữ cái, ký tự đặc biệt và số từ 0 đến 1000. Trên thực tế sẽ có rất nhiều kết hợp xuất hiện để kiểm tra, tuy nhiên không thể kiểm tra tất cả các kết hợp cho từng loại đầu vào. Vì vậy trong trường hợp này, chúng ta sẽ kết hợp các phương pháp để kiểm thử thay vì kiểm tra tất cả các kết hợp.

Các nỗ lực kiểm thử cần thiết để kiểm tra sẽ rất tốn gian và nó cũng sẽ ảnh hưởng đến tiến độ và chi phí của dự án. Do đó, người ta luôn nói rằng kiểm tra toàn diện trên thực tế là không thể.

4) Thử nghiệm phụ thuộc vào ngữ cảnh

Kiểm tra phụ thuộc vào ngữ cảnh, về cơ bản có nghĩa là cách bạn kiểm tra một trang web thương mại điện tử sẽ khác với cách bạn kiểm tra một ứng dụng thương mại ngoài giá bán. Tất cả các phần mềm được phát triển không giống nhau. Bạn có thể sử dụng một cách tiếp cận, phương pháp, kỹ thuật và loại thử nghiệm khác tùy thuộc vào loại ứng dụng.
Ví dụ : thử nghiệm một ứng dụng ngân hàng khác với thử nghiệm bất kỳ ứng dụng thương mại điện tử hoặc quảng cáo nào đó. Rủi ro liên quan đến mỗi loại ứng dụng là khác nhau, do đó sẽ không hiệu quả nếu sử dụng cùng một phương pháp, kỹ thuật và loại thử nghiệm để kiểm tra tất cả các loại ứng dụng.

5) Lỗi thường được phân bố tập trung

Thông thường, phần lớn lỗi tập trung vào những module, thành phần chức năng chính của hệ thống. Điều này cũng thuận theo nguyên lý Pareto: 80% số lượng lỗi được tìm thấy trong 20% tính năng của hệ thống. Nếu bạn thành công xác định được điều này, bạn 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ả

6) Nghịch lý thuốc trừ sâu

Nguyên tắc Nghịch lý thuốc trừ sâu nói rằng nếu cùng một tập hợp các trường hợp thử nghiệm được thực hiện lặp đi lặp lại trong một khoảng thời gian thì các bộ thử nghiệm này không đủ khả năng để xác định các lỗi mới trong hệ thống.

Để khắc phục “Nghịch lý thuốc bảo vệ thực vật” này, bộ các trường hợp thử nghiệm cần được thường xuyên xem xét và sửa đổi. Nếu được yêu cầu, một tập hợp các trường hợp thử nghiệm mới có thể được thêm vào và các trường hợp thử nghiệm hiện có có thể bị xóa nếu chúng không thể tìm thấy thêm bất kỳ khiếm khuyết nào từ hệ thống.

7) Quan niệm sai lầm về việc “hết lỗi”

Nếu phần mềm được kiểm tra đầy đủ và nếu không có lỗi nào được tìm thấy trước khi phát hành, thì chúng tôi có thể nói rằng phần mềm là 99% không có lỗi. Nhưng có khả năng khi ứng dụng được kiểm tra bên cạnh các yêu cầu không chính xác, xác định các lỗ hổng và sửa chúng trong một khoảng thời gian nhất định sẽ không hữu ích vì việc kiểm tra được thực hiện trên đặc điểm kỹ thuật sai, không áp dụng cho các yêu cầu của khách hàng. Việc không có lỗi ngụy biện nghĩa là việc xác định và sửa lỗi sẽ không hữu ích nếu ứng dụng không thực tế và không thể đáp ứng các yêu cầu và nhu cầu của khách hàng

Kết Luận

Kiểm thử là một yếu tố quan trọng của phát triển phần mềm. Nó cũng có thể là một hoạt động phức tạp để cấu trúc chính xác và theo cách hỗ trợ hiệu quả tối đa. Do sự phức tạp này, việc xem xét các quy trình và nguyên tắc luôn hữu ích để đảm bảo bạn đang tuân theo các phương pháp hay nhất.Nếu bạn tham gia vào bất kỳ khía cạnh nào của kiểm thử phần mềm, bạn nên xem xét và hiểu đầy đủ các tiêu chuẩn này, kiểm tra xem bạn có đang tuân thủ các tiêu chuẩn này trong tổ chức và nhóm của mình không, vì chúng sẽ giúp bạn đạt được các tiêu chuẩn chất lượng cao và cung cấp cho khách hàng của bạn niềm tin rằng phần mềm đã sẵn sàng sản xuất.

Tài liệu tham khảo

http://www.softwaretestingandistqb.com/7-fundamental-principles-of-software-testing-as-per-istqb/