mặt trái kiểm thử phần mềm

Mặt trái của ngành kiểm thử phần mềm

Hiện nay ngành kiểm thử phần mềm (KTPM) không còn quá xa lạ với những người làm trong ngành IT như cách đây vài năm. Với việc nhiều công ty KTPM thành lập đã đẩy mạnh ngành KTPM phát triển ở TPHCM và mới đây nhất là Đà Nẵng. Có thể nói hiện nay đây là một trong những nghề thu hút được rất nhiều các bạn sinh viên mới tốt nghiệp ra trường với một mức lương khá. Thế nhưng những điều sau đây mà tôi nói đến sẽ một phần nào đó giúp các bạn hình dung ra một mặt trái của ngành kiểm thử phần mềm nói riêng (và những ngành nghề IT khác nói chung).

knowledge_graph

Manger: Luôn hoàn thành tốt dự án trong thời gian cho phép của khách hàng

Vâng, đó chính là yếu tố đầu tiên mà các Manager, cũng như các công ty KTPM khác, đưa ra khi bạn mới vào làm (mặc dù nó chẳng bao giờ được nhắc đến trong buổi phỏng vấn). Mặc nhiên đây là yếu tố sống còn để bạn tiếp tục tồn tại trong cái ngành nghề khá mới này (và cũng như các ngành khác). Tôi muốn đưa ra một ví dụ để dễ dàng truyền tải ý nghĩa của chủ đề này như sau:

Bạn và 5 người được giao công việc sử dụng công cụ kiểm thử phần mềm tự động (KTPMTD) để thực hiện một dự án A của một khách hàng rất tiềm năng. Và tôi chắc chắc rằng các bạn sẽ phải chịu rất nhiều áp lực từ phía khách hàng cũng như công ty:

  • Công ty: phải giành được hợp đồng với mức lợi nhuận cao nhất nhưng bỏ ra ít đầu tư nhất
  • Khách hàng: bảo đảm chất lượng của sản phẩm tương xứng với số tiền bỏ ra

Chuyện làm thêm giờ (overtime – OT) sẽ là thường xuyên để hoàn thành chỉ tiêu mà khách hàng đưa ra (và tin tôi đi, mỗi ngày khách hàng sẽ càng khó hơn một chút). Đến một lúc nào đó bạn sẽ phải thốt lên rằng: “Điên à, chỉ có thần thánh mới làm kịp”. Nhưng may mắn thay, có lẽ sếp nào đó nghe được và bạn sẽ được “vuốt ve” và ca ngợi bằng những mỹ từ mà bạn mới lần đầu tiên nghe được. Nhưng rồi bỗng nhiên bạn sẽ ngờ ngợ vì thằng bạn làm bên dự án kia nó cũng có cái email với những mỹ từ tương tự. Rồi con nhỏ bạn trong dự án khác nó cũng đang bay bổng với những lời có cánh. Và rồi các bạn lại lao đầu vào công việc với một mục tiêu mới: hoàn thành tốt dự án bằng mọi cách. Và đâu đó trong đầu bạn đã manh nha xuất hiện một ý tưởng: vươn lên trong con đường sự nghiệp.

Ở đây tôi không muốn bàn đến về mặt Leadership, mà là một vấn đề khác: nhận thức về việc hoàn thành dự án.

Việc tôi đề cập ở dưới đây chắc sẽ có rất nhiều các vị cao niên, thâm niên và quyền-uy cười khẩy và nhấn ngay Alt-F4. Tốt thôi vì tôi tin sẽ có người chịu khó thêm 3 phút để đọc đoạn dưới đây và tôi không muốn phí thời gian của ai hết.

KTPM không có nghĩa là bạn hoàn hảo, và KTPMTD không có nghĩa là test case của bạn viết chẳng bao giờ có lỗi.

Tôi đã từng rất mệt mỏi khi phải cặm cụi 4 tiếng chỉ để debug (tìm ra cái lỗi) trong cái test case – KTPMTD – (chỉ chạy mất 30 phút) dùng để tìm ra lỗi của một AUT (application under test). Thật nực cười nhỉ?! Nhưng tôi tự an ủi với chính bản thân rằng khi debug xong thì sau này tester sẽ chỉ ngồi không mà xem cái máy nó chạy test case thôi. (Nhưng có lẽ tôi quá xui chăng?) Cứ mỗi lần có phiên bản mới (version) của AUT thì lại những test cases khác lại có vấn đề đâu đó. Lại cặm cụi debug lại sửa chữa và cố gắng cho kịp thời hạn khách hàng giao phó. Nhưng ôi thôi đó là những chuỗi ngày dài liên tục lập lại mặc dù tôi rất cố gắng.

Đó là câu chuyện của tôi, có người khen có người chê có người góp ý. Ở đây tôi xin phép không bàn đến, nhưng tôi đã để ngỏ cho chính bản thân mình những câu hỏi: Nếu con người có thể hoàn hảo, công việc chúng ta làm hoàn hảo thì làm gì có ngành KTPM này? Khách hàng có những con người viết ra những application hoàn hảo thì đâu cần bỏ tiền thuê KTPM? Thế thì tại sao chúng ta không thừa nhận rằng “chúng tôi không hoàn hảo”.

Tổng hợp