4 Sai lầm phổ biến của tôi khi là một Tester
Bài đăng này đã không được cập nhật trong 7 năm
Tất cả chúng ta hẳn đều đã nghe câu chuyện về con ếch nhỏ ngồi đáy giếng nghĩ rằng cả thế giới chỉ là cái giếng cho đến khi nó bước ra ngoài và nhận ra thế giới to lớn, đẹp và khác biệt nhường nào!
Bạn có nghĩ rằng bạn đã trải nghiệm tình huống này tại một số thời điểm trong cuộc sống nghề nghiệp của bạn? Vâng, tất cả mọi người đều đã từng. Chào mừng bạn đến với thế giới của kiểm thử viên .
Hôm nay, tôi muốn chia sẻ 4 lỗi tôi đã làm khi bắt đầu sự nghiệp kiểm thử phần mềm. Bạn cũng có thể đã phạm những sai lầm này. Thử đọc qua nhé!
4 sai lầm phổ biến nhất mà Thử nghiệm Phần mềm Thực hiện
Là tester, đã bao lần trong sự nghiệp của bạn nghĩ đến những điều sau đây?
# 1. Đặt các câu hỏi không phải lúc nào cũng cần thiết
Tất cả chúng ta đều có những điểm yếu bẩm sinh. Theo một cuộc khảo sát phổ biến, điểm yếu thường thấy nhất ở người lớn là sự sợ hãi vẻ ngoài ngớ ngẩn. Sự sợ hãi không thực tế này cản trở sự tăng trưởng của chúng ta. Giả sử hơn là yêu cầu là những gì chúng tôi được dạy.
Trong khi test một ứng dụng đăng ký vé trực tuyến, người tester đã quan sát thấy rằng người dùng không được phép hủy vé đã đặt trước ít nhất là đến 24 giờ kể từ khi đặt phòng. Từ viễn cảnh của người dùng cuối, điều này hoàn toàn không thể chấp nhận được. Nhưng thay vì đặt câu hỏi về hành vi, người tester cho rằng nó có thể là yêu cầu. Điều này một giả định sai lầm đã dẫn tới việc ứng dụng thất bại trên thị trường.
Một người bạn tôi là tester đã rất nổi tiếng với phong cách hỏi câu hỏi của chị, đã từng nói với tôi rằng chị đã bị cười nhạo vì đặt câu hỏi về hầu hết mọi thứ từ logic mã hóa đến hệ thống theo dõi bug, đến việc giải quyết lỗi như thế nào. Việc đó đã giúp chị ấy bởi vì chị ấy đã phát triển sự tự tin và sự rõ ràng về mọi thứ.
Không ngần ngại đặt câu hỏi và đưa ra quan điểm của bạn. Là người tester, bạn có tất cả các quyền để đặt câu hỏi về hành vi của ứng dụng và dữ liệu sử dụng thời gian thực của nó.
# 2. Test Tự động khó học và mất rất nhiều thời gian
"Tự động hóa" là từ mà vẫn tạo ra cảm giác khó chịu cho nhiều tester.
Nhiều người vẫn nghĩ:
- Học tự động hóa có thể mất thời gian
- Tự động hóa là khó học hỏi
- Tự động hóa không hữu ích
Đây không chỉ là sợ hãi sự thay đổi, sợ hãi học hỏi những điều mới mẻ mà còn là nỗi sợ hãi khi phải ra khỏi vùng an toàn của bạn.
Tôi khuyên rằng bạn nên tìm hiểu test tự động và tiếp tục học tập nếu bạn muốn hình thành sự nghiệp của bạn và muốn phát triển nhanh chóng trong ngành công nghiệp này.
# 3. Mọi thứ đều có trong Tài liệu lịch bản thử nghiệm và tôi không cần phải nghĩ xa hơn
Xu hướng đã được làm theo cho đến nay là: Khám phá requirements, Hiểu chức năng, Động não, VIết kịch bản test, và gửi chúng đi review. Một khi việc review hoàn tất, người tester tuân theo các kịch bản thử nghiệm đã được kiểm chứng. Thử nghiệm thăm dò theo thời gian thực dường như không còn hiệu quả vì việc động não đã được thực hiện vào thời điểm tài liệu.
Một khi việc xem xét được thực hiện, người kiểm tra tuân theo các kịch bản thử nghiệm đã được kiểm chứng. Thử nghiệm thăm dò theo thời gian thực dường như không còn hiệu quả vì việc làm động não đã được thực hiện vào thời điểm tài liệu.
Đây là một cách tiếp cận hoàn toàn sai lầm. Tôi sẽ cho bạn một ví dụ.
Bạn đang nhìn bức tranh và bạn tiếp tục nhìn nó trong 10, 30, 60 phút và vân vân. Ban đầu, bạn tìm thấy bức tranh tốt nhưng nhờ tiếp xúc kéo dài với nó, bạn bắt đầu nhận ra những sai sót trong nó. Sau khi nhìn chằm chằm vào nó trong 60 phút, bạn cảm thấy như bạn biết bức tranh này lâu rồi và bạn biết tất cả những điểm hay và dở về nó. Hãy ngừng xem xét nó trong 1 ngày.
Ngày hôm sau, nhìn lại bức tranh. Bạn có để ý mảng màu ở góc đó ngày hôm qua không? Trông nó có ổn không? Chẳng phải bạn nghĩ rằng phối hợp màu sai sẽ thực sự hủy hoại hiệu ứng tổng thể của bức tranh? Ngạc nhiên chưa, vì bạn đã không nhận thấy điều đó ngày hôm qua! Vâng, điều đó vẫn thường xảy ra. Mỗi ngày mang lại cho chúng ta cái nhìn mới và quan điểm mới và với điều đó chúng ta nhìn vào mọi thứ một cách khác nhau.
Tôi hy vọng ví dụ đó làm rõ quan điểm của tôi là không nên dựa quá nhiều vào tài liệu kịch bản test trong khi thử nghiệm.
Hãy nghịch ngợm thật vui và bất định, sau đó ghi nhận phản ứng của ứng dụng.
#4. Việc của tôi là tìm bug chứ không phải để phân tích mẫu số chung
Chúng ta thường được dạy là hãy tập trung vào việc của mình và bằng cách nào đó chúng ta tin rằng việc của chúng ta chỉ là tìm ra bug. Bất cứ việc gì khác ngoài điều đó không thuộc phạm vi trách nhiệm của chúng ta.
Hãy thay đổi suy nghĩ đó bằng ví dụ tốt nhất mà tôi đã sử dụng trong nhiều năm.
Một nhà hàng mới mở không có khách hàng ngay cả sau khi cố gắng hết sức. Họ gọi một chuyên gia để phân tích tình hình. Phân tích cho thấy rằng nhà hàng không có được bất kỳ khách hàng thường xuyên nào vì bất kì lí do gì. Ông đã liên lạc với khách hàng vãng lai và từ phản hồi của họ, ông hiểu rằng khách hàng không thích thức ăn (bất kỳ loại thức ăn nào) vì chúng vô vị. Những đầu bếp mới và giàu kinh nghiệm được bổ nhiệm ngay lập tức và nhà hàng giờ đây luôn có khách phải đứng chờ.
Vai trò của chúng ta như là một người tester cũng tương tự như của chuyên gia phân tích trong tình huống nêu trên. Chúng tôi không chỉ cần phải tìm ra bug mà còn cần phải phân tích những điểm khác có thể đã bị ảnh hưởng do các lỗi đó và có quy tắc nào của bug lặp lại trong ứng dụng hay không.
Với kinh nghiệm, bạn được mong đợi cung cấp phân tích chi tiết chứ không chỉ là thử nghiệm giới hạn.
Kết luận:
Ý tưởng đằng sau bài viết này là hướng dẫn những tester mới và nhắc nhở họ rằng ngành công nghiệp, nhu cầu và sự mong đợi đang thay đổi.
Hãy luôn cập nhật, tiếp tục học các kỹ năng mới và theo yêu cầu, chia sẻ kiến thức, thông tin và các vấn đề, không bao giờ ngần ngại yêu cầu chất lượng tốt hơn và luôn sẵn sàng đóng góp cho cùng một mục tiêu.
All rights reserved