top of page

"Kiếp nạn thứ 82" của Thủy trong nghề tester

  • Ảnh của tác giả: Thuy Nguyen
    Thuy Nguyen
  • 13 thg 8, 2023
  • 6 phút đọc

Đã cập nhật: 14 thg 8, 2023

Xin chào các bạn, là mình đây 😗

Bài viết này sẽ là mở đầu trong series những kiếp nạn mà mình đã gặp phải khi làm tester.


Nay hơi rảnh xíu nên mình sẽ kể lể với các bạn đôi ba tình huống “ối dồi ôi” mà mình từng gặp khi làm tester. Và qua đó mình đã nhận ra rằng: Để trở thành 1 tester “xuỵn”, ngoài những kỹ năng liên quan đến chuyên môn thì mình thật sự cần trau dồi thêm 3 kỹ năng này: Khả năng phân tích và phán đoán, kỹ năng giao tiếp, kỹ năng sắp xếp độ ưu tiên.


Mình dùng từ bắt buộc vì mình thấy nó thực sự quan trọng!

À ... note 1 chút: câu chuyện bên dưới như một bài văn kể khổ của mình nên hơi dài dòng 🙂. Mọi người hãy dành thời gian đọc nó cho mình vui nhé, cảm thấy dài quá mà ngại đọc thì vẫn cứ đọc nha ~.~


Liên quan đến: Khả năng phân tích và phán đoán 🤔

Sau khi dev đã fix xong một bug, việc quan trọng nhất lúc tester retest bug là dự đoán được rằng: Bug được sửa có thể sẽ ảnh hưởng đến những chức năng nào?


Đôi khi dự án gấp mà phải test nhiều cái cùng lúc, khi đó mình không có thời gian để check lại test case khi retest bug. Sẽ có những chức năng mà mình test xong rồi, mãi sau lại có bug của phần khác và khi dev fix thì rất dễ có khả năng nó sẽ ảnh hưởng đến những chức năng đã hoàn thành.


Mình từng gặp trường hợp như vậy 🙂. Khi ấy thời gian thì gấp, chức năng chưa test còn nhiều, dev thì cứ quay sang hỏi spec (cái này tuỳ dự án, nhưng con dự án của mình bị vậy). Vậy nên đôi khi mình chỉ retest bug đó mà không để ý đến những phần khác, đó là lý do mình đã để lọt bug :< . Và đến lúc UAT rồi còn bị KH báo bug trong khi test case của mình đã pass hết rồi … lúc đó muốn khóc lắm 🥲)


Mọi người sẽ không quan tâm lý do là gì. Mọi người chỉ quan tâm rằng: do tester không cẩn thận nên mới bị lọt bug 😒


Thật tế, trong quy trình log bug và khi dev resolved thì dev cần phải note giúp mình những phần có thể bị ảnh hưởng trong ticket bug đó. Nhưng thường dev cũng không để ý (nếu như team không làm chặt quy trình đó) ... vậy nên buộc mình phải cẩn thận thôi. Ngoài ra, việc xác định phạm vi ảnh hưởng cũng phụ thuộc vào kinh nghiệm test của mình nữa. Những người có kinh nghiệm thì sẽ dễ xác định hơn.


Tóm lại, hãy thật cẩn thận khi retest bug nhé. Tester thì bằng mọi cách, cố gắng đừng để lọt bug vì: dev có thể cười vào mặt bạn 🙂, sếp có thể đánh giá bạn 🥲 và KH có thể sẽ claim cả team dự án của bạn.


Híc … mỗi lần làm gì có lỗi là mình cảm giác buổi review lương tiếp theo sẽ khum yên ổn =))


Về giao tiếp thì sao? 🫠

Ở chức vụ hay lĩnh vực nào thì cũng rất cần kỹ năng này.

Phải có kỹ năng để còn nhờ dev fix bug chứ 🥴. Dev nào mà gặp bà tester ngang với cứng đầu, thấy bug là cáu gắt rồi lèm bèm nhiều, xong lại hay giục nữa thì đúng là … dev mà cáu là thôi không fix bug cho đâu 😀. Nói vậy chứ có bug thì vẫn phải fix, nhưng nếu biết cách giao tiếp thì việc giải thích hoặc nhờ sự giúp đỡ của dev sẽ dễ dàng hơn, mà đôi bên lại cùng zui zẻ ^_^.


Hoặc trong 1 số trường hợp, khi muốn đề xuất với cấp trên thì cũng cần có kỹ năng giao tiếp làm sao để nhận được sự đồng ý. Đã có lần, mình yêu cầu quyền truy cập DB để thực hiện truy vấn data trên site Test. Tuy nhiên có thể do mình đề xuất chưa rõ ràng (PM nói vậy) nên PM đã từ chối và mình phải raise vấn đề đó vào channel General của team. Sau đó mình vẫn được cấp quyền truy cập DB, tuy nhiên mình đã lườm người anh PM của mình cả ngày hôm đó.

