Tại sao lỗi xuất hiện

Bạn sẽ tìm hiểu trong bài 2, phần mềm không xuất hiện một các kỳ diệu mà thường là phải có cả 1 quá trình phát triển các phương thức, kế hoạch được sử dụng để tạo ra nó. Từ sự khởi đầu của phần mềm, qua quá trình lập kế hoạch, lập trình, và kiểm thử, đến khi khi nó được sử dụng bởi khách hàng, những lỗi này có khả năng được tìm thấy. Hình 1.1 biểu diễn một ví dụ về những chi phí cho việc sửa những lỗi có thể phát sinh trong trong toàn bộ thời gian thực hiện dự án.

Chi phí cho việc sửa lỗi có thể tăng đột ngột trên toàn bộ dự án

Chi phí được tính theo hàm loga, mỗi lần chúng tăng lên gấp 10 lần. Lỗi được tìm thấy và sửa lại trong thời gian gần nhất khi bản đặc tả bắt đầu được viết thì chi phí có thể không là gì cả, hoặc chỉ là 1$ cho ví dụ của chúng ta. Cũng với lỗi tương tự, nếu nó không được tìm thấy cho đến khi phần mềm được được lập trình và kiểm thử thì chi phí có thể lên tới 10$ đến 100$. Nếu một để một khách hàng tìm ra nó, thì chi phí có thể lên tới hàng nghìn thậm chí hàng triệu dollar.

Như một ví dụ trong cuốn sách này, hãy xem xét về The Disney Lion King đã được thảo luận gần đây. Lý do cơ bản của vấn đề là phần mềm này không làm việc được trên nền máy tính phổ biến lúc đó. Nếu như ngay ở giai đoạn đặc tả đầu tiên, ai đó đã nghiên cứu dạng máy PC phổ biến và chỉ ra rằng phần mềm cần được thiết kế và kiểm thử để làm việc được trên những cấu hình đó, thì chi phí cho những cố gắng trên sẽ là rất nhỏ. Nếu điều này không được thực hiện, một bản backup sẽ được gửi cho tester để thu thập những mẫu máy tính phổ biến và thay đổi phần mềm cho phù hợp với chúng. Họ sẽ tìm thấy lỗi, nhưng quá trình sửa lỗi sẽ tốn kém hơn bởi vì phần mềm sẽ phải gỡ lỗi, sửa lỗi và kiểm thử lại. Đội phát triển dự án có thể cũng phải gửi đi một phiên bản đầu tiên của phần mềm tới một nhóm nhỏ các khách hàng để họ kiểm tra, quá trình này gọi là kiểm thử beta. Những khách hàng này, đặc trưng cho một thị trường lớn, sẽ có khả năng khám phá ra nhiều vấn đề. Tuy nhiên, lỗi phần mềm không phải là hoàn toàn cho đến khi có hàng nghìn CD-ROM được sản xuất và bán. Disney đã kiên trì trợ giúp khách hàng qua điện thoại trả lời về sản phẩm, thay thế các ổ CD-ROM, tốt như quá trình gỡ lỗi khác, sửa lỗi và vòng đời kiểm thử. Thật dễ dàng để làm tiêu tan toàn bộ lợi ích của sản phẩm nếu các lỗi là nguy hiểm đối với khách hàng.

Bây giờ bạn có phần mềm với những lỗi ngớ ngẩn, bạn đã biết định nghĩa của một lỗi là gì, và bạn cũng biết chi phí cho chúng đắt đỏ như thế nào. Vậy mục đích của một tester là gì: Mục đích của tester là tìm ra lỗi phần mềm (“The goal of a software tester is to find bugs”)

Bạn có thể liên kết (run across) với các đội phát triển sản phẩm, người luôn muốn các tester xác nhận rằng phần mềm của họ làm việc tốt, không có lỗi. Hãy kiểm tra lại các Case study về con tàu thám hiểm lên địa cực của sao Hỏa, và bạn sẽ thấy tại sao đây là hướng tiếp cận sai. Nếu bạn chỉ kiểm tra những thứ mà sẽ làm việc và cài đặt cho quá trình kiểm tra của bạn, vì vậy, chúng sẽ luôn pass. Và bạn sẽ rất dễ bỏ quên những thứ không làm việc. Cuối cùng, bạn sẽ không phát hiện ra một số lỗi.

