BÀI 2 - QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

Mục lục

1. Quy trình phát triển phần mềm
2. Thực trạng của quá trình kiểm thử phần mềm
3. Quá trình nghiên cứu bản đặc tả phần mềm

BÀI 2. QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

Để trở thành một tester có hiệu quả, ít nhất bạn phải hiểu toàn bộ quy trình phát triển phần mềm ở mức cao. Nếu bạn viết một chƣơng trình nhỏ nhƣ một ngƣời mới tập lập trình hoặc nhƣ một sở thích, bạn sẽ thấy rằng cách mà bạn làm khác hẳn với những cách thức mà các công ty lớn thƣờng sử dụng để phát triển phần mềm. Để tạo ra đƣợc một sản phẩm phần mềm mới, có thể bao gồm hàng tá, hàng trăm, thậm chí hàng nghìn thành viên thực hiện các quy tắc khác nhau và làm việc cùng nhau dƣới một lịch trình chặt chẽ. Hãy xem xét những nhiệm vụ mà họ phải thực hiện, họ gây ảnh hƣởng tới nhau nhƣ thế nào, và cách mà họ đƣa ra những quyết định ở tất cả các giai đoạn của quy trình phát triển phần mềm.

2.1. Quy trình phát triển phần mềm

Mục đính của phần này là hƣớng dẫn cho bạn mọi thứ về quy trình phát triển phần mềm sẽ đƣợc áp dụng trong môn học này. Mục đích là cho bạn một cái nhìn tổng quan về tất cả các phần bên trong một sản phẩm phần mềm và thấy đƣợc một vài hƣớng tiếp cận chung thƣờng đƣợc sử dụng ngày nay. Với những hiểu biết này, bạn sẽ tự có cách tốt nhất để áp dụng các kỹ năng kiểm thử phần mềm mà bạn sẽ đƣợc học.

Phần chính của bài này bao gồm:

- Các thành phần (component) chính nào bên trong một sản phẩm phần mềm

- Những ai và các kỹ năng nào đóng góp vào một sản phẩm phần mềm

- Xử lý phần mềm nhƣ thế nào để từ một ý tƣởng xây dựng lên một sản phẩm cuối cùng

2.1.1. Các thành phần của phần mềm (product components)

Một sản phần mềm chính xác là cái gì? Nhiều ngƣời cho rằng, đơn giản nó là thứ mà ngƣời ta down đƣợc từ internet hoặc cài đặt đƣợc từ DVD để nó chạy đƣợc trên máy tính. Đây là một mô tả tốt, nhƣng là một mô tả tốt trong một phạm vi nhỏ, nhƣng thật sự, nhiều thành phần đƣợc ẩn bên trong phần mềm. Có nhiều phần bên trong hộp “come in the box”, mà chúng thƣờng đƣợc lấy ra để trợ giúp hoặc có thể bị bỏ qua. Mặc dù rất dễ quên tất cả các phần này, nhƣng là một tester, bạn cần biết về chúng. Bởi vì chúng là những nội dung cần kiểm tra và chúng có thể chứa lỗi.

a) Lỗ lực đằng sau một sản phẩm phần mềm nhƣ thế nào?

Trƣớc tiên, bạn hãy nhìn nhận những lỗ lực phía sau một sản phầm phần mềm. Hình 2.1 chỉ ra một vài những thành phần trừu tƣợng mà bạn có thể không hề nghĩ tới.

Hình 2.1. Rất nhiều lỗ lực (effort) ẩn dấu phía dưới một sản phầm phần mềm

Vậy, đâu sẽ là tất cả những thứ này, bên cạnh mã nguồn thật sự, liệu đây có phải là một cái phễu (funnel) phần mềm? Nhìn lƣớt qua, có lẽ chúng là những thứ hiển nhiên mà một lập trình việc tạo ra. Và rõ ràng chúng không phải là những thứ mà có thể đƣợc xem trực tiếp từ CD – ROM. Nhƣng để dùng một dòng diễn tả cho “món mì ống thương mại”: “chúng ở đây”. Ít nhất cũng là nhƣ vậy.

Những thuật ngữ đƣợc dùng trong ngành công nghiệp phần mềm để mô tả thành phần một sản phẩm phần mềm, mà đã đƣợc tạo ra và tiếp tục tới một nơi nào khác có thể đƣợc làn truyền. Cách dễ nhất để giải thích những thứ mà tất cả sự chuyển giao này là tổ chức chúng thành những loại lớn.

b) Yêu cầu của khách hàng

Phần mềm cần đƣợc viết một cách đầy đủ các yêu cầu mà một ngƣời hoặc một nhóm ngƣời đƣa ra đó là những khách hàng. Để làm hợp lý những yêu cầu này, một nhóm phát triển phần mềm phải tìm ra những cái mà khách hàng muốn. Một nhóm thì phỏng đoán những yêu cầu, nhƣng hầu hết các thông tin chi tiết đƣợc thu thập trong quá trình khảo sát, hồi đáp từ những phiên bản trƣớc của phần mềm, cạnh tranh các thông tin về sản phẩm, các nhìn tổng quan, các nhóm trọng tâm, và một số các phƣơng thức khác, một số formal, một số các khác. Tất cả những thông tin này đƣợc tìm hiểu, xem xét và làm sáng tỏ để quyết định chính xác những đặc trƣng nào mà sản phẩm phần mềm cần có.

HÃY ĐƯA CÁC FEATURES (ĐẶC TRƯNG) NÀY VÀO PERSPECTIVE

VỚI CÁC FOCUS GROUP (NHÓM TRỌNG TÂM): một phương tiện phổ biến để nhận những hồi đáp trực tiếp từ các khách hàng tiềm năng là sử dụng các focus group. Focus group thƣờng đƣợc tổ chức bởi các công ty khảo sát độc lập - những ngƣời thiết đặt các cơ quan trong các phố mua bán lớn. Các cuộc khảo sát hoặc những chuyến đi bộ điển hình vòng quanh phố mua bán với một bìa kẹp hồ sơ và hỏi những ngƣời đi qua nếu họ muốn đóng góp một phần vào quá trình nghiên cứu. Họ sẽ hỏi một vài câu hỏi liên quan đến chất lƣợng nhƣ: “Bạn có một PC ở nhà không? Bạn sử dụng phần mềm X nhƣ thế nào? Bạn sử dụng bao nhiêu thời gian để online?” và tiếp tục… Nếu bạn phù hợp với yêu cầu về đối tƣợng, họ sẽ mời bạn quay trở lại một vài giờ để tham gia cùng với một vài ngƣời khác trong focus group. Ở đây bạn sẽ đƣợc hỏi các câu hỏi chi tiết hơn về phần mềm máy tính. Bạn có thể đƣợc biểu diễn những hộp phần mềm khác nhau và hỏi về những sở thích của bạn để bạn lựa chọn. Hoặc bạn có thể thảo luận nhƣ một đặc trƣng nhóm (group features) giống nhƣ bạn nhìn thấy một sản phẩm mới. Tốt hơn hết bạn nên bỏ ra chút thời gian của mình. Hầu hết các focus group đƣợc hƣớng dẫn nhƣng với      tƣ cách là một công ty phần mềm mà yêu cầu thông tin đƣợc giữ kín. Nhƣng thƣờng thì rất dễ dàng để đoán ra họ là ai.

c) Đặc tả

Kết quả của quá trình nghiên cứu các yêu cầu của khách hàng chỉ là những dữ liệu thô. Nó không mô tả đƣợc những sản phẩm đề xuất, nó chỉ xác nhận những thứ nên hay không nên tạo ra và các đặc trƣng mà khách hàng mong muốn. Bản đặc tả lƣu giữ các thông tin trên với các yêu cầu bắt buộc và đƣa ra những định hình xem phần mềm sẽ là gì, sẽ làm gì, và trông nó nhƣ thế nào.

Định dạng của các bản đặc tả thay đổi rất nhiều. Đặc biệt, một số công ty mà các sản phẩm của họ dành cho chính phủ, cho vũ trụ, tài chính, và ngành công nghiệp dƣợc phẩm sử dụng một quy trình rất nghiêm khắc với nhiều sự kiểm tra ngặt nghèo và cân nhắc kỹ lƣỡng. Kết quả thu đƣợc là một bản đặc tả vô cùng kỹ lƣỡng, chi tiết đƣợc chốt lại, có nghĩa là không đƣợc phép thay đổi nó dƣới mọi điều kiện. Mọi ngƣời trong nhóm phát triển biết chính xác chúng đang tạo nên cái gì.

Đây là các nhóm phát triển phần mềm, thƣờng tạo ra những sản phẩm ít bị chê trách, những ngƣời đã đƣa ra những bản đặc tả trên bàn ăn (on cocktail napkins), nếu họ tạo ra tất cả chúng. Đây là những thuận lợi dễ nhận thấy, chúng rất mềm dẻo, nhƣng lại chứa đựng đầy rủi ro. Và sản phẩm cuối cùng không đƣợc biết đến cho đến khi nó đƣợc tung ra thị trƣờng.

d) Kế hoạch làm việc (schedule)

Một phần rất quan trọng của quá trình sản xuất phần mềm là kế hoạch làm việc của nó. Là một dự án phát triển rất phức tạp với rất nhiều phần và nhiều ngƣời cùng tham gia vì vậy, cần một số cơ cấu để theo dõi quá trình xử lý này. Nó có thể là một danh sách các nhiệm vụ đơn giản để hình thành nên biểu đồ Gantt (hình 2.2) để theo dõi chi tiết mỗi nhiệm vụ với phần mềm quản lý dự án.

Mục đích của Schedule là biết đƣợc công việc nào đã đƣợc hoàn thành, có bao nhiêu việc bị bỏ quên, và khi nào thì công việc được hoàn thành.

 

 

Hình 2.2. Một biểu đồ Gantt biểu diễn các nhiệm vụ của một dự án tương phản với các đường ngang biểu diễn thời gian (horizontal timeline)

e) Tài liệu thiết kế phần mềm

Một nhận thức sai lầm rất phổ biến là khi một lập trình viên tạo ra một chƣơng trình, đơn giản là anh ta ngồi xuống và bắt đầu viết code. Điều này có thể xảy ra trong một cửa hàng phần mềm nhỏ và không chuyên nghiệp. Nhƣng ở các công ty lớn, dù là với phần mềm nhỏ nhất cũng phải trải qua quá trình thiết kế để lập kế hoạch về cách mà phần mềm sẽ đƣợc viết. Trong cuốn sách này, phần mềm cũng yêu cầu đƣợc phác thảo và lập kế hoạch trƣớc khi những đoạn mã đầu tiên đƣợc gõ, hoặc đƣợc xây dựng.

Những tài liệu mà những lập trình viên tạo ra biến đổi rất nhiều phụ thuộc vào công ty, dự án, và nhóm phát triển, nhƣng mục đích của chúng đều là lập kế hoạch và tổ chức mã đƣợc viết.

Đây là một danh sách một vài tài liệu thiết kế phần mềm rất phổ biến:

- Kiến trúc (Architecture): Một tài liệu mô tả cho toàn bộ thiết kế của phần mềm, bao gồm mô tả của tất cả các thành phần lớn và cách mà chúng gây ảnh hƣởng tới các bộ phận khác.

- Sơ đồ luồng dữ liệu (Data flow diagram): Một sơ đồ chính thức biểu diễn dữ liệu xuyên suốt một chƣơng trình. Thỉnh thoảng nó tham chiếu tới một bubble chart bởi vì nó sẽ gây chú ý hơn với các vòng tròn (circle) và các dòng (line)

- Sơ đồ chuyển trạng thái (State transition diagram): Một sơ đồ chính thức khác phá vỡ phần mềm ở trạng thái cơ bản, hoặc các điều kiện, và biểu diễn các phƣơng tiện di chuyển từ trạng thái này đến trang thái khác.

