Đã đăng vào thg 4 18, 2019 4:12 CH 21 phút đọc

151

Characteristics of a Bad Software Tester

Bài đăng này đã không được cập nhật trong 5 năm

Nếu bạn là một Tester chắc hẳn bạn đã từng tự đặt câu hỏi cho bản thân là "Làm thế nào để trở thành một Good Tester?" rồi nhỉ.

Vậy có bao giờ bạn từng hỏi ngược lại là "Làm thế nào để không trở thành một Bad Tester?" chưa? Vì không ai mong mình sẽ trở thành một bad tester cả đúng không ạ?

Câu hỏi đặt ra là tính cách nào có thể làm cho bạn trở thành một Bad Software Tester?

Mọi người đều mong muốn những đặc tính và yếu tố tích cực được thực thi trong sự nghiệp hoặc cuộc sống của họ nhưng không ai tập trung vào những đặc tính và phẩm chất mà họ cần phải tránh trong sự nghiệp của họ cả.

Về cơ bản thì việc nhận ra các điều tiêu cực mà sẽ hủy hoại sự nghiệp của bạn sẽ giúp bạn trở thành một người tốt hơn.

Trong bài viết này, chúng ta sẽ xem xét một cách sâu xa về các đặc tính mà làm cho một tester trở thành một “bad tester”. Từ đó có thể tránh đưa chúng vào trong sự nghiệp kiểm thử để mang lại cho chúng ta những điều tốt đẹp nhất.

Tổng quát

Trong SDLC, kiểm thử là một giai đoạn quan trọng trước khi phần mềm được đưa vào môi trường thật (hay nói cách khác là được đưa ra thị trường), mọi dự án đều đi qua nhiều giai đoạn kiểm thử trước khi nó được đưa tới tay người dùng cuối.

Hãy tưởng tượng xem chất lượng sản phẩm sẽ ra sao nếu như không có giai đoạn kiểm thử và nếu như phần mềm được triển khai mà không có kiểm thử, và nó sẽ đáp ứng được yêu cầu của khách hàng như thế nào? Do đó, để có thể kiểm thử một phần mềm, chúng ta cần “good testers”. Làm thế nào để xác định được một good tester hay không?

Theo tôi thì, good testers là những người có kiến thức sâu rộng, khả năng học hỏi nhanh, thái độ tích cực, tìm ra nhiều lỗi và điều tra chúng một cách chủ động, v.v. (Có khá nhiều các đặc tính khác nữa nhưng tôi chỉ liệt kê vài cái tiêu biểu). Một kiểu tester mà luôn làm cho bất kỳ dự án nào cũng thành công.

Bây giờ hãy xét ngược lại, một nhóm dự án bao gồm bad testers. Một lần nữa theo những gì tôi biết thì, bad testers là những người có phẩm chất như thiếu thái độ tích cực, giao tiếp kém, kỹ năng trì trệ, v.v.

Các đặc tính của một Bad Tester

Dưới đây là một vài đặc tính mà khiến cho bất kỳ tester nào cũng có thể trở thành một a “bad tester”:

1) Giao tiếp kém

Khi kiểm thử được bắt đầu sớm trong SDLC, trong quá trình phân tích yêu cầu, vai trò của người kiểm tra rất quan trọng và khách hàng đang mong đợi đầu vào từ họ. Do đó, các testers cần có kỹ năng giao tiếp tốt để có thể cung cấp cho khách hàng những thông tin chi tiết một cách súc tích và rõ ràng.

Không chỉ trong giai đoạn đầu mà còn xuyên suốt trong quá trình phát triển dự án, tester nên giao tiếp một cách hiệu quả bằng cách sử dụng lời nói hoặc email với khách hàng, nhóm phát triển hoặc bất kỳ nhóm nào khác.

Danh sách dưới đây nhấn mạnh một vài điểm mà nó góp phần làm cho việc giao tiếp của tester trở nên kém hiệu quả:

Không hiểu rõ yêu cầu và kiến thức kỹ thuật
Thiếu năng lượng để giao tiếp
Sợ bị từ chối đầu vào hoặc những suy nghĩ của mình (đại loại là sợ ý kiến của mình không được chấp nhận)
Sự đa dạng văn hóa
Cảm thấy dễ bị tổn thương
Thiếu sự chuẩn bị

