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

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. Đ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. Hãy 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).

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.

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ị 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 bạn sẽ tham gia và làm việc với team của mình để giúp nó tốt hơn.

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.

Developer 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. Thậm chí, nó còn 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 đó. Hãy 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.

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ờ nghĩ ra.

Có một số function không bao giờ hiện ra 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ứ cho là team của bạn mất 1 tuần để làm Back End và 1 tuần để làm Front End. Bạn sẽ 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.

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 thì việc đầu tiên tôi làm là 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. Con số này sẽ nhiều hơn nếu chúng ta không hành động nhanh chóng.

Vì thế, hãy kiềm chế cảm xúc của mình lại, 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 đó, 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 với tinh thần 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!

Tham khảo:

• https://www.linkedin.com/pulse/firstsevenfailures-qa-nguyen-duong-hai
• https://itviec.com/blog/nhan-vien-qa/