- Sơ đồ luồng (Flow chart): Các phƣơng tiện truyền thống diễn đạt bằng hình ảnh mô tả luồng logic của phần mềm. Ngày nay, flowcharting không còn phổ biến, nhƣng khi nó đƣợc sử dụng, viết code từ một flowchart chi tiết là một quá trình xử lý đơn giản.

- Mã chú giải (commented code): Có một cách nói cũ rằng bạn có thể viết code một lần, nhƣng nó sẽ đƣợc đọc bởi bất kỳ ai, ít nhất là 10 lần. Bởi vậy, những lời chú giải hợp lý cho các đoạn code là rất quan trọng, vì vậy, các lập trình viên đƣợc giao nhiệm vụ bảo trì code có thể dễ dàng hiểu đƣợc đoạn mã đó làm gì và làm nhƣ thế nào.

f) Tài liệu kiểm thử

Là thành phần không thể thiếu để tạo nên một sản phẩm phần mềm. Với các lý do này, các lập trình viên phải lập kế hoạch và xây dựng tài liệu cho công việc của họ, tester phải hiểu rõ điều này. Không ai nghe thấy rằng một nhóm kiểm thử phần mềm phải tạo ra nhiều khả năng chuyển giao (deliverables) hơn các lập trình viên.

Đây là một danh sách test deliverables quan trọng:

- Kế hoạch kiểm thử (test plan) mô tả toàn bộ các phƣơng thức đƣợc sử dụng để thay đổi phần mềm sao cho phù hợp với bản đặc tả và các yêu cầu của khách hàng. Nó bao gồm mục tiêu về chất lƣợng, các yêu cầu về tài nguyên, kế hoạch làm việc, những nhiệm vụ đƣợc giao, phƣơng thức, và những thứ tƣơng tự nhƣ thế (and so forth)

- Danh sách các trƣờng hợp kiểm thử (test case list) Những phần sẽ đƣợc kiểm tra và mô tả từng bƣớc chi tiết và sẽ đƣợc thực hiện theo để kiểm tra phần mềm.

- Báo cáo lỗi (bug reports) mô tả các vấn đề đƣợc phát hiện nhờ các test case. Có thể chúng không đƣợc ghi ra giấy nhƣng chúng sẽ đƣợc theo dõi qua database.

- Các công cụ kiểm thử và kiểm thử tự động (Test tools and automation) đƣợc mô tả chi tiết trong bài 13. Nếu nhóm của bạn sử dụng các công cụ tự động để kiểm thử phần mềm, thì hoặc là chúng đƣợc mua hoặc đƣợc tự viết, và chúng đƣa ra kết quả bằng tài liệu.

g) Thành phần tạo nên một sản phầm phần mềm

Nhưvậy, trong bài này bạn đã đƣợc tìm hiểu về các lỗ lực để tạo ra một sản phẩm phần mềm. Cũng cần phải nhận thức rằng khi một sản phẩm đã sẵn sàng để đƣợc đóng gói và mang đi thì không phải mỗi code đƣợc chuyển đi, còn rất nhiều những bộ phận khác đi cùng với nó (hình 2.3). Bởi vì tất cả những phần này cũng đƣợc này cũng đƣợc thấy và sử dụng bởi khách hàng, chúng cũng cần đƣợc kiểm tra.

Hình 2.3: CD-ROM phần mềm là một trong rất nhiều phần tạo nên một sản phẩm phần mềm

 

Nhưng thật không may, các thành phần này thƣờng xuyên bị bỏ qua trong quy trình kiểm tra phần mềm. Chắc hẳn rằng bạn cũng đã thử sử dụng các trợ giúp gắn liền với sản phẩm và thấy nó không đƣợc tiện dụng lắm thậm chí rất là tồi tệ. Hoặc có lẽ bạn bạn đã kiểm tra yêu cầu hệ thống trên một sticker ở bện cạnh hộp phần mềm (software box) chỉ khám phá ra sau khi bạn mua phần mềm nhƣng nó lại không hoạt động trên PC của bạn. Dƣờng nhƣ, việc kiểm thử là rất đơn giản, nhƣng không hẳn thế, hãy kiểm tra lại chúng một lần nữa trƣớc khi đƣa phần mềm ra thị trƣờng. Bạn sẽ làm vậy chứ.

Sau khi đọc cuốn sách này, bạn sẽ đƣợc biết về những bộ phận không phải  là phần mềm này (non-software pieces) và cách để kiểm tra chúng một cách hợp lý. Sau đó, hãy giữ lại danh sách này trong đầu nhƣ một ví dụ rằng một sản phẩm phần mềm thì không chỉ là code:

• Help files ---- User's manual
• Samples and examples ---- Labels and stickers
• Product support info ---- Icons and art
• Error messages ---- Ads and marketing material
• Setup and installation ---- Readme file

ĐỪNG QUÊN KIỂM TRA NHỮNG THÔNG ĐIỆP LỖI: thông điệp lỗi (error message) là những phần dễ bị bỏ qua nhất trong một sản phẩm phần mềm. Các lập trình viên, không phải những ngƣời thực sự có kinh nghiệm, mà cụ thể là những ngƣời viết ra chúng. Hiếm khi họ lập kế hoạch mà thƣờng sửa chữa dần chƣơng trình trong khi kiểm tra các lỗi. Vì vậy, thật khó khăn khi các tester muốn tìm thấy và hiển thị đầy đủ các lỗi. Đừng đƣa ra những thông điệp lỗi gây sợ e sợ trong phần mềm của bạn.

Error: Keyboard not found. Press F1 to continue. 

Can't instantiate the video thing.

WindowPs has found an unknown device and is installing a driver for it.

A Fatal Exception 006 has occurred at 0000:0000007.

2.1.2. Các nhân lực của dự án phần mềm (Software Project Staff)

Bây giờ, bạn đã biết những thứ bên trong một phần mềm và những lợi ích của nó. Đây chính là thời điểm thích hợp nhất để bạn tìm hiểu về những con ngƣời tạo nên một phần mềm. Dĩ nhiên, tùy thuộc vào các công ty và các dự án đƣợc đề cập tới, điều này sẽ còn thay đổi rất nhiều. Nhƣng hầu hết các quy tắc là giống nhau, chỉ khác nhau ở tên gọi.

Danh sách dƣới đây (không có một sự sắp xếp đặc biệt nào cả) bao gồm những ngƣời tham gia chính và những công việc mà họ phải làm. Những cái tên thông dụng nhất đƣợc sử dụng, nhƣng chúng ta vẫn chờ đợi những sự thay đổi và bổ sung phù hợp:

- Những ngƣời quản lý dự án, quản lý chƣơng trình, hoặc quản lý sản phẩm(Project managers, program managers, hoặc producers): điều khiển dự án từ khi bắt đầu đến khi kết thúc. Thƣờng thì họ chịu trách nhiệm về việc viết các bản đặc tả (product spec), quản lý kế hoạch thực hiện công việc (schedule), và đƣa ra những quyết định đảm bảo sự phối hợp tốt nhất (trade- offs).

- Các kỹ sƣ hệ thống và kiến trúc (Architects or system engineers): là những chuyên gia về công nghệ của nhóm xây dựng sản phẩm. Thƣờng thì họ là những ngƣời có nhiều kinh nghiệm và có đủ khả năng để thiết kế toàn bộ kiến trúc hệ thống, hoặc thiết kế phần mềm. Có kết hợp rất chặt chẽ với các lập trình viên.

- Các lập trình viên, ngƣời phát triển dự án, hoặc ngƣời viết code (Programmers, developers, or coders): thiết kế, viết phần mềm, và sửa lỗi đƣợc tìm thấy. Họ kết hợp rất chặt chẽ với những ngƣời quản lý dự án và ngƣời xây dựng kiến trúc phần mềm để tạo nên phần mềm. Sau đó, họ cùng làm việc với ngƣời quản lý và tester để sửa lỗi phần mềm.

- Testers hoặc nhân viên QA (Quality Assurance: có nhiệm vụ tìm kiếm và báo cáo các vấn đề mà phần mềm gặp phải. Họ làm việc rất mật thiết với tất cả các thành viên của dự án. Họ phát triển, chạy các trƣờng hợp test và báo cáo các vấn đề họ phát hiện ra.

- Ngƣời viết các kỹ thuật, trợ giúp ngƣời dùng, giáo dục ngƣời dùng, ngƣời viết thủ công, hoặc hình ảnh minh họa (Technical writers, user assistance, user education, manual writers, or illustrators) trên giấy và trên mạng đến với một sản phẩm phần mềm.

- Quản lý cấu hình hoặc xây dựng (Configuration management or builder): điều khiển quy trình cùng làm việc (the process of pulling together) toàn bộ phần mềm bởi lập trình viên và toàn bộ tài liệu đƣợc xây dựng bởi ngƣời viết và cùng đặt nó trong một gói đơn.

Nhƣ bạn thấy, một vài nhóm ngƣời góp phần tạo nên một sản phầm phần mềm. Trong các đội lớn, có hàng tá hoặc hàng trăm ngƣời làm việc cùng nhau. Để kết nối thành công và tổ chức hƣớng tiếp cận, họ cần lập kế hoạch, một phƣơng thức thực thi từ điểm A đến điểm B. Đây là cái sẽ đƣợc mô tả tiếp theo.

2.2. Thực trạng của quá trình kiểm thử phần mềm

Trong phần 1, bạn đã đƣợc tìm hiểu những khái niệm cơ bản về kiểm thử phần mềm và quy trình phát triển phần mềm. Những thông tin đã biểu diễn trong các bài này chỉ là ở mức tổng quan, và cho bạn cái nhìn về cách mà các dự án phần mềm có thể hoạt động. Nhƣng thật không may, trong thế giới thật, bạn sẽ không bao giờ thấy một phần mềm hoàn hảo theo một bất kỳ một mô hình phát triển phần mềm nào. Bạn sẽ không thể đƣa ra đƣợc một bản đặc tả chi tiết hoàn toàn đầy đủ mà khách hàng cần và bạn cũng sẽ không đủ thời gian để làm tất cả những bài kiểm tra mà bạn cần phải làm. Không có vấn đề gì cả. Nhƣng để trở thành một tester làm việc có hiệu quả, bạn cần phải biết tƣởng tƣợng ra quy trình phần mềm làm việc nhƣ thế nào để đạt đƣợc mục đích.

Mục đích của bài này là làm dịu đi tác động của chủ nghĩa lý tƣởng lên quá trình kiểm tra thực tế trên phần mềm. Nó sẽ giúp bạn thấy rằng, trong thực tế, sự thỏa hiệp và nhƣợng bộ phải xuyên suốt vòng đời phát triển phần mềm. Nhiều điều trong những sự thỏa hiệp này là liên quan quan trực tiếp đến nỗ lực kiểm thử

 

phần mềm. Những lỗi mà bạn tìm thấy và những vấn đề mà bạn ngăn chặn, tất cả đều có ảnh hƣởng đặc biệt tới dự án của bạn. Sau khi đọc bài này, bạn sẽ thu nhận đƣợc rất nhiều quy tắc, sự tiếp xúc, và những khả năng hồi đáp mà tester cần và hi vọng rằng bạn sẽ đƣa ra những quyết định giúp kiến tạo ra một sản phẩm phần mềm.

Trọng tâm của bài này bao gồm:

- Tại sao phần mềm không bao giờ là hoàn hảo

- Tại sao kiểm thử phần mềm không phải là một vấn đề mang tích chất khuôn

mẫu

- Những thuật ngữ phổ biến đƣợc sử dụng trong kiểm thử phần mềm

2.2.1. Phƣơng châm của việc kiểm thử

Đoạn đầu của bài này là một danh sách các phƣơng châm hoặc các chân lý. Hãy coi chúng giống nhƣ “quy tắc đi đường” ("rules of the road") hoặc “chân lý của cuộc sống” ("facts of life") dành cho quá trình kiểm thử hoặc phát triển phần mềm. Mỗi một phƣơng châm này là một sự hiểu biết nho nhỏ giúp họ đặt một số khía cạnh của toàn bộ quá trình xử lý vào viễn cảnh tƣơng lai.

a) Tầm quan trọng của việc kiểm thử đầy đủ một chƣơng trình:

Là một tester, bạn có thể tin rằng bạn có khả năng tiếp cận với một khía cạnh của phần mềm, kiểm tra nó, tìm ra tất cả các lỗi, và đảm bảo rằng phần mềm là hoàn hảo. Nhƣng thật không may, điều này là không thể đƣợc, thậm chí là với một chƣơng trình rất đơn giản, vì 4 lý do sau:

- Số lƣợng các dữ liệu có thể là đầu vào là rất lớn

- Số lƣợng các dữ liệu có thể đƣa ra cũng vô cùng lớn

- Số lƣợng các “lối đi” trong phần mềm là rất lớn

- Đặc tả phần mềm có tính chất chủ quan. Bạn có thể nói rằng lỗi là những khuyết điểm dƣới con mắt của độc giả.

Tất cả các trƣờng hợp trên nếu kết hợp cùng nhau, bạn sẽ thu đƣợc một tập các điều kiện vô cùng lớn đến mức không thể thử hết được. Nếu bạn không tin điều này thì có thể xem xét trong hình 2.4, phần mềm Microsoft Windows Calculator.

Hình 2.4. . Thậm chí một chương trình đơn giản như Windows Calculator cũng quá phức tạp để kiểm thử đầy đủ

• Khi bạn đƣợc phân công kiểm tra phần mềm Windows Calculator. Bạn quyết định là sẽ bắt đầu kiểm tra phép cộng. Bạn thử nghiệm xem 1+0=? Bạn nhận đƣợc câu trả lời là 1. Phép kiểm tra này cho kết quả đúng. Sau đó, bạn tiếp tục kiểm tra 1+1=? Kết quả nhận đƣợc là 2. Bạn đi bao xa? Máy tính chấp nhận một số có 32 chữ số, vì vậy, bạn phải cố gắng thử tất cả các khả năng có thể:

1+99999999999999999999999999999999=

Sau lần đầu tiên, bạn hoàn thành chuỗi số trên, bạn cũng có thể thử trên các phép toán 2+0=?, 2+1=?, 2+2=?... Và cứ tiếp tục nhƣ vậy. Cuối cùng, bạn sẽ phải thử nghiệm trên phép tính:

99999999999999999999999999999999+99999999999999999999999999999999=

• Tiếp theo bạn sẽ phải thử trên các giá trị thập phân: 1.0+0.1=?, 1.0+0.2=?....

• Một khi bạn đã kiểm tra tính đúng đắn của tổng các số, không nên kiểm tra các giá trị liên tiếp, bạn cần cố gắng đƣa vào các dữ liệu bất hợp lý để kiểm tra tính đúng đắn của phần mềm. Hãy nhớ rằng, bạn không được phép giới hạn những số mà người sử dụng nhập vào, họ có quyền nhấn bất kỳ phím nào trên bàn phím. Những giá trị nên đƣợc thử nghiệm có lẽ là: 1+a, z+1, 1a1+2b2,… Nhƣ vậy, thì sẽ có đến hàng tỷ trƣờng hợp cần kiểm tra.

• Những dữ liệu đƣợc biên tập cũng phải đƣợc kiểm tra. Phần mềm Windows Calculator cho phép sử dụng các phím Backspace và Delete. Vì vậy, bạn nên thử nghiệm với chúng. Ví dụ, 1<backspace>2+2 phải cho ra kết quả là 4. Những thứ mà bạn đã thực hiện kiểm tra trong chừng mực nào đó, phải đƣợc kiểm tra lại bằng cách nhấn vào phím Backspace cho mỗi “lối vào” (entry), cho mỗi cặp “lối vào” (two entries), và cứ tiếp tục nhƣ vậy.

• Nếu bạn hoặc nhân viên của bạn đƣợc giao nhiệm vụ hoàn thiện tất cả các trƣờng hợp này. Sau đó, bạn có thể tiếp tục tiến hành trên 3 chữ số, sau đó là 4 chữ số,…

Có rất nhiều lối (entry) vào có thể khiến bạn không bao giờ hoàn thành đƣợc chúng, thậm chí, nếu bạn sử dụng một siêu máy tính để chuyển dữ liệu vào Calculator. Nếu bạn quyết định loại bỏ một vài điều kiện kiểm tra bởi vì bạn thấy chúng dƣ thừa hoặc không cần thiết, hoặc chỉ để tiết kiệm thời gian (or just to save time), thì có nghĩa là bạn đã không kiểm tra chƣơng trình một cách đầy đủ.

b) Kiểm thử phần mềm là một bài kiểm tra phụ thuộc vào sự rủi ro

Nếu bạn quyết định không kiểm tra mọi trƣờng hợp kiểm thử, bạn sẽ phải chịu trách nhiệm về những rủi ro. Trong ví dụ về Calculator, trƣờng hợp mà bạn lựa chọn để kiểm thử có lẽ là những trƣờng hợp thông thƣờng: 1024+1024=2048? Và có thể, lập trình viên đã tình cờ loại bỏ lỗi trong hoàn cảnh này. Nhƣng trong những trƣờng hợp không đƣợc kiểm tra, bạn cũng không thể đảm bảo rằng nó không có lỗi, và sẽ đến lúc khách hàng khám phá ra nó. Và khi đó, chi phí cho việc sửa lỗi sẽ là lớn hơn rất nhiều so với việc sửa lỗi ngay từ đầu.

Điều này thật đáng sợ (This may all sound pretty scary). Bạn không thể kiểm tra mọi thứ, và nếu không kiểm tra mọi trƣờng hợp thì bạn sẽ bỏ sót lỗi. Sản phẩm

 

phải đƣợc tung ra thị trƣờng, vì vậy, bạn cần dừng việc kiểm tra, nhƣng nếu dừng quá sớm thì một số vùng sẽ không đƣợc kiểm thử. Bạn phải làm nhƣ thế nào?

Một nội dung quan trọng mà tester cần phải tìm hiểu là làm thế nào để giảm số lƣợng các trƣờng hợp kiểm thử rất lớn thành một tập các test case có thể thực thi đƣợc, và làm thế nào để sáng suốt lựa chọn những quyết định ít rủi ro nhất. Điều này buộc tester phải xác định đƣợc đâu là vấn đề quan trọng và đâu là vấn đề không quan trọng.

Hình 2.5 mô tả mối quan hệ giữa số lƣợng các trƣờng hợp test với số lƣợng các lỗi đƣợc tìm thấy. Nếu bạn cố thử kiểm tra mọi thứ, chi phí có thể tăng lên đột ngột và những lỗi bị bỏ quên sẽ giảm xuống thấp nhất, nhƣng cũng sẽ không còn chi phí để tiếp tục dự án. Nếu bạn cắt giảm công việc kiểm thử thì chi phí cho nó sẽ ít, nhƣng bạn sẽ bỏ quên rất nhiều lỗi. Mục đích là bạn phải lọc ra số các trƣờng hợp kiểm thử tối ƣu, để đảm bảo bạn không phải kiểm thử quá nhiều hay quá ít các trƣờng hợp.

Hình 2.5: Mọi dự án phần mềm đều có một điểm nỗ lực kiểm thử tối ưu

Bạn sẽ đƣợc tìm hiểu làm thế nào để thiết kế và lựa chọn các kịch bản kiểm thử (test scenarios) sao cho ít rủi ro nhất và quá trình kiểm tra là tối ƣu nhất.

c) Quá trình kiểm thử không thể biểu diễn những lỗi không tồn tại

Hãy nghĩ về điều này trong chốc nát. Bạn là một “kẻ hủy diệt”  (exterminator) với bài kiểm tra các lỗi. Bạn xem xét hàng giờ và tìm ra dấu vết của các lỗi, lỗi này có thể vẫn đang tồn tại (live bug), đã đƣợc sửa (dead bug), hoặc còn đang tiềm ẩn (nest). Bạn có thể nói một cách an toàn rằng “the house has bugs”

Bạn đến thăm một “house” khác. Lần này, bạn không tìm thấy dấu vết của lỗi. Bạn hãy nhìn vào tất cả những địa điểm rõ ràng (obvious place) và tìm xem không có dấu hiệu nào của sự tàn phá. Có lẽ bạn nên tìm một vài lỗi đã từng đƣợc xử lý hoặc tiềm ẩn từ lâu, nhƣng bạn hãy coi nhƣ không thấy gì cả. Có thể bạn tuyên bố một cách chắc chắn rằng “the house is bug free”? Không. Kết luận cuối cùng, có thể bạn không tìm thấy một live bug nào cả. Ngƣợc lại, bạn tháo gỡ hoàn toàn the house thành foundation, bạn không thể chắc chắn rằng: bạn không bỏ quên một số lỗi đơn giản.

Tester làm việc chính xác nhƣ một “kẻ hủy diệt”. Nếu có thể biểu diễn những lỗi đang tồn tại, nhƣng không thể biểu diễn những lỗi không tồn tại. Bạn có thể thực hiện bài kiểm tra của bạn, tìm và báo cáo các lỗi, nhƣng bạn có thể kết luận rằng: lỗi không đƣợc tìm thấy nữa. Bạn có thể tiếp tục kiểm tra và khả năng tìm thấy lỗi là lớn hơn.

d) Những lỗi đƣợc tìm thấy và những lỗi không thể tìm thấy (The More Bugs You Find, the More Bugs There Are)

Thậm chí, có rất nhiều điểm tƣơng đồng giữa real bug và software bug. Cả hai loại này đều cần đƣa vào một nhóm. Thƣờng thì một tester sẽ chạy phần mềm nhƣ thể nó không có một lỗi nào. Sau đó, anh ta sẽ tìm ra một lỗi rồi những lỗi khác, lỗi khác nữa. Có một vài lý do cho điều này:

Các lập trình viên có những ngày thật tội tệ: Giống nhƣ tất cả chúng ra, những ngƣời lập trình có thể có những lúc không đƣợc minh mẫm lắm. Vào một thời điểm này code có thể đƣợc viết rất hoàn hảo, nhƣng lúc khác anh ta lại viết code rất cẩu thả. Một lỗi có thể là một dấu hiệu tell – tale rất quen thuộc.

Một lập trình viên thƣờng xuyên mắc những lỗi tƣơng tự nhau: Ai cũng có những thói quen. Một lập trình viên thiên về một loại lỗi nào đó mà thƣờng xuyên mắc đi mắc lại.

 

Một số lỗi thật sự nguy hiểm nhƣ đỉnh của một tảng băng trôi: Thƣờng thì trong các bản thiết kế và kiến trúc của phần mềm đều ẩn chứa một số vấn đề chƣa đƣợc phát hiện. Tester đã tìm đƣợc một số lỗi mà dƣờng nhƣ nó không liên quan đến nhau. Nhƣng không hẳn thế, những lỗi này lại có những quan hệ mật thiết với nhau và đều xuất phát từ một lý do chính vô cùng quan trọng.

Vấn đề quan trọng bây giờ là cần chú ý rằng ngƣợc với ý tƣởng “bugs follow bugs” này cũng có thể coi là đúng. Nếu bạn không thể tìm ra lỗi của phần mềm thì cũng không có vấn đề gì. Sẽ rất thuận lợi nếu các đặc trƣng mà bạn kiểm tra đƣợc viết một cách trong sáng và quả thực sẽ có một vài điều nếu nhƣ bất kỳ một lỗi nào đƣợc tìm ra.

e) Nghịch lý về thuốc trừ sâu (The Pesticide Paradox)

Vào năm 1990, Boris Beizer, trong cuốn sách Software Testing Techniques, tái bản lần 2, đã xây dựng thuật ngữ Pesticide Paradox để mô tả một hiện tƣợng bạn kiểm thử phần mềm. Những điều tƣơng tự với hiện tƣợng này đã xảy ra khi bạn dùng pesticides để diệt sâu bọ (mô tả trong hình 2.6). Nếu bạn liên tục dùng một loại pesticide giống nhau, sâu bọ sẽ kháng cự lại thuốc, và pesticide không còn hiệu quả nữa.