2) Thiếu kiến thức kỹ thuật

Cùng với việc giao tiếp giỏi, nếu như một tester có kiến thức kỹ thuật về phần mềm thì nó sẽ tạo ấn tượng tốt với các bên khác nhau mà có liên quan đến dự án. Nếu một tester không có hoặc có ít kiến thức kỹ thuật thì đó là một nghi ngờ về chất lượng của phần mềm.

Và đôi khi trong các cuộc thảo luận nhóm, các developer sử dụng những thuật ngữ kỹ thuật và nói nhiều hơn về các công cụ kỹ thuật về dự án dẫn tới các tester sẽ khó hiểu và dẫn tới ảnh hưởng lớn đến dự án .

Dưới đây là danh sách các yếu tố ảnh hưởng tới kiến thức kỹ thuật:

Thiếu chương trình đào tạo ở nơi làm việc
Giảng viên thiếu trình độ
Thiếu thái độ học tập.
Thiếu thực hành.
Thiếu năng lượng hoặc sự nhiệt tình.

3) Báo cáo một lỗi mà không có sự phân tích

Trong quá trình kiểm thử, tester phải báo cáo lỗi / sự cố ngay lập tức khi mà họ nhận thấy rằng kết quả thực tế không đáp ứng yêu cầu. Báo cáo lỗi là quan trọng nhưng mà trước đó, tester nên điều tra nguyên nhân gây ra lỗi là gì.

Vì vậy, nó thường là một cách tiếp cận tốt để điều tra nguyên nhân của lỗi và nếu có thể thực hiện một kiểm thử hai lần trước khi báo cáo lỗi nào đó. Người kiểm tra không nên báo cáo bất kỳ vấn đề nào được xác định trong quá trình kiểm thử như là một lỗi, thay vào đó họ nên phân tích và điều tra vấn đề trước khi báo cáo đó là một lỗi.

Dưới đây là các yếu tố mà bạn cần phân tích trước khi báo cáo bất kỳ lỗi nào và chúng là những yếu tố mà gây ra một lỗi không hợp lệ:

Dữ liệu kiểm thử không hợp lệ
Môi trường không ổn định
Bước kiểm thử không chính xác
Yêu cầu không rõ ràng

4) Không tuân theo các quy trình chất lượng

Mỗi tổ chức có các quy trình chất lượng khác nhau giúp họ thực hiện dự án một cách thành công. Hiệu suất của cá nhân và nhóm thường được đo bằng các quy trình này. Những tester không tuân theo các quy trình như vậy có thể ảnh hưởng đến chất lượng sản phẩm do đó sẽ dẫn đến sự không hài lòng của khách hàng.

Dưới đây là một vài ví dụ về việc không tuân theo các quy trình:

Không sử dụng template chính xác đối với các hiện vật thử nghiệm.
Không tuân theo quy trình đánh giá
Sử dụng phiên bản cũ của tài liệu do thiếu kiểm soát phiên bản.

5) Kiểm thử được thực hiện trên nền tảng giả định

Có nhiều thứ liên quan đến phần mềm mà một tester giả định và thực hiện kiểm thử trên nó. Các giả định này bao gồm phần mềm kỹ thuật, phi kỹ thuật và có khả năng là các giả định này có thể sai và tester có thể bỏ sót các lỗi nghiêm trọng.

Vì vậy, không bao giờ kiểm thử bất kỳ ứng dụng nào dựa trên các giả định, làm cho các yêu cầu sản phẩm trở nên rõ ràng và dễ hiểu từ các developer hoặc nhà phân tích kinh doanh. Nếu bạn không rõ ràng về một yêu cầu cụ thể thì hãy hỏi một cách không do dự về sự nghi ngờ đó. Bằng không thì các lỗi bị sót do các giả định như vậy có thể gây ra chi phí rất lớn cho dự án.

Danh sách được đưa ra dưới đây bao gồm các giả định phổ biến trong quá trình kiểm thử:

