5 lời biện hộ mà nhân viên kiểm thử cần ngừng lại

Trong quá trình làm việc, đôi khi tôi cảm thấy khó chịu khi phải step-by-step để tìm ra bug mà không hề biết nguyên nhân thực sự bug là do đâu. Và đây là một bài viết đưa ra 5 quan điểm mà tester chúng ta thường dùng nó làm lý do để biện hộ cho 1 trong những vấn đề tôi đã nêu trên. Hãy đọc với sự thoải mái và nhìn nhận đúng vấn đề. Tôi mong bạn sẽ tìm ra vấn đề hay những điểm chúng ta còn khiếm khuyết như tôi.

Tôi muốn tiết lộ một vài điều từ kinh nghiệm thuê vài trăm tester trong một thời gian và phỏng vấn một vài nghìn người khác của tôi.

Từ các buổi thảo luận tôi đã có với các đồng nghiệp tester trong các buổi phỏng vấn, tôi đã cảm thấy rất hạnh phúc khi nhìn thấy các tài năng mà chúng ta có trong cộng đồng các tester.

Nhưng hãy để tôi cũng chia sẻ các câu chuyện bên lề khác, về những điều mà tôi đang nói về. Nó làm tôi buồn.

Tôi không bao giờ cảm thấy hạnh phúc khi xem các diễn viên tài năng đang bị nhốt vào 1 cái cũi ảo của các trách nhiệm. Tôi cảm thấy bất mãn khi xem các ngôi sao nhạc rock đang biểu diễn trên 1 sân khấu bị điều khiển. Nếu bạn vẫn đang tự hỏi chuyện gì vậy và ranh giới là gì, nó là như này – Phần khá đông của cộng đồng test của chúng ta là không có đủ sự phát triển về nhiều mặt trong nhiều năm sau khi họ bắt đầu công việc của họ như 1 tester. Xét trên 360 độ, phải gần 1 nửa con số đó.

Xin lỗi cho sự lỗ mãng, nhưng nó là sự thật. Ai là người để đổ lỗi cho điều này? Có lẽ nhận thức trong ngành là 1 phần nào. Các chính sách của công ty và quản lý cấp cao cũng có thể. Nhưng nhiều hơn bất cứ thứ gì khác, nó chính là bản thân tester.

Nói cách khác, nó là bạn. Nó là chúng ta. Bởi vì chúng ta trở thành nạn nhận của sự bào chữa.

Dưới đây là 1 vài điều mà tôi đã ngộ ra.

5 lời biện hộ mà nhân viên kiểm thử cần ngừng lại

Lưu ý: Tôi không nói rằng đây là các trường hợp với mọi tester và mọi tổ chức. Nhưng tôi đã thấy đủ các ví dụ để công nhận hầu hết chúng ta là các nạn nhân ở đây.

1) Chúng ta không điều khiển môi trường test của chúng ta, chúng ta đã giới hạn quyền hạn.

Tôi thường nghe các phát biểu – “Chúng ta chỉ Read-only tới môi trường”. Hay tệ hơn – “Chúng ta chỉ truy nhập tới các log ngoài ra không gì khác”. Mọi thứ khác được làm bởi deverlop team hoặc 1 vài team khác.

Công việc mà sẽ mang lại cho chúng ta rất nhiều hiểu biết phong phú về testing và nhiều công cụ kỹ thuật khác không được làm bởi chúng ta. Và có lẽ chúng ta cảm thấy hạnh phúc về điều này, nhưng thật ra chúng ta không nên như vậy.

Hãy kể cho tôi 1 lý do tại sao bạn sẽ không kiểm soát môi trường test của bạn và đưa ra tất cả các lợi ích của nó.

Ở đây là 1 vài lợi ích có thể nếu bạn đang tự hỏi tôi đang nói về điều gì:

1. Bạn có toàn quyền kiểm soát môi trường test của bạn để đảm bảo nó là chính xác hoặc gần giống môi trường sản xuất. Điều này giúp bạn tránh 1 vài bỡ ngỡ ít nhất là khi phân phối sản phẩm của bạn.
2. Bạn biết tất cả các thành phần liên quan, tất cả các phần mềm được sử dụng cùng với các phiên bản của chúng cho các tính năng sản phẩm của bạn. Với thời gian, tin tôi đi bạn sẽ có nhiều hiểu biết về công việc của chúng, các giới hạn và các điểm lỗi có thể.
3. Bạn có đủ quyền truy cập để thực hiện debug ở cấp độ cao nhất trong trường hợp có các issue cấp độ thấp hơn. Ví dụ: thiết lập running slow, kiểm tra CPU, bộ nhớ sử dụng và các log ở mỗi cấp độ mà không có gì khó khan.
4. Bạn có quyền kiểm soát các thiết lập, bởi vậy bạn biết bạn đang thay đổi cái gì và build bạn đang triển khai là gì. Bạn tự tin nhiều hơn trước khi xuất xưởng bản release tương lai.
5. Bạn tìm hiểu tất cả về nó. Dù nó là Linux base hay window base.

Có lý chứ? Hãy để tôi tiếp tục nếu ít nhất bạn đồng ý rằng có nhiều lợi ích.

