7 Thất bại đầu đời của nhân viên QA

nhan-vien-qa

Một nhân viên QA thường mắc phải những thất bại đầu tiên nào? Bỏ sót bug, mâu thuẫn với Developer và còn gì nữa?

Đọc ngay bài viết này để biết được:

  • 7 Thất bại đầu đời (hay giờ vẫn thế) của một nhân viên QA
  • Nguyên nhân của những sai lầm này
  • Bài học rút ra từ những thất bại trên

Tham khảo hàng trăm việc làm QA trên ITviec.

Đọc bản Tiếng Anh tại đây.

1. Chúng ta test mọi thứ

Là một người mới, tôi thường nghĩ là tôi có nhiệm vụ phải bảo vệ chất lượng của sản phẩm, mỗi case dù là nhỏ nhất đều cần test khi mới build xong vì chúng tôi không thể tin tưởng được ai hết. Chuyện quái gì cũng có thể xảy ra.

Sau đó tôi mới nhận ra rằng “Test trối chết” như vậy không hề khả thi và điều quan trọng là bạn phải xây dựng niềm tin với team của mình, thấy được các nguy cơ tiềm ẩn đúng hướng. Nếu không, bạn đang phí thời gian của mình và đồng nghiệp khi cứ test những cái không cần thiết hay không thể fail khi update.

Bài học của tôi là các nhân viên QA nên nói chuyện với Developer, cố gắng hiểu cái họ đang fix và dùng kiến thức của mình về requirement và hệ thống để quyết định case nào cần phải test hồi quy (Regression testing).

Việc làm QA tại TP HCM

Việc làm QA tại Hà Nội

2. Nhân viên QA không thể mắc sai lầm

“Bạn là cánh cổng chất lượng cuối cùng! Tất cả bug đều phải được phát hiện, bạn không được để sót bất cứ điều gì!”

Những câu này cứ văng vẳng bên tai tôi và có một thời gian nó ảnh hưởng rất nhiều tới mindset và phong cách test của tôi. Nếu tôi để sót một bug, thậm chí một bug nhỏ thôi thì tôi cũng cảm thấy khó chịu. Vì vậy, tôi không bao giờ chuẩn bị trước cho trường hợp tôi hoặc ai đó để sót một bug. Bạn biết sao không? Đó mới là vấn đề đấy!

Vấn đề là dù bạn có tránh đến cỡ nào những thứ quái quỷ này vẫn xảy ra mỗi ngày. Và nếu bạn không chuẩn bị khi chúng ập tới thì chúng sẽ tấn công bạn rất khiếp đấy!

Lời khuyên của tôi là ở mọi tính năng quan trọng, như những “upgrade task” (đổi cấu trúc database chẳng hạn), bạn luôn cần phải xây dựng một kế hoạch back up trong trường hợp có sai sót. Chuẩn bị cho thất bại trong những case như thế mới chứng minh được rằng bạn là một Senior QA.

Đọc thêm bài viết này để biết điều gì làm nên một nhân viên QA giỏi

3. Requirement là kinh thánh

Đó là cách nghĩ của người mới vào nghề. Chúng ta nhìn vào requirement và viết test case theo từng dòng trong đó, chúng ta không quan tâm requirement có hợp lý hay không, có hữu ích cho người dùng cuối hay không?

Sau đó, khi được lên cấp Senior và QA Lead, tôi mới có cơ hội tham gia vào các cuộc thảo luận viết ra requirement và thậm chí là các workshop về design. Tôi có thể thấy rằng có nhiều mâu thuẫn và đánh đổi khi tạo ra một quy tắc kinh doanh và ở vị trí QA, bạn hoàn toàn có thể góp ý hay trong cuộc thảo luận này để chuẩn bị cho những case thất bại sau này.

Bài học rút ra ở đây là: Requirement không phải là kinh thánh, nó có thể sai. Hãy chắc chắn rằng bạn cần phải tham gia và làm việc với team của mình để giúp nó tốt hơn.

Việc làm senior QA QC

Việc làm senior QA QC tại TP HCM

Việc làm senior QA QC tại Hà Nội

4. Developer là kẻ thù của tôi

Ôi trời ơi! Đó là những ngày đen tối và đôi khi giờ nó vẫn quay lại với tôi 🙂

Là một QA/QC bình thường trong một công ty Outsourcing, thì mỗi lần một sản phẩm thất bại, một bug xuất hiện, mọi ánh mắt hình viên đạn đều nhằm vào Developer. Họ là người code những tính năng đó và gây ra mọi bug! Họ chẳng đưa tôi thông tin để giúp tôi test gì cả! Họ luôn cho ra sản phẩm với vài thay đổi hay thiếu mất vài tính năng nào đó mà chẳng nói với chúng tôi! Và tôi tự nhủ với mình là đừng bao giờ tin họ, nếu họ nói “tốt mà” nghĩa là chắc chắn họ đang giấu bug đây.

Vấn đề là nếu bạn cứ để lộ ra mặt xấu nhất của mình, thì những người khác cũng vậy. Và mối quan hệ này sẽ giết chết bạn vì:

  • Không khí khi làm việc và thảo luận sẽ rất căng thẳng đến nỗi sẽ giảm năng suất của bạn và gây ra stress nhiều hơn bạn tưởng tượng.
  • Nếu bạn hối Developer quá mức thì họ sẽ thật sự giấu bug đi đấy! Dù chỉ để trả thù thôi, hay cứ hoãn việc lại mãi trước khi họ có thời gian fix nó. Và tin tôi đi, chỉ cần họ muốn, thì họ làm rất giỏi đấy!
  • Bạn đã bỏ đi một nguồn thông tin tốt về hệ thống khi bạn không có mối quan hệ tốt với Developer. Nó sẽ là một bất lợi lớn cho bạn mỗi lần sản phẩm mới ra. Nó cũng ảnh hưởng xấu đến những project dài hạn nữa.
  • Developer cũng giống bạn thôi, không thể tránh được sai lầm. Hãy cố gắng giúp họ tránh sai lầm sau đó, hay làm việc với họ để có một mục tiêu, estimation rõ ràng hơn để giúp họ code tốt hơn.