Các developer có nhiều kiến thức về ứng dụng và họ đã lập trình một cách chính xác.
Giả sử các tuyên bố hoặc yêu cầu mà không thực sự đề cập đến bất kỳ tài liệu nào.
Không có thảo luận hoặc bất kỳ sự chấp thuận nào giả định rằng một chức năng cụ thể nằm ngoài phạm vi kiểm thử.

6) Thiếu thái độ “Test to Break”

Test to break: nói cách khác là phá app mà các developer vẫn hay nói vui với tester mỗi khi tester kiểm thử một cách không bình thường

Kiểm thử chủ yếu là một quá trình để tìm ra một lỗi trong hệ thống. Các lỗi là các lỗi ẩn và mọi tester suy nghĩ cả tích cực và tiêu cực để xác định các lỗi đó.

Do đó, những các tester nên có thái độ như vậy đối với ứng dụng đang kiểm thử. Đối với điều này, họ không nên giả định bất cứ điều gì thay vào đó tester cần kiểm thử một cách tối đa các luồng hoặc kịch bản có thể sẽ chứng minh rằng hệ thống không hoạt động như mong đợi.

Nếu người kiểm tra chỉ kiểm thử những gì được đưa ra trong bản yêu cầu, ví dụ: chỉ có kịch bản tích cực thì họ có thể bỏ lỡ các lỗi nghiêm trọng được ẩn trong hệ thống hoặc gieo mầm trong quá trình phát triển phần mềm.

Các yếu tố sau đây ảnh hưởng đến thái độ “Test to Break”:

Suy nghĩ tích cực và không có suy nghĩ tiêu cực về hệ thống đang được kiểm thử nghiệm và quy trình làm việc của nó.
Không có thử nghiệm thăm dò hoặc phương pháp thử nghiệm đặc biệt.
Đưa ra một giả định về hành vi hệ thống hơn là kiểm thử các yêu cầu thực tế.
Không chú ý trong khi kiểm thử.
Chỉ kiểm thử những luồng thông thường.

7) Các kỹ năng kiểm thử trì trệ

Công nghiệp phần mềm đang thay đổi mỗi ngày và có rất nhiều công nghệ và công cụ mới nổi mà có thể được sử dụng trong quá trình kiểm thử phần mềm. Các testers có trách nhiệm tiếp nhận các kiến thức đổi mới về các công cụ. Ngoài ra, nó sẽ có lợi cho các tester nếu họ học công nghệ mới, công cụ mới và áp dụng nó vào trong dự án của họ làm.

Một bad tester chỉ hoàn thành nhiệm vụ của mình và không học thêm về công cụ, công nghệ, ngôn ngữ, v.v. Họ không vượt qua giới hạn bản thân và học những điều mới, cũng không tìm kiếm thông tin mới trong ngành công nghiệp phần mềm.

Những điểm sau đây là nguyên nhân dẫn tới kỹ năng kiểm thử trì trệ:

Thiếu sự chủ động trong việc tìm hiểu ứng dụng.
Trở nên chán nản công việc.
Cảm thấy nó là một công việc đơn điệu và không có gì mới trong cuộc sống thử nghiệm hàng ngày.
Bạn có thể đang trong một “vùng thoải mái”.
Chưa quyết định được mục tiêu nghề nghiệp.

8) Thiếu thông tin chi tiết của khách hàng

Tester có trách nhiệm kiểm thử xem liệu một ứng dụng có đang hoạt động đúng yêu cầu hay chưa. Ngoài ra, hãy suy nghĩ kiểu “out of the box”, họ cần nhìn từ quan điểm của người dùng cuối trong khi kiểm thử. Một bad tester sẽ không vượt qua giới hạn yêu cầu dự án và xác minh các lỗi.

Một bad tester không thể hiểu khách hàng và những gì họ cần. Một bad tester ngại hỏi bất kỳ nghi ngờ hoặc truy vấn nào, điều này có thể vì họ thiếu tự tin hoặc kiến thức kỹ thuật.

Mọi tester cần hiểu một cách rõ ràng và trong khi kiểm thử phải luôn nghĩ xem là quan điểm của người dùng cuối trong khi sử dụng ứng dụng này là gì và sử dụng phần mềm dễ dàng như nào v.v.

