Tất cả sự kỳ thị xung quanh khái niệm "dàn xếp" cho vị trí Kiểm thử phần mềm thay vì nhắm đến nó chỉ đơn giản vì "bạn phải làm nhiệm vụ kiểm thử phần mềm vì bạn không thể viết code". Tôi phải thừa nhận rằng, điều này có thể đúng trong nhiều trường hợp.

Các kỹ sư phần mềm tốt nghiệp hạng nhất bước vào môi trường làm việc với rất ít hoặc không có kỹ năng lập trình và chọn ngành Kiểm thử phần mềm. Những người thử nghiệm này làm việc 1 thời gian, bắt đầu trở nên thoải mái trong không gian của họ và không phát triển mạnh để học hỏi và cải thiện.

Họ tin rằng những gì họ biết và đã làm cho đến thời điểm hiện tại là đủ. Họ hài lòng với mọi thứ và trở nên tự mãn.

Trong khi các Tester không chịu học hỏi thì thị trường tiêu dùng vẫn tiếp tục phát triển - khoảng thời gian chú ý của mọi người trở nên ngắn hơn, nhu cầu triển khai nhanh trở nên lớn hơn, sự thay đổi nhanh chóng trong công nghệ trở nên khó khăn để tiếp tục theo dõi. 

Ngành công nghiệp yêu cầu được làm ít hơn nhưng giá trị tạo ra cần phải nhiều hơn. Các khái niệm về kiểm thử Agile trở thành một tiếng vang lớn.

Ở một thị trường như vậy, các Tester nên có những ý tưởng tuyệt vời về việc triển khai các phương pháp kiểm thử nhanh, quy trình tinh gọn và quay vòng kiểm tra nhanh với tỷ lệ sai sót sau phát hành sản phẩm là thấp nhất có thể. 

Dưới đây là danh sách 5 điều đầu tiên mà một người kiểm tra phải có để đáp ứng được yêu cầu trên.

1. Cải tiến liên tục

Người kiểm thử phần mềm phải không ngừng học hỏi. Thế giới công nghệ không hề trì trệ. Nó thay đổi trong chớp mắt. Hôm nay, chúng ta đang nói về việc vận chuyển mọi người từ Anh đến Úc trong vòng chưa đầy ba giờ bằng máy bay phản lực bay trong không gian!

Điều này không nói rằng mọi người nên ra ngoài ngay bây giờ và bắt đầu học khoa học hàng không. Ý nghĩa của nó là những người thử nghiệm không nên ngồi trong không gian thoải mái của họ và bảo vệ sự thiếu năng lực của mình bằng cách đưa ra lời biện bạch "Tôi chỉ cần kiểm thử task này là đủ".

Trong số nhiều điều, một trong những điều quan trọng nhất mà người thử nghiệm nên học là sự phát triển không ngừng domain của sản phẩm. Những người kiểm thử có quan niệm sai lầm phổ biến là hiểu biết về domain chỉ cần bằng với hiểu biết về sản phẩm. Điều này là hoàn toàn sai lầm.

Hiểu biết về sản phẩm tất nhiên là rất quan trọng, nhưng có kiến thức về domain mới là điều sống còn. Không biết miền mà hệ thống đang kiểm thử đến từ đâu không chỉ là vô trách nhiệm mà còn là nguy hiểm.

2. Kỹ năng lập trình

Người kiểm thử phần mềm nên biết kiến thức cơ bản về lập trình. 1 kiểm thử viên không thể lập trình, ít nhất là các chương trình cơ bản thì không thể là người kiểm thử phần mềm xuất sắc.

1 số công ty hiện nay có một quy tắc để có thể trở thành tester, trước tiên người ta phải hoàn thành một vòng luân chuyển phát triển. Điều này đạt được khi người kiểm thử có thể liên hệ và hình dung cấu trúc mã khi kiểm thử, từ đó mang lại giá trị lớn cho các developer và kỹ sư hệ thống trong giai đoạn thử nghiệm.

Đây là lúc nhóm thử nghiệm thực sự cung cấp thêm nhiều giá trị cho sản phẩm mà họ đang thử nghiệm.

3. Đổi mới tư duy

Người kiểm thử phải liên tục suy nghĩ về cách họ có thể làm hai điều và làm tốt chúng:

• Thay đổi các kịch bản thử nghiệm
• Cải tiến các phương pháp kiểm thử.