nhan-viec-qa

Nếu bạn muốn chuyển sang làm Developer, hãy đọc bài này của anh John Sonmez để biết cách chuyển đổi nhé!

5.  Chỉ làm End-to-End Testing

“Tôi không quan tâm cái mà Developer làm! Tôi chỉ cần biết nếu tôi là một người dùng cuối thì tôi có dùng sản phẩm này không, nếu có thì tôi cho qua.”

Nghe có vẻ hợp lý lắm, nhưng sự thật thì không như vậy. Có rất nhiều vấn đề trong hệ thống mà nếu bạn chỉ nhìn với tư cách là một người dùng cuối, bạn sẽ không bao giờ nghtĩ ra. Có một số function không bao giờ hiện ta trước mặt người dùng, ít nhất là người dùng cuối thông thường, chẳng hạn như API hay cron job. Tuy nhiên, đó là một phần quan trọng trong hệ thống và nếu nó thất bại, hệ thống cũng sẽ thất bại toàn tập.

Đọc thêm bài viết này để biết vài case tôi đã từng gặp nhé!

Hơn nữa, cứ nói là team của bạn mất 1 tuần để làm Back End, 1 tuần để làm Front End, bạn có được sản phẩm sau 2 tuần và mất 2 ngày để test. Trước khi bạn tìm thấy vấn đề nổi cộm nào thì đã quá trễ rồi. Bạn nên xem xét chuyện chia nhỏ việc testing ra và đi sâu vào hệ thống để tìm bug sớm hơn và có hiệu suất hơn.

6. Automation có thể giải quyết mọi thứ

Đây là vấn đề gần đây tôi hay nghe các Manager nói. Họ tin rằng nếu team có những kỹ năng đúng đắn và đủ thời gian, automation sẽ là giải pháp tuyệt đối cho Regression Test và tiết kiệm được chi phí. Sai lầm này đến từ quan điểm là Tester chỉ tập trung click vào sản phẩm để test, không làm gì hơn, và chuyện này rất dễ để tự động hóa.

Sai rồi! Đầu tiên, bạn vẫn cần một ai đó nhìn tổng thể busisness flow, technical flow để nghĩ ra test case.

Test case đâu có từ trên trời rớt xuống cho bạn được! Những hoạt động mà tôi nói đến thật sự cần kỹ năng phân tích rất nhiều, và chỉ có người ở cấp Senior liên tục nghiên cứu sản phẩm mới có thể giúp bạn. Thứ hai, có rất nhiều khía cạnh về UX, cần một người dùng thật nhìn vào sản phẩm để nói ra cảm nhận, không chỉ là nói “pass” hay “fail”. Bạn sẽ cần một QA có kinh nghiệm giúp bạn tìm ra những vấn đề này hay giúp bạn tổ chức lại những UAT session.

Đó là lý do tại sao tôi có nói là luôn cần phải có một Manual QA, hay ít nhất một người không tập trung vào viết code mà thật sự phải nhìn vào sản phẩm và nói “nó tốt hay không tốt?” Lời khuyên của tôi cho những nhân viên Manual QA là cần phải tăng bộ kỹ năng và kiến thức của mình lên nhanh chóng nếu họ không muốn bị chới với bởi những Automation QA.

Tham khảo bài viết này để biết công việc của Automation QA là gì.

nhan-vien-qa

Việc làm Automation QA

Việc làm Automation Tester

7. Cứ đổ lỗi hơn là cố gắng tìm giải pháp

Trở lại khi tôi còn trẻ, khi tôi để sót một bug, đầu tiên, tôi luôn cố gắng tìm lý do vì sao tôi bỏ sót nó, hoặc là cố gắng tìm một lý do để trách cứ ai đó. Có thể nguyên nhân là một Developer push code mới mà không báo ai cả, mà cũng có thể là cái gì đó không được ghi trong requirement.

Tuy nhiên, sau đó, tôi nhận ra rằng những thứ này không phải là vấn đề chính. Dù lý do là gì, thì ngay cả khi bạn đúng, vẫn sẽ có một khách hàng cảm thấy bực mình, và sẽ có nhiều hơn nếu chúng ta không hành động nhanh chóng.

Vì thế, kiềm chế cảm xúc của mình lại, bạn cần phải đảm bảo rằng chúng ta fix được vấn đề, hay chúng ta phải giải thích cặn kẽ với người dùng cuối để giúp họ hiểu được vấn đề và làm những gì có thể trước đã. Sau đó, về s au, trong buổi Root Cause Analyst, bạn có thể mang những vấn đề này ra và cố gắng cải thiện theo tinh thần có xây dựng. Bug đã xảy ra rồi, đừng làm nó tệ hơn bằng cách phá vỡ các mối quan hệ, nhớ đấy!

Còn bạn, bạn có những sai lầm nào khi làm nhân viên QA? Hãy chia sẻ với tôi nhé!

Tham khảo những mong đợi của nhà tuyển dụng qua các việc làm QA tại ITviec.

About the Author:

Guest Author

Hai has more than 6 years in IT industry with the role of QA in big IT companies. Read more...

Comments

error: