7 Thất bại đầu đời của nhân viên 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).

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à ở 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.

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