Được trang bị hai kỹ năng này, việc thay đổi kịch bản thử nghiệm giờ đây chỉ trở thành một vấn đề của chiến lược. Thực hiện nó không phải là một vấn đề nữa. Điều này giúp người kiểm thử tập trung vào chiến lược thử nghiệm hơn là các chi tiết của thử nghiệm. Họ ngừng đổ mồ hôi cho những thứ nhỏ nhặt để tập trung cho những thứ tốt hơn. Nhiều công cụ và chương trình kiểm thử phần mềm tốt hiện nay cũng chính là kết quả của việc đổi mới tư duy trong quá khứ.

4. Giao tiếp

Những người kiểm thử thường cảm thấy rằng họ là những người “back office”, do đó không cần phải nói nhiều như những người ở "front office". Điều này có thể đúng trong một số trường hợp, nhưng không có nghĩa là người thử nghiệm nên giao tiếp ít hơn. Nói và giao tiếp là hai việc rất khác nhau, trong hầu hết mọi ngữ cảnh.

Kiểm thử viên phải có khả năng giao tiếp rõ ràng, chính xác và thể hiện khả năng hiểu cao. Kỹ năng giao tiếp ở đây bao gồm các hoạt động như đọc và hiểu các thông số kỹ thuật, dịch chúng thành các trường hợp kiểm thử có cấu trúc, báo cáo lỗi và viết báo cáo rõ ràng và ngắn gọn cho cấp quản lý. Nhưng không dừng lại ở đó..

Khi tham gia các cuộc họp, kiểm thử viên phải có khả năng hợp lý hóa cuộc thảo luận và truyền đạt những phát hiện của họ theo một phương pháp logic và rõ ràng. Nói tóm lại, một người kiểm thử phần mềm phải có kỹ năng nói và viết đặc biệt để có thể nổi trội trong ngành.

5. Trách nhiệm giải trình

Đây là một từ mà rất nhiều người kiểm thử phần mềm có thể cảm thấy không hài lòng lắm. Thuật ngữ này được giải thích theo hai cách khác nhau:

a) Trách nhiệm đối với sản phẩm bạn đang thử nghiệm: Nhiều người kiểm thử đến văn phòng vào buổi sáng, thực hiện các task của họ và sau đó rời văn phòng vào cuối buổi chiều. Ngay sau khi hoàn thành nhiệm vụ trong ngày, họ đứng lên và ra về. Nghe có vẻ hợp lý ? Có đó, và cũng có rất nhiều người vẫn phát triển dù có những thói quen đó ở nơi làm việc.

Tuy nhiên, đây không phải là điểm mấu chốt. Điều quan trọng ở đây là, những người thử nghiệm thường không thấy sản phẩm của họ phù hợp ở đâu trong ngữ cảnh rộng lớn hơn.

Nó ảnh hưởng như thế nào đến nền kinh tế và thị trường, doanh nghiệp và phong trào kinh doanh, người tiêu dùng và người dùng cuối, v.v.? Nếu chỉ những người kiểm thử có thể nghiên cứu điều này và nhận ra những đóng góp mà họ đang thực hiện, công việc họ làm sẽ có ý nghĩa hơn rất nhiều và họ sẽ làm việc tốt hơn rất nhiều do ý thức làm chủ mà họ đã trau dồi.

b) Chịu trách nhiệm về những sai sót hoặc sai lầm mà bạn đã mắc phải: Mọi người thường nghĩ về những người kiểm thử như những người bắt lỗi người khác. Và các kiểm thử viên cũng thích tin vào điều này. Tuy nhiên, các kiểm thử viên (giống như phần còn lại của thế giới) cũng có lúc mắc sai lầm. Thừa nhận những sai lầm làm cho người kiểm thử trở nên trung thực hơn.

Có ý kiến nói rằng những người kiểm thử thừa nhận sai lầm của họ và không đưa ra lời giải thích không cần thiết làm lãng phí thời gian và công sức của người khác, là những người kiểm thử đáng tin cậy. Từ đó, chúng ta có thể tránh xa việc đổ lỗi để tập trung vào giải pháp. Việc chỉ tay là ai sai hoặc chuyển hướng đổ lỗi sang cho ai cũng rất nguy hiểm. Chỉ cần thừa nhận và tiếp tục công việc của mình.

Theo viblo.asia

Japan IT Works