9) Bất cẩn

Đôi khi, tester có thể trở nên lười biếng trong khi kiểm thử một ứng dụng nhưng hãy nhớ rằng những thói quen như vậy sẽ khiến bạn trở thành một Bad Tester.

Trong khi kiểm thử, tester cần đảm bảo rằng họ đang cung cấp các thông tin chi tiết chính xác trong các báo cáo, lỗi hoặc trong các test case, v.v.

Dưới đây là một vài ví dụ về sự bất cẩn trong khi kiểm thử:

Viết trường hợp kiểm tra không chính xác hoặc thiếu một bước trong trường hợp kiểm tra.
Thiếu kỹ năng lắng nghe mà không phải tất cả các thông tin đều bị bắt.
Quên thêm vào một snapshot.
Báo cáo lỗi với thông tin không chính xác hoặc quá ít thông tin.
Cung cấp những báo cáo dài thay vì báo cáo chính xác.
Viết các testcase không chính xác hoặc thiếu bước trong một testcase.
Thiếu kỹ năng lắng nghe dẫn tới không nắm bắt được hết các thông tin.

10) Kiểm thử có thể được thực hiện bởi bất kỳ ai

Nếu một tester nghĩ rằng việc kiểm thử là một công việc dễ dàng và nó có thể thực hiện bởi bất kỳ ai mà không cần kiến thức thì họ đang thực sự không hiểu rõ về các khái niệm kiểm thử cơ bản và nhu cầu của việc “kiểm thử” là gì. Tester có những thái độ hoặc tư duy như vậy thì quả là một mối đe dọa đối với dự án vì chắc chắn họ sẽ thỏa hiệp với chất lượng sản phẩm.

Kiểm thử là một kỹ năng mà bạn có thể đạt được bằng cách học tập kinh nghiệm, v.v. Ở đây, tôi không cung cấp một danh sách đầy đủ nhưng một tester nên có các kỹ năng, thái độ học hỏi, giao tiếp tốt và kiến thức kỹ thuật, kiểm thử phá vỡ tư duy thông thường, v.v.

Kết hợp tất cả các phẩm chất như vậy sẽ làm cho bạn trở thành một good tester và bạn sẽ là một tài sản đối với dự án và tổ chức .

Bad tester có những giả định sau về việc kiểm thử:

Kiểm thử không yêu cầu bất kỳ kỹ năng nào.
Kiểm thử là một công việc dễ dàng nên nó có thể được thực hiện bỏi bất kỳ ai.
Nếu mà làm kiểm thử hoặc là một tester thì không có tương lai hay phát triển gì.
Kiểm thử là một công việc đơn điệu và không có gì mới liên quan tới công việc hay hoạt động hàng ngày.

Làm thế nào để loại bỏ những đặc tính xấu

Có rất nhiều những đặc tính mà làm bạn trở thành một “bad tester”. Bạn có thể thoát khỏi tất cả những đặc tính đó, nhưng bạn cần phải cống hiến, nghiên cứu chi tiết và tập trung trong khi kiểm thử. Ngoài ra, có thể tham gia các kỳ thi chứng chỉ, nó sẽ giúp bạn có thêm kiến thức và cũng khá hữu ích cho dự án của bạn.

Bạn cần vượt qua giới hạn của mình và học công nghệ mới, công cụ mới và thu thập kiến thức, v.v. Có những công cụ kiểm thử khác nhau mà có sẵn trên thị trường mà bạn có thể tự học hoặc với sự trợ giúp của một số khóa đào tạo. Ngoài ra, bạn cũng có thể áp dụng những kiến thức này trong các hoạt động của dự án bạn tham gia.

Bạn cần chứng minh mình là người kiểm thử chủ động bằng cách hỏi điều thú vị khác nhau, các truy vấn logic, bằng cách thực hiện một ý tưởng sáng tạo hoặc bằng việc tạo một công cụ / tiện ích nhỏ bằng cách sử dụng macro hoặc công cụ tự động hóa sẽ mà giúp tiết kiệm được thời gian của mọi người.