Nếu bạn đang bỏ sót một số lỗi, bạn sẽ phải trả giá cho dự án của bạn và tiền của công ty bạn. Là một tester, bạn không nên bằng lòng với những lỗi đã được tìm thấy, bạn nên nghĩ xem làm thế nào để tìm thấy chúng sớm nhất trong quy trình phát triển phần mềm, như vậy, chi phí để fix lỗi sẽ ít hơn.

Mục đích của một tester là tìm các lỗi và tìm thấy chúng một cách sớm nhất có thể (“ The goal of a software tester is to find bugs and find them as early as possible ”).

Nhưng, tìm kiếm các lỗi, thậm chí phát hiện chúng từ rất sớm vẫn là chưa đủ. Hãy nhớ lại định nghĩa về 1 lỗi. Bạn, 1 tester, là con mắt của khách hàng, trước tiên phải xem xét phần mềm. Bạn nói chuyện với khách hàng và phải tìm kiếm một sự hoàn chỉnh.

Mục đích của một tester là tìm các lỗi, tìm thấy chúng một cách sớm nhất có thể, và chắc chắn rằng chúng sẽ được sửa (“ The goal of a software tester is to find bugs, find them as early as possible, and make sure they get fixed. ”).

Câu nói cuối cùng này rất quan trọng. Bạn hãy ghi nhớ nó và lấy ra xem lại khi bạn tìm hiểu về các kỹ thuật kiểm thử được thảo luận trong toàn bộ những nội dung quan trọng của cuốn sách này.