Hình 2.6: Phần mềm đã phải trải qua những phép thử lặp đi lặp lại tƣơng tự nhau để chống lại các lỗi

Hãy nhớ về mô hình xoắn ốc của quy trình phát triển phần mềm đƣợc mô tả trong bài 2. Quá trình kiểm thử cũng phải lặp đi lặp lại mỗi lần quanh vòng lặp. Với mỗi lần lặp lại, tester nhận phần mềm để kiểm tra và chạy các trƣờng hợp kiểm thử của họ. Cuối cùng, ngoài một vài trƣờng hợp phần mềm chạy đúng yêu cầu, thì các trƣờng hợp kiểm tra của tester sẽ tìm ra và phơi bày các lỗi. Nhƣng ở lần lặp sau, nếu tester vẫn tiếp tục chạy các trƣờng hợp kiểm thử này, chúng sẽ không giúp tìm ra lỗi mới. Để cách vƣợt qua pesticide paradox, tester phải viết thêm các trƣờng hợp kiểm thử khác nữa, và tìm những cách tiếp cận mới để kiểm tra chƣơng trình và tìm ra nhiều lỗi hơn.

f) Không phải tất cả các lỗi mà bạn phát hiện sẽ đƣợc sửa

Một trong những điều thật sự đáng buồn của kiểm thử phần mềm là sau tất cả những lỗ lực cố gắng làm việc của bạn, không phải tất cả các lỗi bạn phát hiện ra sẽ đƣợc sửa. Nhƣng điều này cũng không gây thất vọng bởi vì nó không có nghĩa rằng bạn đã làm sai điều gì khi cố gắng thực hiện mục đích của mình, cũng không có nghĩa rằng bạn cùng với cả đội của bạn sẽ phải chấp nhận giao cho khách hàng một sản phẩm kém chất lƣợng. Tuy nhiên, nó có nghĩa rằng, bạn sẽ cần dựa trên những cặp tiêu chí về nghề tester đã đƣợc liệt kê trong bài 1. Bạn và đội của bạn cần mô tả lại những quyết định dựa trên sự rủi ro cho riêng từng lỗi và cho tất cả các lỗi, để đƣa ra quyết định cái nào sẽ đƣợc sửa và cái nào thì không.

Có một số lý do khiến một số lỗi không đƣợc fix:

Không đủ thời gian: Trong mọi dự án luôn có rất nhiều feature của phần mềm, nhƣng bạn lại có quá ít ngƣời để viết mã và kiểm thử chúng, và cũng không đủ khả năng để thay đổi kế hoạch làm việc cho đến khi kết thúc. Nếu bạn đang làm việc cho một chƣơng trình đòi hỏi những thử thách lớn, mà thời hạn hoàn thành đã sắp đến thì bạn buộc phải bỏ qua một số lỗi

Nó không hẳn là một lỗi: Có lẽ bạn cũng đã từng nghe thấy thành ngữ sau: “it‟s not a bug, it‟s a feature!” Không phải là hiếm những trƣờng hợp: hiểu sai, lỗi do quá trình kiểm tra, hoặc đặc tả thay đổi dẫn đến kết quả có thể phát sinh lỗi trong tƣơng lai. Có quá nhiều rủi ro khi sửa lỗi: Thật không may điều này là quá thƣờng xuyên xảy đến. Phần mềm có thể rất dễ hỏng, các bộ phận gắn kết chặt chẽ với nhau, và đôi khi chúng giống nhƣ “món mì Ý”. Có thể bạn sửa một lỗi lại khiến một lỗi khác xuất hiện. Dƣới áp lực về thời gian hoàn thành sản phẩm, dƣới một lịch trình kín đặc, thì có lẽ thay đổi phần mềm là một quyết định chứa quá nhiều rủi ro. Có lẽ tốt hơn hết là bỏ qua những lỗi có thể chấp nhận đƣợc để tránh phát sinh những lỗi mới, những rủi ro mới.

Nó không đáng để phải sửa: điều này nghe có vẻ bất hợp lý, nhƣng nó là sự thật. Những lỗi hiếm khi xuất hiện hoặc những lỗi xuất hiện trong những feature ít sử dụng thì có thể bỏ qua đƣợc. Những lỗi “work- around”, tức là có cách để ngƣời sử dụng có thể ngăn chặn hoặc tránh đƣợc lỗi, thì thƣờng không đƣợc sửa. Tất cả các quyết định phải mang tính chất thị trƣờng dựa trên độ rủi ro.

Quá trình xử lý các quyết định này thƣờng bao gồm các tester, các project manager, các coder. Mỗi ngƣời sẽ có những cách nhận định về một viễn cảnh xảy ra khi một số lỗi không đƣợc sửa. Nếu lỗi không đƣợc fix, tester hiểu khách hàng sẽ phải gánh chịu những hậu quả nhƣ thế nào. Project manager có tầm nhìn chiến lƣợc và đoán nhận đƣợc những hậu quả có thể xảy ra với dự án khi lỗi không đƣợc giải quyết. Và coder hiểu đƣợc rằng nếu fix lỗi này thì chi phí cho việc đó sẽ lớn nhƣ thế nào. Dựa vào đó, họ sẽ đƣa ra những lý do tại sao họ nên sửa hoặc không nên sửa các lỗi đó.

CHUYỆN GÌ SẼ XẢY ĐẾN KHI BẠN ĐƯA RA MỘT QUYẾT ĐỊNH SAI:

Hãy nhớ lại về lỗi mà hãng Intel Pentium mô tả trong bài 1. Hãng Intel đã tìm ra lỗi này trƣớc khi sản phẩm đƣợc tung ra thị trƣờng, nhƣng đội phát triển sản phẩm đã quyết định rằng: nó là một lỗi quá nhỏ và không đáng để phải sửa. Họ có một lịch làm việc quá dày đặc và đã đến hạn hoàn thành sản phẩm. Vì vậy, họ đã quyết định việc sửa lỗi này sẽ đƣợc thực hiện trong phiên bản sau của chip.

Nhƣng thật không may, lỗi này đã bị khách hàng phát hiện ra. Trong một số khía cạnh của phần mềm, có thể có tới hàng trăm lỗi không đƣợc sửa bởi vì họ nhận thấy rằng hiệu quả tích cực của nó là không lớn. Vậy rất khó để có thể nói rằng các quyết định này là đúng hay sai.

g) Một lỗi có tồn tại nhƣng không ai phát hiện thì có phải là lỗi không? (When a Bug's a Bug Is Difficult to Say)

Nếu có một vấn đề trong phần mềm, nhƣng không một ai phát hiện ra nó, không phải lập trình viên, không phải một tester, và thậm chí là một khách hàng nào đó, thì nó có đƣợc gọi là lỗi không?

Một nhóm các tester ở trong một phòng và hỏi chúng tôi câu hỏi này. Bạn sẽ phải thảo luận về vấn đề này. Ai cũng có ý kiến riêng của mình và có thể là bạn cũng thế. Vấn đề ở đây là không có câu trả lời xác định. Câu trả lời phụ thuộc vào bạn và đội phát triển của bạn với việc đƣa ra những quyết định tốt nhất cho mình.

Với mục đích của cuốn sách này, bạn hãy tham khảo những quy tắc để xác định một lỗi trong bài 1:

Phần mềm không thực hiện một số thứ giống nhƣ mô tả trong bản đặc tả phần mềm Phần mềm thực hiện một số việc mà bản đặc tả yêu cầu nó không đƣợc thực hiện Phần mềm thực hiện một số chức năng mà bản đặc tả không đề cập tới

Phần mềm không thực hiện một số việc mà bản đặc tả không đề cập tới, nhƣng là những việc nên làm

Trong con mắt của ngƣời kiểm thử phần mềm là khó hiểu, khó sử dụng, chậm đối với ngƣời sử dụng

Quy tắc này sẽ giúp chúng ra lọc ra những tình huống khó xử để đƣa ra quyết định. Có một cách khác để suy xét nó. Không phải là hiếm những trƣờng hợp mà 2 ngƣời sử dụng có những nhận xét hoàn toàn trái ngƣợc nhau về vấn đề chất lƣợng phần mềm. Một ngƣời thì nói rằng chƣơng trình nhƣ vậy là không thể chấp nhận và ngƣời còn lại thì quả quyết rằng chƣơng trình này là hoàn hảo. Có thể cả hai đều đúng? Câu trả lời là một ngƣời sử dụng sản phẩm theo cách mà rất nhiều lỗi bị bộc lộ. Còn ngƣời kia thì không.

 

Chú ý: Lỗi không đƣợc khám phá hoặc chƣa từng đƣợc chú ý thì thƣờng đƣợc gọi là lỗi ngầm (latent bug)

Nếu điều này quá khó hiểu thì cũng đừng lo lắng. Hãy đem nó ra thảo luận với đồng nghiệp trong đội kiểm thử của bạn và cố gắng hiểu điều mà họ nghĩ. Hãy lắng nghe những ý kiến khác, kiểm tra ý tƣởng của họ và định hình lại suy nghĩ của chính mình. Hãy nhớ lại một câu hỏi quen thuộc: “ nếu một cái cây đổ trong rừng và không ai nghe thấy gì cả, vậy nó có tạo ra âm thanh không?” ("If a tree falls in the forest and there's no one there to hear it, does it make a sound?").

h) Xây dựng bản đặc tả phần mềm là công việc không bao giờ kết thúc

Phát triển phần mềm có một vấn đề. Ngành công nghiệp này đang phát triển quá nhanh: năm ngoái nó có thể là một sản phẩm sắc bén, nhƣng năm nay nó đã trở lên lỗi thời. Tại cùng một thời điểm, phần mềm có quy mô lớn hơn, có nhiều feature hơn và tƣơng đối phức tạp, dẫn đến kế hoạch phát triển sẽ lâu hơn. Có 2 vấn đề đối lập nhau, và kết quả là liên tục phải thay đổi bản đặc tả sản phẩm.

Không có cách nào khác để phản ứng lại sự thay đổi mau lẹ của bản đặc tả. Bạn cho rằng, sản phẩm của bạn đã bị khóa và chúng ta tuyệt đối không thể thay đổi bản đặc tả sản phẩm. Bạn đã đi đƣợc nửa chặng đƣờng trong kế hoạch phát triển 2 năm của sản phẩm, đối thủ chính của bạn thì đã tung ra thị trƣờng một sản phẩm hoàn toàn tƣơng tự với sản phẩm của bạn. Mà thậm chí một vài feature rất tuyệt vời mà sản phẩm của bạn không có đƣợc. Liệu bạn có nên tiếp tục với bản đặc tả của mình và giao cho khách hàng một sản phẩm thua kém hơn không? Hay đội phát triển dự án của bạn nên tập hợp lại, suy ngẫm lại về những feature của sản phẩm, viết lại bản đặc tả và làm việc trên một sản phẩm đƣợc sửa lại? Trong hầu hết các trƣờng hợp, những nhà kinh doanh sáng suốt sẽ tuyên bố sau cùng.

Là một tester, bạn phải thừa nhận rằng bản đặc tả sẽ thƣờng xuyên thay đổi. Các feature sẽ đƣợc thêm vào mà nó không hề nằm trong kế hoạch kiểm thử. Các feature sẽ thay đổi và thậm chí là bị xóa hoàn toàn khi bạn đã kiểm tra và sẵn sàng báo cáo lỗi về nó. Điều này hoàn toàn có thể xảy ra. Bạn sẽ đƣợc tìm hiểu các kỹ thuật linh hoạt để lập kế hoạch và thực thi việc kiểm thử trong phần còn lại của cuốn sách.

k) Tester không phải là thành viên đƣợc mọi ngƣời chờ đợi trong một dự án

Hãy nhớ lại mục đích của quá trình kiểm thử phần mềm là gì? Mục đích của một tester là tìm ra lỗi, tìm thấy chúng sớm nhất có thể, và chắc chắn rằng chúng phải được sửa.

