Những điều một tester nên tránh
Sau khi bài viết “10 đặc điểm của một kỹ sư phần mềm kém”, đề cập đến một số thói quen hoặc thái độ không tốt của một kỹ sư phần mềm, được đăng, một câu hỏi về các đặc điểm của một tester phần mềm yếu kém đã được đưa ra. 1- Kiểu “Tôi thấy bug bot”: Người này sẽ dừng lại ...
Sau khi bài viết “10 đặc điểm của một kỹ sư phần mềm kém”, đề cập đến một số thói quen hoặc thái độ không tốt của một kỹ sư phần mềm, được đăng, một câu hỏi về các đặc điểm của một tester phần mềm yếu kém đã được đưa ra.
1- Kiểu “Tôi thấy bug bot”: Người này sẽ dừng lại ngay khi thấy dấu hiệu đầu tiên của bug và lập tức làm báo cáo bug. Đừng hiểu lầm, báo cáo bug rất quan trọng – nếu không thì làm sao sửa được bug chứ? Nhưng chỉ cần một chút điều tra tìm hiểu về bài test hoặc môi trường cũng có thể tạo ra khác biệt lớn trong việc viết một bản báo cáo bug hiệu quả đấy.
2- Kiểu “Tôi không phải lập trình viên”: Tôi không biết code, tôi không muốn biết cách code, đó là việc của lập trình viên. Dạng người này không nắm được chuyên môn kỹ thuật của phần mềm đang được test hoặc những tác động về kỹ thuật của các bug mà anh ta/cô ta gặp phải. Trường hợp tốt nhất, người đó sẽ hành động như một người dử dụng và kiểm tra chức năng của phần mềm; trường hợp xấu nhất, người đó sẽ chống đối bằng cách gõ v’s vào checkbox.
3- Kiểu “Tôi cần tất cả tài liệu thì mới có thể test được”: Một vài người thường bị mắc kẹt ở các bước thử nghiệm cơ bản. Họ thiếu trí tưởng tượng và không thể bắt đầu test dựa trên sản phẩm, mã và thông tin từ lập trình viên. Tester kiểu này tin rằng cả thế giới (hoặc ít nhất là công ty đó) sẽ kết thúc nếu tất cả mọi thứ không được sắp xếp sẵn trước khi mình bắt đầu các hoạt động testing.
4- Câu nói gây khó chịu: Test của tôi hiệu quả, nhưng mà: Tôi không thể viết một bản báo cáo bug hoàn chỉnh. Hầu hết những điều tôi viết ra đều có kết luận chung là “Nó không hoạt động.” Không có sự điều tra nghiên cứu. Không có quy ước nhất quán về testing, báo cáo hay cách giao tiếp. Báo cáo bug ở khắp nơi, v.v
5- Kiểu “Nhà đầu tư ngắn hạn”: Người đó test. Người đó viết báo cáo. Người đó làm tiếp. Không hề nỗ lực học hỏi thêm về sản phẩm, về cách code hay nhà phát triển. Bạn test phần mềm nhưng không đạt được thêm gì nữa, một chút kiến thức cũng không.
6- Kiểu “Người biểu tình”: code kém, kế hoạch test kém, tôi không làm được, giao cho ai đó có kỹ thuật hay kiến thức hơn giải quyết chuyện này đi. Tôi ghét cái này (10 lần/giờ)
7- Kiểu “Người chỉ đạo”: Hoặc là làm theo tôi, hoặc là rút lui. Đó là “ý của họ” so với “ý của bạn”, không phải “ý của dự án”. Đó là giải pháp của họ so với giải pháp của bạn. Tôi dám chắc rằng sẽ xảy ra một cuộc tranh luận. Bằng cách nào đó, họ sẽ vẫn cứ quay lại một phần test bạn đã thực hiện. Người này là một vật cản lớn với năng suất làm việc và sẽ là người đầu tiên đầu hàng khi phải chịu áp lực và bắt đầu ra lệnh cho người khác. Kiểu người này không có ích gì cho cả nhóm, dù họ có là một lập trình viên giỏi và kinh nghiệm đến đâu đi nữa.
8- Kiểu “Quá thận trọng”: Kiểu tester này sẽ đông cứng nếu tất cả các yêu cầu không được quy định rõ ràng. Kiểu tester này sẽ phát hoảng khi biết được không phải tất cả tài liệu đều đã có sẵn. Kiểu tester này sẽ co rúm lại nếu bảo hiểm không được đảm bảo 100% (code- , chức năng- , hay bất cứ thứ gì khác). Những người này sẽ làm bất cứ điều gì để tránh việc phải bước ra ngoài vùng an toàn của mình. Những tester giỏi luôn thể hiện xu hướng dịch chuyển dần dần/nhanh chóng khỏi vùng an toàn của mình để khám phá thêm những điều khác.
9- Kiểu “Bất cẩn”: Quên làm bản sao lưu, snapshot, không biết tái tạo bug, v.v. Đây thường là xu hướng của những người mới làm và sẽ dần cải thiện khi được tiếp xúc với chuyên môn nhiều hơn.
10- Kiểu “Cracker phần mềm lười biếng”: Họ tự hào rằng mình luôn dùng những công cụ và phương pháp mới nhất để test những phần mềm phức tạp. “Công cụ điều khiển hành vi, tự động test phần mềm mới nhất đời thứ 4 này sẽ giải quyết tất cả các vấn đề về chất lượng của chúng ta. 100 lần thì đến 99 lần đây sẽ là 1 kiểu làm bộ. Họ sẽ đầu tư rất nhiều thời gian vào việc chuẩn bị công cụ/môi trường và sau đó, nó không hoạt động khi không có nhiều khoản đầu tư mới hơn. Chuẩn bị phần mềm sẵn sàng rồi test sẽ tốn nhiều chi phí hơn khi thử nghiệm nó ngay lần đầu tiên.
Nguồn tham khảo và dịch từ: http://www.testingexcellence.com/10-characteristics-bad-software-tester/