Bây giờ câu hỏi là thay đổi gì bạn có thể làm trong team hoặc tổ chức của bạn để thực hiện công việc này. Và làm sao bạn làm nó 1 cách chính xác.

Vâng, tôi không biết. Tôi không biết team của bạn, lãnh đạo của bạn, và tổ chức của bạn, bởi vậy tôi không thể giúp bạn điều này. Tôi có thể chia sẻ 1 vài điều mà có thể làm. Bạn thử làm việc sát sao với Dev của bạn hoặc bất cứ team nào liên quan và quan sát họ làm những gì và làm thế nào. Mọi thứ. Cái cách mà họ login tới môi trường (server), cách mà họ logout và mọi thứ còn lại. Một khi bạn có được 1 vài kiến thức, bạn sẽ có sự tự tin để nói 1 vài điều, đưa ra 1 vài gợi ý khi 1 tình huống tương tự lặp lại hoặc 1 hành động tương tự được thực hiện 1 lần nữa.

Rõ ràng sớm hay muộn sự tự tin này của bạn sẽ được nhìn thấy bởi dev/lead/manager của bạn. Đó là thời điểm bạn có thể yêu cầu sự kiểm soát. Và kể với tôi 1 lý do chính đáng tại sao họ không đưa cho bạn mọi thứ? Họ nên cảm thấy hạnh phúc để làm điều đó nếu bạn thể hiện được khả năng cần thiết.

Tin tôi đi, họ có quá nhiều việc để làm, bởi vậy nó sẽ không khó khăn để họ trao cho bạn quyền kiểm soát. Ít nhất tôi hi vọng như vậy.

2) Chúng ta không tự deploy, 1 vài team khác sẽ làm nó.

Bạn đến công sở vào 1 buổi sáng thứ 2. Bạn thông báo rằng có 1 vài vấn đề trong Build dẫn tới sự cản trở. Bạn cần Build mới từ bản Build của bạn. Bạn đưa yêu cầu lên hoặc liên hệ dev team của bạn hoặc team triển khai.

Oh, họ đang bận 1 vài thứ. Nhưng họ sẽ giải quyết và làm nó sau 1 thời gian nữa. Bây giờ kể cho tôi lý do của tất cả việc này? Nó không phức tạp như ta tưởng.

Khi để đưa ra 1 Build mới, 1 developer có thể đề xuất khi anh ấy thừa nhận 1 tính năng hoặc 1 bug fix nào đó chắc chắn. Nhưng khi bạn đơn giản cần kích hoạt hoặc triển khai nó, tại sao bạn cần đợi chờ hoặc phụ thuộc vào ai đó.

Có khả năng và thẩm quyền để triển khai bất cứ khi nào bạn muốn làm công việc của bạn thật dễ dàng mà không phải chờ đợi. Bạn có thấy điều đó không? Nó cũng sẽ làm tăng thời gian quay vòng trong công việc test hàng ngày. Cho dù nó là debug 1 vài thiếu xót đã được bổ sung, hay đưa ra build mới để kiểm tra các bug đã được giải quyết. Hay là làm mới build và bắt đầu với việc test 1 vài tính năng mới.

Hãy để tôi kể cho bạn 1 vài kinh nghiệm của cá nhân tôi. Nó không chỉ về thời gian. Việc triển khai dạy bạn nhiều thứ mà bạn không thể tưởng tượng. Nguyên nhân mà nó thường xảy ra lỗi. Đôi khi ứng dụng dừng làm việc với code mới. Các lỗi triển khai xảy ra nhiều lần. Và mỗi khi 1 thứ gì đó lỗi, nó buộc bạn phải debug nó. Nó buộc bạn tìm kiếm 1 thứ gì đó trên google hay hỏi 1 ai đó 1 câu hỏi hoặc tốt nhất hỏi chính bản thân bạn 1 câu hỏi.

Nó làm bạn phải suy nghĩ?

Dĩ nhiên, nó không thật sự là 1 công việc test software, nhưng nó chắc là đang kiểm tra khả năng của bạn.

Tôi sẽ nói 1 phần lớn việc học của tôi bên cạnh test software là từ triển khai và duy trì các môi trường.

• Tôi không nhớ có bảo nhiêu sự thử nghiệm và lỗi sai mà tôi đã cố gắng thực hiện, có thể đếm đến vào trăm.
• Tôi không nhớ có bao nhiêu lần tôi đã kiểm tra 1 vài bản release của 1 vài software 1 cách thủ công.
• Và tôi không nhớ có bao nhiêu lần tôi tìm kiếm google hay truy cập vào vô số trang web. Tôi biết, nó đã cho tôi rất nhiều, dạy tôi rất nhiều. Tìm hiểu nó, biểu diễn nó và hỏi về nó. Nó có thể làm việc.

3) Chúng ta không debug 1 vấn đề, chúng ta tìm kiếm các bước và log nó

Tôi sẽ không đi sâu vào vấn đề này như trong 1 cuộc phỏng vấn không phải lúc nào bạn cũng có cơ hội thảo luận cặn kẽ về những khuyết điểm từ kinh nghiệm của các ứng viên và các nghiên cứu/debug được làm bởi họ.