Công việc của bạn là xem xét thật kỹ lƣỡng và phê bình công việc của các đồng nghiệp của bạn, phát hiện những vấn đề của công việc, và phải thực hiện công khai những gì bạn tìm thấy. Và bạn sẽ phải cố gắng chiến thắng trong các cuộc tranh luận với các đồng nghiệp.

Hãy giữ thái độ hòa bình với những đồng nghiệp trong đội của bạn:

Phát hiện lỗi thật sớm: Dĩ nhiên, đây là công việc của bạn, và bạn phải kiên trì làm công việc này. Và dĩ nhiên, nếu bạn phát hiện một lỗi nguy hiểm trƣớc 3 tháng thì tốt hơn là 1 ngày trƣớc khi đến thời điểm tung sản phẩm ra thị trƣờng.

Giữ thái độ hăng hái, nhiệt tình: Tốt thôi, bạn thật sự yêu công việc của mình. Bạn sẽ cảm thấy phấn khích khi bạn tìm đƣợc một lỗi khủng khiếp. Nhƣng nếu bạn huênh hoang dồn ép lập trình viên và nói với anh ta rằng bạn vừa mới tìm đƣợc một lỗi kinh khủng nhất (nastiest bug) trong suốt quá trình làm việc của bạn, thì chắc hẳn rằng anh ta sẽ cảm thấy khó chịu.

Đừng chỉ báo cáo những thông tin xấu: Nếu bạn đã phát hiện ra một đoạn mã chứa đầy lỗi, hãy nói cho mọi ngƣời biết, dù bạn sẽ bị phản đối. Bởi vì nếu bạn chƣa từng phát hiện ra lỗi của các lập trình viên, mọi ngƣời cũng sẽ tránh xa bạn.

i) Kiểm thử phần mềm là một công việc đòi hỏi tính kỷ luật

Kiểm thử phần mềm là công việc đƣợc thực hiện sau khi có sản phẩm. Các sản phẩm phần mềm và không phức tạp. Số lƣợng ngƣời với máy tính sử dụng phần mềm là bị giới hạn và một số ít lập trình viên trong đội dự án của bạn có khả năng gỡ lỗi cho mỗi đoạn mã của ngƣời khác. Các lỗi là một vấn đề không tốt.

Chúng xuất hiện và sớm đƣợc sửa chữa thì chi phí cho chúng sẽ không nhiều. Thƣờng thì các tester không đƣợc huấn luyện và họ vẫn phát huy khả năng của họ trong các dự án sau để làm thay đổi nhiều thứ.

Hãy nhìn xem sản phẩm phần mềm cần đƣợc giúp đỡ và bạn sẽ nhìn thấy một danh sách các tester. Ngành công nghiệp phần mềm đang phát triển vƣợt bậc với mũi nhọn là đội ngũ tester chuyên nghiệp. Bởi vì hiện tại, ngƣời ta đã mất quá nhiều chi phí để xây dựng lên những phần mềm kém chất lƣợng.

Thật là tội tệ, không phải mọi công ty đều thống nhất quan điểm đó. Nhiều computer game và những công ty phần mềm nhỏ vẫn thƣờng xuyên sử dụng những mô hình phát triển lỏng lẻo nhƣ big-bang hoặc code-and-fix. Nhƣng bây giờ, nhiều phần mềm đƣợc phát triển và luôn tuân thủ kỷ luật. Các tester trở thành lực lƣợng lòng cốt, những thành viên sống còn trong nhiệm vụ của họ.

Đây sẽ là một vấn đề lớn, nếu bạn là thấy hứng thú với kiểm thử phần mềm. Nó đã trở thành một nghề nghiệp đƣợc nhiều ngƣời lựa chọn và cần phải đƣợc đào tạo, làm việc có kỷ luật và thúc đẩy sự tiến bộ.

2.2.2. Các định nghĩa và thuật ngữ kiểm thử phần mềm

Bài này bao gồm một danh sách các thuật ngữ và các định nghĩa. Các thuật ngữ này mô tả những khái niệm nền tảng về quá trình phát triển phần mềm và kiểm thử phần mềm. Bởi vì chúng thƣờng rất lộn xộn và đƣợc sử dụng không hợp lý, chúng đƣợc định nghĩa ở đây nhƣ một cặp để giúp bạn hiểu ý nghĩa thật sự chúng và sự khác nhau giữa chúng. Hãy ý thức rằng nhiều ngƣời không bằng lòng về ngành công nghiệp phần mềm với những khái niệm của nhiều công ty, đƣợc phổ biến rộng rãi, (đó là các thuật ngữ). Là một tester, bạn nên thƣờng xuyên làm rõ ràng ý nghĩa của các thuật ngữ mà đội của bạn sử dụng. Thƣờng thì đây là cách tốt nhất để một khái niệm đƣợc đồng tình hơn là bạn phải cố gắng để mọi ngƣời chấp nhận rằng thuật ngữ đó là đúng.

Kiểm thử phần mềm (Software testing): Là một tiến trình thực hiện một chƣơng trình hoặc một ứng dụng với mục đích tìm kiếm các lỗi (bugs) phần mềm.

Các mục tiêu chính của kiểm thử phần mềm :

- Phát hiện càng nhiều lỗi càng tốt trong thời gian kiểm thử xác định trƣớc.

- Chứng minh rằng sản phẩm phần mềm phù hợp với các đặc tảyêu cầu của nó.

- Xác thực chất lƣợng kiểm thử phần mềm đã dùng chi phí và nỗ lực tối thiểu

- Tạo các testcase chất lƣợng cao, thực hiện kiểm thử hiệu quảvà tạo ra các báo cáo vấn đề đúng và hữu dụng.

Kiểm thử phần mềm là 1 thành phần trong lĩnh vực rộng hơn, đó là Verification & Validation (V &V), ta tạm dịch là Thanh kiểm tra và kiểm định phần mềm.

Verification (sự kiểm tra) và Validation (sự xác nhận) Verification và Validation thƣờng đƣợc sử dụng thay thế cho nhau nhƣng thực chất chúng là các khái niệm khác nhau. Sự khác nhau này rất quan trọng trong kiểm thử phần mềm.

Verification là quy trình xác nhận rằng một số khía cạnh của phần mềm là phù hợp với bản đặc tả của nó. Validation là quy trình xác nhận rằng phần mềm phù hợp với yêu cầu của ngƣời sử dụng.

Thanh kiểm tra (Verification) phần mềm là qui trình xác định xem sản phẩm của 1 công đoạn trong qui trình phát triền phần mềm có thoả mãn các yêu cầu đặt ra trong công đoạn trƣớc không (Ta có đang xây dựng đúng đắn sản phẩm không ?).

Thanh kiểm tra phần mềm thƣờng là hoạt động kỹ thuật vì nó dùng các kiến thức về các artifacts, các yêu cầu, các đặc tả rời rạc của phần mềm.

Các hoạt động Thanh kiểm tra phần mềm bao gồm kiểm thử (testing) và xem lại (reviews).

Kiểm định (Validation) phần mềm là qui trình đánh giá phần mềm ở cuối chu kỳ phát triển để đảm bảo sự bằng lòng sử dụng của khách hàng (Ta có xây dựng phần mềm đúng theo yêu cầu khách hàng ?).

Các hoạt động kiểm định đƣợc dùng để đánh giá xem các tính chất đƣợc hiện thực trong phần mềm có thỏa mãn các yêu cầu khách hàng và có thểtheo dõi với các yêu cầu khách hàng không ?

Kiểm định phần mềm thƣờng phụ thuộc vào kiến thức của lĩnh vực mà phần mềm xử lý.

Ví dụ kính thiên văn không gian Hubble (Hubble space telescope).

Vào tháng 4 năm 1990, Kính thiên văn không gian Hubble (Hubble space telescope) đƣợc đƣa vào quỹ đạo quanh trái đất. Là một thiết bị phản chiều, Hubble sử dụng một l tấm gƣơng lớn nhƣ một phƣơng tiện chính để khuếch đại đối tƣợng mà nó nhằm tới. Quá trình chế tạo tấm gƣơng này là đỏi sự chính xác và tập trung tuyệt đối. Kiểm tra tấm gƣơng rất khó, từ khi chiếc kính thiên văn này đƣợc thiết kế để sử dụng trong không gian và ngƣời ta không thể xác định đƣợc vị trí, thậm chí là nó có tầm nhìn xuyên suốt ngay cả khi nó vẫn ở trên trái đất. Với những lý do này thì chỉ có một cách kiểm tra tốt nhất là đo đạc cẩn thận tất cả các thuộc tính của nó và so sánh với những tiểu chuẩn đã đƣợc chỉ ra. Quá trình kiểm tra này đã đƣợc thực thi và Hubble đƣợc tuyên bố là đã sẵn sàng.

Nhƣng thật không may, ngay sau khi nó đƣợc đƣa vào quỹ đạo hoạt động, các bức ảnh nó gửi về không hề có trung tâm. Tổ chức điều tra đã khám phá ra rằng tấm gƣơng đã đƣợc chế tạo không hợp lý. Khi ở trên mặt đất, tấm gƣơng này đã đƣợc sản xuất theo đúng bản đặc tả, nhƣng bản đặc tả này lại sai. Tấm gƣơng vô cùng precise nhƣng nó không accurate. Quá trình kiểm tra đã xác nhận rằng tấm gƣơng đƣợc sản xuất đã đáp ứng đƣợc sự kiểm tra của bản đặc tả (spec verification), nhƣng nó không xác nhận đƣợc rằng nó đáp ứng đƣợc yêu cầu cơ bản (original requirement validation).

Năm 1993, một phái đoàn trên tài con thoi đã sửa kính thiên văn Hubble bằng cách cài đặt một “corrective len” để lấy lại trung tâm của những bức ảnh đƣợc chụp bởi Hubble.

Mặc dù không có một ví dụ về phần mềm, verification và validation áp dụng tốt nhƣ nhau với quá trình kiểm thử. Chứa từng có bản đặc tả nào là đúng. Nếu bạn thay đổi bản đặc tả và thông qua sản phẩm cuối cùng, thì bạn sẽ tránh đƣợc những vấn đề nhƣ với chiếc kính thiên văn Hubble.

Sai sót (error): Là một sự nhầm lẫn hau một sự hiểu sai trong quá trình phát triển phần mềm của ngƣời phát triển

Khiếm khuyết, lỗi (bug, defect, faults): Xuất hiện trong phần mềm nhƣ là một kết quả của một sai sót khi lập trình viên thiết kế và xây dựng chƣơng trình.

Hỏng hóc (failure): là kết quả của khiếm khuyết có trong ứng dụng hoặc sản phẩm, làm cho chƣơng trình không hoạt động đƣợc hay hoạt động nhƣng cho kết quả không nhƣ mong đợi.

Kiểm thử viên (Tester): Là ngƣời thực hiện kiểm thử

Ca kiểm thử (Test Case):

- Theo chuẩn IEEE 610 (1990) định nghĩa test case là một các dữ liệu đầu vào kiểm thử, các điều kiện thực hiện, và các kết quả mong đợi đƣợc phát triển cho một mục tiêu cụ thể nhƣ một đƣờng thực thi chƣơng trình hoặc xác minh sự tuân thủ với một yêu cầu xác định.

- Một test case là một tài liệu gồm có một tập dữ liệu test, các tiền điều kiện, các kết quả mong đợi và các hậu điều kiện, đƣợc phát triển cho một kịch bản test (Test scenario) cụ thể để xác minh sự tuân thủ một yêu cầu cụ thể.

Test case đóng vai trò nhƣ là điểm khởi đầu cho việc thực hiện kiểm tra và sau khi áp dụng một tập các giá trị đầu vào, ứng dụng có một kết quả nhất định và rời khỏi hệ thống tại một số điểm kết thúc hoặc đƣợc xem nhƣ hậu điều kiện thực hiện.

Các tham số điển hình của test case:

• Test Case ID

• Test Scenario

