Giáo trình

Đảm bảo chất lượng phần mềm

Science and Technology

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

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 3.1, phần mềm Microsoft Windows Calculator.

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 BackspaceDelete. 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 3.2 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.

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 chô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 3.3). 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.

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:

  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
  2. 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
  3. 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
  4. 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
  5. 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ộ.

Mục lục
Đánh giá:
0 dựa trên 0 đánh giá
Nội dung cùng tác giả
 
Nội dung tương tự