Đúng vậy, tình anh em đã bị sứt mẻ đôi chút! : ))


Mình đánh giá rất cao việc phải có kỹ năng giao tiếp tốt, mặc dù thực tế mình vẫn thường xuyên bị đồng nghiệp bảo là: “Mày đừng nói nữa, anh không hiểu gì cả!” - mình nghĩ m.n cố tình bảo vậy thôi chứ không phải do mình nói m.n không hiểu thật đâu :))


Vậy nên: chúng mình hãy cố gắng cải thiện kỹ năng giao tiếp để tốt hơn nhé. Mọi thứ sẽ dễ trao đổi hơn và bản thân mình cũng được mọi người đánh giá cao hơn. 😗


Và đây là câu chuyện về việc: Sắp xếp độ ưu tiên 🤐

Mình đã gặp tình huống như thế này:

Dự án đang UAT, trong giai đoạn đó thì team sẽ chờ feedback (FB) của KH, đồng thời fix các bug còn tồn đọng. Lúc đó mình đang ngồi query data và retest bug liên quan đến logic tính toán, bug này ảnh hưởng đến nhiều màn hình nên mình cần phải tập trung.


Và "bùm" - comtor báo rằng phía KH gửi FB: API của bên mình cung cấp bị lỗi, họ không gửi được request. 🫡


Mình định lặng lẽ ngồi test cho xong rồi mới xem FB đó, nhưng thấy PM với DEV ngồi điều tra lỗi quá trời nên mình mới quay sang bảo dev: "Anh thử xem body của request bên họ gửi đã đúng chưa?". Sẽ không có vấn đề gì nếu lúc đó mình cũng đang ngồi check cùng mọi người, nhưng mình không 🥴. Và vừa nói xong thì anh PM quay sang quạo: "Em cũng check đi, em là tester thì em phải check đầu tiên chứ!" …

Lúc đấy mình kiểu: 😀🙃🤔😒 - mình định giải thích nhưng lại thôi vì sợ anh ấy mắng.

(Anh PM của mình là sub-DL nên mình cũng hơi rén. Với do mình cũng *hiền nữa 😗)


Cuối cùng mình đành dừng việc đang làm lại để check FB với mọi người 🙂.

Con bé ngồi check FB trong im lặng, anh PM thấy thế nên ra ngó: “Anh nói không đúng hay sao mà không nói gì, dỗi à?” - Thật ra cũng hơi pực đấy :))

Xong anh PM nói với mình: “Sau gặp những tình huống như này thì em cứ ưu tiên kiểm tra trước giúp anh, bug để test sau cũng được”. Nghe xong thì mình cũng phải ngồi nghĩ lại.


Theo các bạn trong tình huống này thì mình nên làm gì trước?

Sau khi nghĩ lại thì thấy mình cũng hồ đồ thật. Đúng ra nên dừng việc test lại để check FB trước. Do tính chất dự án là outsource, UAT rồi mà còn bị lỗi API @.@

Việc API lỗi nghiêm trọng hơn việc mình ngồi truy vấn data. Vậy mà mình đã không nghĩ thế, làm PM phải nhắc nhở 🤕. Tester như vậy là có khả năng bị đánh giá không biết cách sắp xếp độ ưu tiên rồi đó.


Qua đây mình chỉ muốn nói: Kỹ năng đánh giá và sắp xếp độ ưu tiên ở bất kỳ công việc hay hoàn cảnh nào đều rất quan trọng. Kỹ năng này kém sẽ khiến mình bị đánh giá thấp trong công việc, nếu trong trường hợp team work thì cả team có thể bị ảnh hưởng như: chậm task, chậm tiến độ, bị KH claim, ...

Không phải ngày một ngày hai mà mình làm tốt được nhưng hãy làm nhiều, suy nghĩ, quan sát nhiều để học cách đánh giá và cải thiện kỹ năng này nhé!

 

Với cá nhân mình thì cả 3 kỹ năng trên mình đều chưa thật sự tốt và cần phải học hỏi rất nhiều. Vậy nên: nếu được hỏi "Bao giờ mình mới là tester xịn?" thì mình cũng khum biết nữa 😵‍💫


Còn với các bạn, hy vọng qua những tình huống “ố zề” của mình và những chia sẻ từ đáy lòng trong bài viết này sẽ có ý nghĩa với mọi người! ❤️


Bạn nào muốn đọc thêm về những kỹ năng khác thì có thể đọc ở post này nha, mình thấy liệt kê khá đủ các kỹ năng mà chúng ta cần đó: https://viblo.asia/p/mot-so-ky-nang-ma-tester-nen-co-Az45bNBz5xY


Trên đây là quan điểm cá nhân của mình. Ngoài ra nếu có góp ý hay các bạn cũng từng gặp những tình huống như vậy hoặc “ngáo” hơn nữa thì nhớ kể mình nghe với nhéee =))


Hẹn gặp lại ở bài viết tiếp theo. Bái baiii ~.~

Comments


© 2023 by ThuyNguyen ・hoctestdao

bottom of page