• Test Case Description

• Test Steps

• Prerequisite

• Test Data

• Expected Result

• Test Parameters

• Actual Result

• Environment Information

• Comments

 Ví dụ:

Chúng ta nói rằng chúng ta cần kiểm tra một trƣờng dữ liệu vào mà chấp nhận mƣời ký tự. Trong khi phát triển các test case cho kịch bản ở trên, các test case đƣợc tài liệu hóa nhƣ sau. Trong ví dụ dƣới, trƣờng hợp đầu là kịch bản qua (pass), kịch bản thứ hai là không qua (fail).

Nếu kết quả mong đợi không phù hợp nhƣ kết quả thực tế, thì chúng ta ghi nhận là một defect. Defect đó đi qua chu kỳ sống củadefect.

 

Một bộ test (Test Suite): Bộ test gồm có nhiều test. Nó có thể có một trong ba trạng thái Active, Inprogress và completed. Một test case có thể đƣợc thêm vào nhiều bộ test và kế hoạch test. Sau khi tạo test plan, test suit đƣợc tạo, trong test suit chứa

nhiều test case.

Hình 2.7. Quan hệ giữa ba khái niệm

Quality (chất lƣợng) và reliability (sự đáng tin cậy)

Trong cuốn từ điển của trƣờng cao đẳng Merriam-Webster đã định nghĩa rằng quality là “độ đo sự hoàn hảo” hoặc “sự vƣợt chội về thứ hạng”. Nếu sản phẩm phần mềm có chất lƣợng cao, nó sẽ đáp ứng đƣợc nhu cầu của khách hàng. Khách hàng sẽ cảm thấy sản phẩm hoàn hảo và nó sẽ đƣợc sắp thứ hạng cao hơn trong danh sách lựa chọn của khách hàng.

Tester có thể cảm thấy 2 khái niệm quality và reliability là gần nhƣ nhau. Họ cảm thấy rằng nếu nhƣ họ có thể kiểm tra một chƣơng trình cho đến khi nó chạy ổn định và có thể tin tƣởng đƣợc (realiability). Khi đó, họ có thể quả quyết rằng sản phẩm đã đạt chất lƣợng tốt. Nhƣng thật không may, điều này không hẳn đã đúng. Reliability chỉ là một khía cạnh của quality. Quan niệm về quality của ngƣời sử dụng phần mềm có thể bao gồm cả sự thoải mái của các feature, sản phẩm có khả năng chạy trên cả những PC cũ, dịch vụ hậu mãi của các công ty phần mềm, và thƣờng bao gồm cả giá cả của sản phẩm. Sự tin tƣởng hoặc cách thức mà phần mềm thâm nhập vào dữ liệu của khách hàng, có thể là rất quan trọng, nhƣng không phải lúc nào cũng thế.

Chắc rằng, với một chƣơng trình có chất lƣợng cao và đáng tin cậy, thì tester phải kiểm tra và thông qua trong suốt quá trình phát triển sản phẩm.

Testing (Kiểm thử) và Quality Assurance (đảm bảo chất lƣợng) (QA)

Cặp khái niệm cuối cùng là testing và quality assurance (có thể viết tắt là QA). Hai thuật ngữ này, một cái thƣờng đƣợc sử dụng để mô tả nhóm hoặc quá trình kiểm tra và xác nhận chất lƣợng phần mềm. Bạn sẽ đƣợc tìm hiểu nhiều hơn về thƣớc đo chất lƣợng phần mềm, nhƣng trƣớc tiên hãy xem xét những khái niệm sau:

Mục đích của testing là tìm ra lỗi, tìm thấy chúng sớm nhất có thể, và đảm bảo rằng chúng đã đƣợc sửa.

Trách nhiệm chính của ngƣời QA là tạo và bắt phần mềm phải tuân theo các chuẩn để cải tiến quy trình phát triển phần mềm và ngăn chặn các lỗi xuất hiện bất cứ lúc nào

Dĩ nhiên, 2 khái niệm này vẫn có sự chồng chéo nhau. Một số tester sẽ làm nhiệm vụ QA, một số thì thực thi việc kiểm tra. Hai công việc này cùng các nhiệm vụ của nó có quan hệ chặt chẽ với nhau. Tuy nhiên khó mà tránh khỏi sự lộn xộn giữa các thành viên làm nhiện vụ kiểm thử (testing) và các thành viên đảm bảo chất lƣợng phần mềm (QA).

2.2.3. Mô hình chữ V

Mô hình chữ V sẽ giúp chúng ta hình dung về quy trình test trong toàn bộ kế hoạch thực hiện dự án

Hình 2.8. V - Model

2.3. Quá trình nghiên cứu bản đặc tả phần mềm

Trong phần này chúng ta sẽ tìm hiểu:

- Khởi động

- Thực hiện duyệt ở mức cao của bản đặc tả

- Kỹ thuật kiểm thử bản đặc tả mức thấp

Bài này sẽ giúp bạn bắt tay kiểm thử một phần mềm thật sự đầu tiên nhƣng đó không phải là điều mà chúng ta mong chờ. Bạn sẽ không cài đặt và chạy phần mềm và bạn cũng không đập thình thịch vào bàn phím để hi vọng sẽ thấy phần mềm chạy sai. Trong bài này, bạn sẽ học cách làm thế nào để kiểm thử bản đặc tả của sản phẩm để tìm lỗi trƣớc khi chúng đƣợc chuyển thành một phần mềm.

Kiểm tra bản đặc tả không phải kiểm tra những thứ mà tất cả các tester cho rằng đó là công việc xa xỉ, không cần thiết. Đôi khi bạn đang ở giữa quá trình phát triển một dự án, sau khi bản đặc tả đã đƣợc viết và việc viết mã cũng đã bắt đầu, ngƣời ta phát hiện bản đặc tả không ổn. Nếu gặp hoàn cảnh này thì cũng đừng lo lắng, bạn vẫn có thể sử dụng các kỹ thuật đã đƣợc mô tả ở đây để kiểm tra bản đặc tả cuối cùng.

Nếu bạn không có đủ may mắn và lâm vào cảnh rắc rối với dự án ngay từ đầu và phải xem xét tới bản đặc tả sơ bộ, bài này sẽ dành cho bạn. Các lỗi đƣợc tìm kiếm tại giai đoạn này là tiềm năng giúp bạn tiết kiệm đƣợc một số lƣợng lớn tiền của và thời gian cho dự án của bạn.

Trọng tâm của bài này bao gồm:

- Thế nào kiểm thử black-box và white-box

- Kiểm thử static và dynamic khác nhau nhƣ thế nào

- Kỹ thuật mức cao nào có thể đƣợc sử dụng để duyệt lại một bản đặc tả phần mềm

- Vấn đề đặc biệt nào bạn nên tìm kiếm khi duyệt lại bản đặc tả chi tiết

2.3.1. Khởi đầu

Hãy nghĩ về 4 mô hình phát triển phần mềm đƣợc mô tả trong bài 2 “Quy trình phát triển phần mềm”: big-bang, code-and-fix, waterfall và spiral. Trong mỗi mô hình, ngoại trừ big-bang, đội phát triển phần mềm tạo ra một bản đặc tả (product specification) từ tài liệu yêu cầu của khách hàng (requirement document) để định nghĩa những cái mà phần mềm sẽ làm.

Điển hình, bản đặc tả sản phẩm là tài liệu đƣợc viết bằng word và có các bức tranh để mô tả sản phẩm dự định. Một trích dẫn từ bản đặc tả phần mềm Windows Calculator (trong hình 2.9) có thể đọc một số thứ giống nhƣ dƣới đây:

 

Hình 2.9: Phần mềm Windows Calculator chuẩn hiển thị menu drop-down Edit

Bạn có thể nhìn thấy rằng, phải mất một đoạn văn bản ngắn để mô tả về việc điều khiển 2 item menu trong một chƣơng trình Calculator đơn giản. Một bản đặc tả chi tiết và triệt để cho toàn bộ ứng dụng có thể phải dài hàng trăm trang.

Dƣờng nhƣ với cách viết nhƣ vậy, chúng ta đã tạo ra một văn bản quá tỉ mỉ cho một phần mềm đơn giản. Tại sao lại không để cho lập trình viên viết một phần mềm Calculator theo ý của anh ta? Vấn đề là bạn sẽ không thể có ý tƣởng nào là cuối cùng. Ý tƣởng của các lập trình viên sẽ hình thành nên phần mềm, chức năng nào nên có, và ngƣời sử dụng sẽ sử dụng nó nhƣ thế nào. Chỉ có cách đảm bảo rằng sản phẩm cuối cùng là cái mà khách hàng yêu cầu với kế hoạch hợp lý về những lỗ lực kiểm thử để mô tả thấu đáo sản phẩm trong một bản đặc tả.

Những thuận lợi khác có trong một bản đặc tả, và là nội dung cơ bản của bài này, một tester sẽ có một văn bản về các item để thực hiện kiểm tra. Bạn có thể tìm các lỗi trong chính văn bản đó trƣớc khi dòng mã đầu tiên đƣợc viết.

a) Kiểm thử black-box và white-box

Hai thuật ngữ mà các tester sử dụng để mô tả cách mà họ tiếp cận để kiểm thử phần mềm là kiểm thử black-box và kiểm thử white-box. Hình 2.10 biểu diễn sự khác nhau giữa 2 hƣớng tiếp cận này. Trong kiểm thử black-box, tester chỉ biết cái mà phần mềm giả định là thực hiện đƣợc và anh ta cũng không hề biết cách thức phần mềm hoạt động nhƣ thế nào. Nếu anh ta đƣa vào một dữ liệu chính xác, anh ta cần nhận đƣợc dữ liệu chính xác. Anh ta không hề biết làm cách nào và tại sao điều đó lại xảy ra.

Hình 2.10: Với kiểm thử black-box, tester không biết chi tiết về cách thức mà phần mềm làm việc

Lời khuyên: Đôi khi, kiểm thử black-box đƣợc quy về kiểm thử chức năng (function testing) hoặc kiểm thử về cách hoạt động (behavioral testing). Đừng có cố chạy theo những thuật ngữ đƣợc dùng trong thực tế. Đội của bạn có thể sử dụng những thuật ngữ khác đi. Công việc của bạn là phải hiểu những thuật ngữ này và cách mà chúng đƣợc sử dụng trong đội của bạn.

Hãy suy nghĩ về phần mềm Calculator đƣợc mô tả trong hình 4.1. Nếu bạn đƣa dữ liệu vào là 3.14159 và nhần nút Sqrt, bạn sẽ nhận đƣợc 1.772453102341.

Với kiểm thử black-box, không có vấn đề gì khi phần mềm thực hiện tính toán. Nó vừa thực hiện điều này. Là một tester, bạn có thể xác minh kết quả trên một Calculator đã đƣợc chứng thực khác và xác nhận rằng Windows calculator thực hiện chức năng này đúng.

Trong kiểm thử white-box (đôi khi còn đƣợc gọi là kiểm thử clear-box), tester có khả năng truy cập vào mã nguồn và có thể kiểm tra nó với các manh mối để giúp ích quá trình kiểm thử. Dựa trên những gì mà tester nhìn thấy, anh ta có thể xác định rằng những con số chính xác nào có thể gây lỗi và từ đó anh ta có thể thiết kế bài kiểm tra của mình dựa trên những thông tin này.

Chú ý: Kiểm thử white-box có nhiều rủi ro. Rất dễ dàng để phát sinh lỗi khi kiểm thử phần mềm 1 cách khách quan bởi vì bạn có thể thiết kế bài kiểm tra kết nối với điều khiển của mã.

b) Kiểm thử static và dynamic

Có 2 thuật ngữ khác cũng đƣợc sử dụng để mô tả cách phần mềm đƣợc kiểm tra là kiểm thử static và kiểm thử dynamic. Kiểm thử static quy về việc kiểm tra  một số thứ mà nó không phải đang đƣợc chạy, đang kiểm tra và đang duyệt lại nó. Kiểm thử dynamic là cái mà thông thƣờng bạn nghĩ về cách để kiểm tra, cách chạy và sử dụng phần mềm.