Chú ý: Điều quan trọng là phải chú ý: lỗi phần mềm được sửa không có nghĩa rằng phần mềm đã hoàn hảo. Phần mềm nên được bổ sung thêm những hướng dẫn sử dụng hoặc cung cấp các khóa đào tạo đặc biệt cho khách hàng. Việc này có thể còn yêu cầu thay đổi những số liệu mà nhóm Maketing quảng cáo hoặc thậm chí trì hoãn việc giải phóng (bỏ qua) buggy feature. Trong suốt cuốn sách này, bạn sẽ học cách để trở thành người đi tìm kiếm sự hoàn hảo và phải chắc chắn rằng những lỗi được phát hiện sẽ được sửa, và sẽ có những bài thực hành thực tế cho bạn kiểm thử. Đừng có tìm kiếm đường xoắn ốc nguy hiểm của sự hoàn hảo không thể có thật (Don't get caught in the dangerous spiral of unattainable perfection).

Trong đoạn phim Star Trek II: The Wrath of Khan, Spock nói rằng: “Là một vấn đề của lịch sử vũ trụ, phá hủy bao giờ cũng dễ hơn kiến tạo” (“As a matter of cosmic history, it has always been easier to destroy than to create”). Mới nhìn qua, có thể mọi người sẽ nghĩ công việc của một tester là đơn giản hơn so với công việc của một lập trình viên. Phát hiện ra những lỗi lập trình chắc chắn là dễ hơn so với viết code. Nhưng thật ngạc nhiên, điều đó lại không đúng. Cách tiếp cận rất bài bản và có kỷ luận với phần mềm mà bạn sẽ tìm hiểu trong cuốn sách này yêu cầu bạn phải cống hiến và làm việc một cách chăm chỉ chẳng kém gì một lập trình viên. Hai công việc đều phải sử dụng rất nhiều kỹ năng tương tự nhau, và mặc dù kiểm thử phần mềm không nhất thiết phải cần là một lập trình viên chuyên nghiệp, nhưng họ lại tạo ra những khoản lợi nhuận lớn.

Ngày nay, hầu hết những công ty đã trường thành đều coi kiểm thử phần mềm như công việc của một kỹ sư kỹ thuật. Họ thừa nhận rằng phải đào tạo các tester trong các đội dự án của họ và cho phép họ áp dụng các kỹ thuật vào quá trình phát triển phần mềm để xây dựng được một phần mềm có chất lượng tốt hơn. Thật không may, vẫn có một vài công ty không đánh giá đúng nhiệm vụ khó khăn của quá trình kiểm thử và giá trị của những lỗ lực kiểm thử rất bền bỉ. Với sự giao thiệp trong thị trường tự do, có những công ty thường nổi bật hơn hẳn, bởi vì khách hàng thì thường nói rằng: không nên mua những sản phẩm có nhiều khiếm khuyết. Một tổ chức kiểm thử tốt (hoặc thiếu một cái) có thể tạo nên hoặc phá hỏng một công ty.

Hãy nhìn vào danh sách những đặc điểm mà một tester nên có:

• Họ là những người thám hiểm: tester không sợ mạo hiểm khi ở trong những hoàn cảnh mà họ chưa làm chủ được. Họ thích những khía cạnh mới của phần mềm, cài đặt nó trên máy của họ, và xem xét chuyện gì sẽ xảy ra.
• Họ là những người thợ sửa chữa: các tester làm rất tốt các công việc tính toán xem tại sao một số chức năng của phần mềm lại không làm việc. Họ rất thích những vấn đề khó giải quyết
• Họ rất nghiêm khắc: Các tester luôn phải thử nghiệm, họ có thể nhìn thấy một lỗi mà đã nhanh chóng biến mất hoặc là rất khó để tạo lại tình huống có lỗi đó. Đúng hơn là giải tán nó như một sự may mắn, họ sẽ cố gắng bằng mọi cách có thể để tìm ra nó.
• Họ luôn sáng tạo: việc kiểm thử những điều hiển nhiên, rõ ràng là không thể đủ với một tester. Công việc của họ cần những ý tưởng sáng tạo và thậm chí là các cách tiếp cận mới mẻ để tìm kiếm lỗi (bug).
• Họ là những người cầu toàn: Họ cố gắng để đạt đến sự hoàn hảo, nhưng họ cũng biết rằng điều đó là không thể đạt được và họ chấp nhận dừng quá trình kiểm thử khi họ thấy có thể.
• Họ sử dụng óc phán đoán rất tốt: tester cần đưa ra những quyết định về những thứ mà họ sẽ phải kiểm tra, và ước lượng quá trình kiểm tra sẽ diễn ra trong thời gian bao lâu, nếu như vấn đề mà họ tìm kiếm thật sự là một lỗi.
• Họ là những người rất khéo léo và thích ngoại giao: Tesrter luôn là người thông báo những tin tức xấu. Họ phải nói với lập trình viên những lỗi mà họ phát hiện. Một tester tốt sẽ biết cách để làm việc khéo léo và rất chuyện nghiệp, và họ cũng biết cách để làm việc với lập trình viên, những người không phải lúc nào cũng khéo léo và lịch thiệp.
• Họ là người biết cách thuyết phục người khác: các lỗi mà tester tìm thấy sẽ luôn được xem xét một cách đủ khắt khe để đảm bảo nó sẽ được sửa. Các tester cần chứng minh những luận điểm của họ rằng tại sao những lỗi mà họ phát hiện lại cần được sửa, và những lỗi này có thể gây ra những gì?

KIỂM THỬ PHẦN MỀM LÀ MỘT CÔNG VIỆC RẤT THÚ VỊ: Một đặc điểm cơ bản của các tester là họ rất thích thú với những thứ bị hỏng. Họ sống là để tìm kiếm những sai lầm của các hệ thống khó nắm bắt. Họ toại nguyện khi phát hiện lỗi trong các chương trình phức tạp. Họ thường nhảy lên sung sướng vì điều đó.

Trong những nét đặc trưng này, nếu tester có một số kiến thức về lập trình phần mềm là một ưu thế rất lớn. Bài này sẽ hiểu cách thức mà phần mềm được viết, nó đưa cho bạn một cách nhìn khác về nơi mà các lỗi phần mềm được tìm thấy. Vì vậy, bài này sẽ giúp bạn trở thành một tester làm việc có hiệu quả và gây ảnh hưởng nhiều hơn. Có thể nó cũng giúp bạn phát triển các công cụ kiểm thử.

Cuối cùng, nếu bạn là một chuyên gia trong lĩnh vực không phải là về máy tính, thì sự hiểu biết của bạn có thể vô cùng giá trị để đội dự án phần mềm tạo ra được một sản phẩm mới. Hàng ngày, phần mềm đang được viết để làm mọi thứ. Sự hiểu biết của bạn về dạy học, nấu ăn, máy bay, y học hoặc bất cứ cái gì sẽ là sự trợ giúp đặc lực cho các lỗi được tìm thấy trong phần mềm về lĩnh vực đó.