Tuy nhiên, tôi có thể nói chắc rằng không phải tất cả chúng ta thử thách mình trước khi truyền lại cái thiếu sót tới developer. Nhiều thời điểm bản log nói lên tất cả. Nhiều lúc các dạng của 1 vấn đề nói lên tất cả. Nhiều khi nó thất bại bởi 1 số dịch vụ tiên quyết bị down.

Vì vậy trong thời gian ngắn, nhiều khi nó thực sự có thể cho chúng ta có được nguyên nhân gốc rễ hay ít nhất đạt được sát vấn đề nhất.

Vì vậy hãy tự hỏi mình 1 số câu hỏi, không phải để giúp developer nhưng làm cho chu kỳ test của bạn nhanh chóng và cho sự phát triển của riêng bạn. Bạn là biện pháp khắc phục ở đây. Không phải ai khác.

4) Tôi không biết tại sao nó xảy ra.

Developer đã giải quyết nó và tôi đơn giản là kiểm tra nó.

Oh, tới đây. Xin lỗi nhưng nghe điều này làm phiền tôi rất nhiều.

Mỗi lần, nó gây phiền toái cho tôi khi tôi hỏi tester 1 câu hỏi – tại sao vấn đề xảy ra hay nguyên nhân chính là gì và họ trả lời “tôi không biết”. Chúng ta đã mang tới 1 hộp đen theo đúng nghĩa phải không? Làm sao chúng ta có thể không hỏi developer xem anh ta đã sửa cái gì? Tại sao chúng ta không thể hỏi nó nếu như nó thực sự là 1 vấn đề?

Tôi chắc chắn rằng 99% thời gian chúng ta không biết phân tích nguyên nhân chính hay sửa nó bởi vì chúng ta không hỏi nó. Tin tôi đi, biết được chính xác giải pháp, module nào được sửa, front end hay back end, nó đã được đưa vào bất cứ tính năng nào hay sửa 1 số lỗi khác, nó luôn luôn giúp bạn trong công việc test. Luôn luôn Ngoài ra, thông tin này giúp bạn biết nhiều công cụ kỹ thuật mà có thế bạn sẽ không bao giờ dùng qua.

Khắc phục? Hỏi nó? Đòi hỏi nó? Bất cứ việc gì.

5) Tôi đã không có cơ hội làm việc với bất cứ thứ gì khác ngoài manual testing

Có lẽ lý do này hợp lý với 1 số phạm vi khối lượng công việc được giao phó cho bạn hoặc hạn chế về mặt trách nhiệm được đưa ra, nhưng nó không phải hoàn toàn hợp lý. Vấn đề ở đây là, chúng ta nói rằng chúng ta đã không nhận được cơ hội để thực hiện các chức năng khác của việc test, hoặc chúng ta không nên làm điều đó hoặc chúng ta không có thời gian.

Đồng ý, học tập luôn tốn thời gian. Nhưng không có bất cứ thứ gì bạn có thể làm khác phải không?

Trong khi kiểm tra 1 tính năng mới hoặc 1 API,

• Nó không thể cho bạn nắm giữ thời gian phản hồi phải không?
• Nó không thể hỏi về khả năng phân tích từng tính năng/module/API đang đợi xử lý mà bạn có có thể kiểm tra phải không?
• Nó không thể thực hiện việc kiểm tra bảo mật cơ bản như phiên hết hạn, Url giả mạo hay xử lý XSS trên website mà bạn có nghĩa vụ kiểm tra phải không?
• Nó không thể để ít nhất nói rằng nút “submit” hay “help” dường như đặt không chính xác hay không dễ để thấy và vai trò nhỏ của bạn trong việc làm cho sản phẩm sử dụng nhiều hơn phải không?
• Nó không thể cho bạn để bắt đầu với 1 vài thứ và sau đó tiếp tục học hỏi nhiều hơn nữa?

Câu trả lời là YES, lớn hay nhỏ tùy thuộc vào nhiều yếu tố xung quanh bạn nhưng nó chắc chắn không phải NO.

Nếu trách nhiệm của bạn không đòi hỏ nó (bởi vì có 1 vài team khác cho nó), Không ai ngăn bạn đầu tư thêm thời gian cho việc học của bạn. Tôi nghĩ tự học tập trong thời gian rảnh rỗi là luôn luôn có thể. Vậy tìm thêm những thứ có thể và bắt đầu làm nó bây giờ.

Tôi hi vọng tôi đã kích hoạt 1 số suy nghĩ và tham vọng học tập trong bạn.

Xin hãy tha thứ nếu bạn thấy bất kỳ sự cay nghiệt nào của tôi, nhưng hãy tin tôi, tôi muốn rõ ràng 100% để nó tiếp cận với các bạn với mức thật cần thiết.

Tôi sẽ rất hạnh phúc để biết bất kỳ khía cạnh thiếu xót nào xung quanh những điều mà tôi đã nói.

Tham khảo: http://www.softwaretestinghelp.com/5-excuses-every-software-tester-must-stop-giving/