Sự giống nhau nhiều nhất của các thuật ngữ này là quy trình bạn đi xuyên qua khi kiểm tra một chiếc xe ô tô đã đƣợc sử dụng. Đá vào vỏ xe, kiểm tra lớp sơn và nhìn xuống dƣới mui xe là các kỹ thuật kiểm tra static. Nào hãy bắt đầu, lắng nghe tiếng động cơ, và đánh xe trên đƣờng là các kỹ thuật kiểm thử dynamic.

c) Kiểm thử static black-box: Kiểm tra bản đặc tả

Kiểm tra bản đặc tả là kiểm thử static black-box. Bản đặc tả là một tài liệu, không phải là một chƣơng trình đang chạy, vì vậy mà nó đƣợc xem xét tĩnh (static). Nó cũng có thể là một số thứ đƣợc tạo ra sử dụng dữ liệu từ nhiều đề tài nghiên cứu tiện dụng, các nhóm trọng tâm, đầu vào mang tính thị trƣờng… Bạn không cần phải biết làm cách nào và tại sao các thông tin này lại đƣợc sử dụng hoặc các chi tiết của quá trình xử lý đã sử dụng nó. Chúng đƣợc tóm tắt lại trong một bản đặc tả sản phẩm. Sau đó, bạn có thể nắm bắt đƣợc tài liệu này, thực thi việc kiểm thử static black-box, và nghiên cứu cẩn thận về các lỗi.

Ở ngay phần đầu, bạn đã quan sát một ví dụ về bản đặc tả sản phẩm cho phần mềm Windows Calculator. Ví dụ này đã sử dụng một tài liệu đƣợc viết rất chuẩn với một bức tranh mô tả về cách thức hoạt động của phần mềm. Mặc dù đây là cách thức rất phổ biến cho việc viết một bản đặc tả, có nhiều sự thay đổi. Đội phát triển dự án của bạn có thể làm nổi bật biểu đồ dựa trên các từ hoặc nó có thể sử dụng một ngôn ngữ máy self-document ví dụ nhƣ Ada. Với bất kể lựa chọn nào của họ, bạn vẫn có thể áp dụng tất cả các kỹ thuật biểu diễn trong bài này. Bạn sẽ phải thiết kế chúng dựa trên định dạng của bản đặc tả mà bạn có, nhƣng ý tƣởng vẫn giống nhƣ vậy.

Bạn phải làm gì nếu dự án của bạn không có một bản đặc tả? Có thể đội của bạn đang sử dụng mô hình big-bang hoặc một mô hình code-and-fix không chặt chẽ lắm. Là một tester, đây là một vị trí khác. Mục đích của bạn là tìm ra các lỗi sớm nhất có thể, trƣớc khi phần mềm đƣợc viết code. Nhƣng nếu nhƣ sản phẩm của bạn không có một bản đặc tả, dƣờng nhƣ điều này là không thể đƣợc. Mặc dù, bản đặc tả có thể không đƣợc viết ra, một ai đó, hoặc một vài ngƣời, biết cái thứ mà họ đang cố gắng để xây dựng. Có thể đó là ngƣời phát triển phần mềm, là một quản trị dự án, hoặc là một thƣơng gia. Sử dụng chúng nhƣ khi đi dạo, nói chuyện, đặc tả sản phẩm và áp dụng các kỹ thuật giống nhƣ đánh giá đánh giá bản đặc tả tinh thần này (mental specification), mặc dù nó đƣợc viết trên giấy. Thậm chí, bạn có thể từng bƣớc ghi lại các thông tin và tụ họp lại để tính toán lại nó.

Hãy nói với đội dự án của bạn, “Đây là cái mà tôi lập kế hoạch để kiểm tra và đệ trình lại các lỗi”. Bạn sẽ hết sức ngạc nhiên rằng có bao nhiêu chi tiết, họ sẽ ngay lập tức điền đầy nó.

Lời khuyên: Bạn có thể kiểm tra một bản đặc tả với các kỹ thuật static black-box mà không có vấn đề gì về định dạng của bản đặc tả. Nó có thể là văn bản viết hoặc tài liệu mô tả hoặc cả hai. Thậm chí, bạn có thể kiểm tra một bản đặc tả không đƣợc viết, mà chỉ gồm các câu hỏi của những ngƣời đang thiết kế và viết phần mềm

2.3.2. Thực thi quá trình xem xét bản đặc tả ở mức cao

Định nghĩa một sản phẩm phần mềm là một quy trình rất khó. Bản đặc tả phải đề cập đến rất nhiều thứ chƣa đƣợc biết tới, nó bao gồm vô số dữ liệu đầu vào thay đổi liên tục, và cố gắng lôi kéo tất cả chúng vào một tài liệu mô tả một sản phẩm mới. Quá trình này là một hệ thống kiến thức không mang tính khuôn mẫu và ấp ủ nhiều vấn đề.

Trong bƣớc đầu tiên của việc kiểm thử là xem xét bản đặc tả là không đƣợc phép bỏ qua và tìm kiếm các lỗi cụ thể. Bƣớc đầu tiên là đứng sau và xem xét nó ở mức cao. Kiểm tra bản đặc tả với những vấn đề lớn, giám sát và bỏ quên một số thứ. Bạn cũng có thể xem xét và nghiên cứu kỹ hơn về kiểm thử, nhƣng cuối cùng thì sự nghiên cứu này cũng chỉ là một một công cụ để hiểu kỹ hơn về cái mà phần mềm nên làm. Nếu bạn hiểu rõ hơn là tại sao và nhƣ thế nào về bản đặc tả, bạn sẽ thấy tốt hơn về việc kiểm thử một cách chi tiết.

a) Giả sử bạn là một khách hàng

Điều dễ chịu nhất dành cho một tester là khi anh ta nhận một bản đặc tả để duyệt và anh ta sẽ đƣợc đóng vai trò nhƣ một khách hàng. Anh ta sẽ phải làm một số nghiên cứu về những khách hàng tiềm năng. Hãy nói chuyện với những ngƣời quảng bá sản phẩm của bạn và những ngƣời bán hàng để nhận đƣợc từ họ những gợi ý về nhu cầu của khách hàng. Nếu sản phẩm là một phần mềm nội bộ, hãy xác định xem ai sẽ sử dụng nó và nói chuyện với họ.

Điều quan trọng là bạn phải hiểu đƣợc những mong muốn của khách hàng. Hãy nhớ rằng chất lƣợng (quality) có nghĩa là “đáp ứng đƣợc những nhu cầu của khách hàng”. Là một tester, bạn phải hiểu những nhu cầu đó để kiểm tra xem phần mềm đã có những gì. Để thực hiện hiệu quả không có nghĩa rằng bạn phải bạn phải là một chuyên gia trong lĩnh vực vật lý hạt nhân nếu bạn đang kiểm thƣ cho một power plant. Hoặc bạn phải là một phi công chuyên nghiệp nếu bạn đang kiểm tra một phần mềm mô phỏng các chuyến bay. Nhƣng nếu bạn có những hiểu biết nhất định về lĩnh vực của phần mềm bạn đang kiểm thử thì cũng sẽ giúp bạn rất nhiều.

 

Với tất cả những cái khác thì không có gì cả. Nếu bạn phải xem xét một phần của bản đặc tả và không hiểu gì về nó, thì đừng cho rằng nó là một bản đặc tả tốt và tiếp tục làm việc. Cuối cùng, bạn vẫn phải sử dụng bản đặc tả này để thiết kế các trƣờng hợp kiểm thử của bạn. Vì vậy mà rút cuộc thì bạn vẫn phải hiểu nó. Không có thời điểm nào tốt hơn để tìm hiểu về nó nhƣ bây giờ. Nếu bạn tìm thấy lỗi theo cách này, tất cả sẽ ổn.

Lời khuyên: Đừng quên chú ý tới khả năng bảo mật của phần mềm khi bạn đóng vai trò là một khách hàng. Khách hàng sẽ tin rằng phần mềm là đảm bảo, nhƣng bạn có thể biết rằng lập trình viên sẽ phải bàn về vấn đề bảo mật một cách hợp lý.

b) Nghiên cứu về những chuẩn đã có sẵn và đƣờng lối chỉ đạo

Hãy trở về với thời kỳ đầu của Microsoft Windows và Apple Macintosh, những sản phẩm phần mềm đầu tiên có một giao diện sử dụng rất khác biệt. Chúng có các màu sắc khác nhau, cấu trúc menu khác nhau, các cách không giới hạn để mở một file và vô số những lệnh khó hiểu để thực hiện các nhiệm vụ giống nhau. Để chuyển từ việc sử dụng phần mềm này sang phần mềm khác đòi hỏi bạn phải đƣợc đào tạo lại hoàn toàn.

Nhƣng thật may mắn, ngƣời ta đã cố gắng để chuẩn hóa phần cứng và phần mềm. Họ đã tổ chức một cuộc nghiên cứu trên phạm vi lớn về cách mọi ngƣời sử dụng máy tính. Kết quả là ngày nay chúng ra có những sản phẩm có cách dùng rất gần gũi với nhau và thân thiện với ngƣời dùng. Bạn có thể thảo luận về những standard đã đƣợc thông qua và guideline không phải là hoàn hảo, có những cách rất tốt để hoàn thành nhiệm vụ một cách xuất sắc, nhƣng hiệu quả đƣợc cải tiến rất nhiều vì sự tƣơng đồng này. Bây giờ bạn nên tự xem xét xem những chuẩn (standard) và đƣờng nối (guideline) nào có thể áp dụng vào sản phẩm của bạn.

Chú ý: Sự khác nhau giữa các chuẩn (standards) và đƣờng lối (guidelines) là về mức độ quan trọng. Một standard có tính bền vững hơn một guideline. Nên tuân theo các standard một cách chặt chẽ nếu nhƣ đội của bạn đƣợc chỉ thị rằng: điều quan trọng là phải tuân theo chúng một cách đầy đủ. Guideline thì không bắt buộc nhƣng cũng nên tuân theo. Cũng không ít trƣờng hợp các đội quyết định dùng các standard lâu dài nhƣ một guideline. Mọi ngƣời cho rằng đó là một kế hoạch.

Có một vài ví dụ về các standard và các guideline đƣợc xem xét. Đây không phải là danh sách cuối cùng. Bạn nên nghiên cứu những cái có thể bạn sử dụng cho phần mềm của bạn:

- Các thuật ngữ và các quy ƣớc của các tổ chức (Corporate Terminology and Conventions): Nếu phần mềm này là để đáp ứng nhu cầu cho một công ty cụ thể, nó sẽ trở thành các quy ƣớc và thuật ngữ chung đƣợc các nhân viên trong công ty đó sử dụng.

- Nhu cầu của ngành công nghiệp (Industry Requirements): Các ngành tài chính, công nghiệp, dƣợc và y học có những tiêu chuẩn rất nghiêp ngặt mà buộc các phần mềm của họ phải tuân theo.

- Chuẩn về chính quyền (Government Standards): Chính phủ, đặc biệt là là lực lƣợng vũ trang, có những tiêu chuẩn rất nghiêm ngặt (strict standards)

- Giao diện đồ họa ngƣời dùng (Graphical User Interface - GUI): Nếu nhƣ phần mềm của bạn chạy dƣới hệ điều hành Microsoft Windows hoặc Apple Macintosh thì sẽ có những standard và guideline đƣợc công bố để đạt đƣợc những yêu cầu về sự nhìn nhận và cảm nghĩ (look and feel) của ngƣời dùng về phần mềm.

- Tiêu chuẩn về sự bảo mật (Security Standards): Phần mềm của bạn, giao diện và những giao thức của nó có thể cần đảm bảo đạt đến những chuẩn về bảo mật hoặc đạt các mức độ (levels). Cũng có thể nó cần đƣợc chứng nhận một cách độc lập những thứ mà nó có thể làm đƣợc, và những tiêu chuẩn mà nó đạt đƣợc.

Là một tester, công việc của bạn không phải là vạch rõ những guideline nào và standard nào nên áp dụng cho phần mềm của bạn. Việc đó là của những ngƣời quản lý dự án hoặc thậm chí là của những ngƣời đang viết bản đặc tả. Tuy nhiên,

 

bạn nên tự điều tra để phục vụ việc kiểm thử của mình sao cho phần mềm đảm bảo đạt chuẩn và mọi ngƣời đều nhận thấy điều đó. Bạn cũng phải có những kiến thức về standard này và kiểm tra lại chúng khi bạn xác minh và công nhận phần mềm. Xem chúng nhƣ một phần của bản đặc tả.

c) Xem xét và kiểm tra những phần mềm tƣơng tự

Một trong những cách thức tốt nhất để tìm hiểu cái mà phần mềm của bạn cần đạt đến là nghiên cứu những phần mềm tƣơng tự. Đó cũng có thể là một phần mềm của công ty đang cạnh tranh với công ty bạn hoặc là một số sản phẩm tƣơng tự của chính công ty bạn. Một số điều cần lƣu ý khi xem xét các sản phẩm đang cạnh tranh với phần mềm của bạn:

- Tỷ lệ (scale): Các feature sẽ nhiều hơn hay ít hơn? Code sẽ ít đi hay nhiều hơn? Những sự thay đổi này sẽ là nội dung trong công việc kiểm thử của bạn?

- Sự phức tạp (complexity): Phần mềm của bạn sẽ phức tạp hơn hay đơn giản hơn? Điều này cũng sẽ ảnh hƣởng tới công việc kiểm thử của bạn chứ?

- Khả năng kiểm thử (testability): Bạn sẽ có tài nguyên, thời gian, và chuyên môn để kiểm thử phần mềm nhƣ vậy không?

- Chất lƣợng / tính tin cậy (quality / reliability): Đây có phải là phần mềm tiêu biểu cho chất lƣợng các phần mềm của bạn. Liệu phần mềm của bạn có đáng tin cậy hơn trƣớc không?

- Bảo mật (security): Độ bảo mật của phần mềm cạnh tranh với công ty bạn nhƣ thế nào, cả những lời quảng cáo và sự thật, so sánh để thấy đƣợc mức mà bạn đề nghị?

Không gì có thể thay thế đƣợc kinh nghiệm truyền tay (hands-on experience), vì vậy khi làm bất sản phẩm nào bạn nên xem xét những phần mềm tƣơng tự, sử dụng nó, đánh giá những phần hoàn hảo nhất của nó, và đặt nó vào trong hoàn cảnh của chính nó. Bạn sẽ thu thập đƣợc rất nhiều kinh nghiệm. Nó sẽ giúp ích rất nhiều cho bạn khi bạn kiểm thử một cách chi tiết bản đặc tả của mình.

Lời khuyên: Đừng quên tìm kiếm những tài liệu trên mạng, xem xét các tài liệu về phần mềm và các bài báo về đối thủ của bạn. Điều này có thể đặc biệt có ích cho vấn đề bảo mật. Bạn không muốn thấy những lỗ hổng bảo mật nhƣ ở những phần mềm bạn đã từng sử dụng.

2.3.3. Kỹ thuật kiểm thử đặc tả mức thấp

Sau khi bạn hoàn thành thao tác kiểm tra mức cao của bản đặc tả sản phẩm, bạn sẽ hiểu kỹ hơn về cái mà sản phẩm của bạn có đƣợc và những vấn đề gây ảnh hƣởng cuối cùng tới thiết kế của bạn. Ngụy trang với các thông tin này, bạn có thể tiếp tục kiểm thử ở mức thấp hơn. Phần còn lại của bài này giải thích bản đặc tả làm gì.

a) Danh mục những thuộc tính của bản đặc tả

Thật là tốt, bản đặc tả đƣợc cân nhắc kỹ, với "all its t's crossed and its i's dotted", có 8 thuộc tính quan trọng:

- Hoàn thiện (complete): Có chỗ nào còn lỗi hoặc bị bỏ quên không? Phần mềm đã triệt để chƣa? Có phải nó bao gồm mọi thứ cần thiết để nó có thể đứng độc lập không?

- Chính xác (accurate): Giải pháp đƣợc đề xuất có đúng không? Nó có xác định đƣợc mục đích một cách hợp lý không? Có còn tồn tại lỗi nào không?

- Rõ ràng, chính xác, không mập mờ và trong sáng (Precise, Unambiguous, and Clear): Mô tả có chính xác, rõ ràng không? Những lời giải thích có làm sáng tỏ vấn đề không? Có dễ đọc, dễ hiểu không?

- Nhất quán (consistent): Lời mô tả cho những feature đã đƣợc viết không đƣợc mâu thuẫn với chính nó hoặc những mục khác trong bản đặc tả.

- Mối quan hệ (relevant): Có những mô tả cần thiết để chỉ định ra các đặc trƣng không? Nó có phải là những thông tin mở rộng nên bỏ bớt đi không? Có phải feature là những cái mô tả nhu cầu cơ bản của khách hàng không?

- Khả thi (Feasible): có phải feature có thể đƣợc thực thi với nguồn nhân lực đã có sẵn, các công cụ, và tài nguyên trong lịch trình và nguồn ngân sách đã đƣợc chỉ định

- Mã nguồn mở (code - free): Có phải bản đặc tả chỉ định sản phẩm và những thứ không nằm phía dƣới bản thiết kế, kiến trúc và mã của phần mềm. Bản đặc tả chỉ rõ những phần dùng mã nguồn mở, nguồn gốc của những code này

- Khả năng kiểm thử (testable): Các feature có cần đƣợc kiểm thử không? Thông tin liệu có đủ để cung cấp cho tester để họ thực hiện quá trình xác minh những điều khiển của phần mềm không?

Khi bạn đang kiểm tra một bản đặc tả sản phẩm, đọc những đoạn văn bản, kiểm tra những hình vẽ của nó, xem xét cận thận từng đặc điểm một. Bạn hãy tự hỏi chính bản thân mình về từ ngữ và những bức hình mà bạn đang kiểm tra. Nếu chúng không đáp ứng đƣợc yêu cầu thì bạn đã tìm thấy lỗi

b) Danh mục những thuật ngữ đặc tả

Bổ sung cho danh sách những thuộc tính là một loạt các từ ngữ về các vấn đề cần đƣợc quan tâm trong khi xem xét bản đặc tả. Sự xuất hiện của những từ này báo hiệu rằng feature không đƣợc trọn vẹn. Hãy tìm kiếm những từ này trong bản đặc tả và cẩn thận xem xét chúng đƣợc sử dụng trong hoàn cảnh nào. Bản đặc tả có thể lọc ra hoặc trau chuốt cho chúng, hoặc có thể loại những từ ngữ không rõ ràng, mơ hồ ra khỏi bản đặc tả.

- Luôn luôn, mọi thứ, tất cả, không một ai, không bao giờ (Always, every, all, none, never): Nếu bạn nhìn thấy những từ kiểu nhƣ vậy là bản đặc tả muốn nói đến những khẳng định chắc chắn. Là một tester, bạn hãy đặt ra những tình huống không đúng với những khẳng định đó.

- Tất nhiên, bởi vậy, chắc hẳn rồi, hiển nhiên, rõ ràng (Certainly, Therefore, Clearly, Obviously, Evidently): Những từ này có khuynh hƣớng làm cho bạn tin tƣởng và chấp nhận những điều mà họ đƣa ra. Đừng rơi vào những tình trạng đó.

- Vân vân, và cứ tiếp tục ở phía trƣớc, và cứ tiếp tục nhƣ vậy, ví dụ (Etc., And So Forth, And So On, Such As): Đây là danh sách những từ mà chúng ta không có khả năng kiểm tra đƣợc. Những từ ngữ này cần đƣợc khẳng định và giải thích để tránh sự lôn xộn, để kiểm soát xem chuỗi tiếp theo đƣợc sinh ra nhƣ thế nào và cài gì xuất hiện tiếp theo.

- Tốt, nhanh, rẻ, hiệu quả, nhỏ gọn, ổn định (Good, Fast, Cheap, Efficient, Small, Stable): Có một số thuật ngữ không đủ điều kiện để đƣợc sử dụng. Không thể kiểm tra đƣợc độ chính xác của chúng. Nếu thấy chúng xuất hiện trong một bản đặc tả bạn phải chỉ định thêm những lời giải thích chính xác xem chúng là gì.

- Danh hiệu, quy trình, loại bỏ, bỏ qua, loại trừ (Handled, Processed, Rejected, Skipped, Eliminated): Những thuật ngữ này ẩn dấu một số lƣợng lớn các chức năng mà cần phải đƣợc chỉ rõ.

- Nếu … thì … nhƣng không có trƣờng hợp còn lại (If…Then…but missing Else): hãy tìm những lời thông báo dạng mệnh đề “nếu… thì…” nhƣng không có vế còn lại. Hãy tự đặt câu hỏi: cái gì sẽ xảy đến nếu nhƣ trƣờng hợp “nếu…” không xảy ra.

Tổng kết:

 

- Tất nhiên, bởi vậy, chắc hẳn rồi, hiển nhiên, rõ ràng (Certainly, Therefore, Clearly, Obviously, Evidently): Những từ này có khuynh hƣớng làm cho bạn tin tƣởng và chấp nhận những điều mà họ đƣa ra. Đừng rơi vào những tình trạng đó.

- Vân vân, và cứ tiếp tục ở phía trƣớc, và cứ tiếp tục nhƣ vậy, ví dụ (Etc., And So Forth, And So On, Such As): Đây là danh sách những từ mà chúng ta không có khả năng kiểm tra đƣợc. Những từ ngữ này cần đƣợc khẳng định và giải thích để tránh sự lôn xộn, để kiểm soát xem chuỗi tiếp theo đƣợc sinh ra nhƣ thế nào và cài gì xuất hiện tiếp theo.

- Tốt, nhanh, rẻ, hiệu quả, nhỏ gọn, ổn định (Good, Fast, Cheap, Efficient, Small, Stable): Có một số thuật ngữ không đủ điều kiện để đƣợc sử dụng. Không thể kiểm tra đƣợc độ chính xác của chúng. Nếu thấy chúng xuất hiện trong một bản đặc tả bạn phải chỉ định thêm những lời giải thích chính xác xem chúng là gì.

- Danh hiệu, quy trình, loại bỏ, bỏ qua, loại trừ (Handled, Processed, Rejected, Skipped, Eliminated): Những thuật ngữ này ẩn dấu một số lƣợng lớn các chức năng mà cần phải đƣợc chỉ rõ.

- Nếu … thì … nhƣng không có trƣờng hợp còn lại (If…Then…but missing Else): hãy tìm những lời thông báo dạng mệnh đề “nếu… thì…” nhƣng không có vế còn lại. Hãy tự đặt câu hỏi: cái gì sẽ xảy đến nếu nhƣ trƣờng hợp “nếu…” không xảy ra.

 

Bây giờ bạn phải hiểu sản phẩm phần mềm tạo ra nhƣ thế nào, cái gì bên trong chúng và quy trình đƣợc sử dụng để liên kết chúng với nhau. Cũng nhƣ bạn có thể nhìn thấy, không có một hƣớng tiếp cận xác định. Bốn mô hình mô tả ở đây chỉ là ví dụ. Có nhiều mô hình khác nữa và biến thể của chúng. Mỗi công ty, mỗi dự án và mỗi đội sẽ chọn mô hình phù hợp với họ. Đôi khi, họ lựa chọn đúng, nhƣng thỉnh thoảng họ cũng sẽ lựa chọn sai. Công việc của bạn là kiểm tra phần mềm để nó làm việc tốt nhất trong mô hình phát triển của nó, áp dụng các kỹ năng kiểm thử trong phần còn lại của cuốn sách để tạo ra những phần mềm tốt nhất có thể đƣợc.