Những thất bại và những điều QA cần biết.

I. Những sai lầm chúng ta cứ ngỡ là đúng đắn

1. Phải test mọi thứ

Trước đây mình đã nghĩ là phải có trách nhiệm 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ì không thể tin tưởng dev được. Sau đó mình mới nhận ra rằng 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, chỉ là đang phí thời gian của mình và đồng nghiệp Bài học của mình là các nhân viên QA nên nói chuyện với dev, 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 để cùng đưa ra hướng xử lý hợp lý ngay từ đầu và có được những ma trận test phù hợp

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

“QA 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, 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 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 mình. Nếu mình để sót một bug, thậm chí một bug nhỏ thôi thì cũng cảm thấy khó chịu. Vì vậy, mình không bao giờ chuẩn bị trước cho trường hợp mình hoặc ai đó để sót một bug. Như vậy có thụ động quá không nhỉ.!? Vấn đề là dù mình có tránh đến cỡ nào thì nó vẫn xảy ra mỗi ngày. Và mình thấy rằng ở mọi tính năng quan trọng, như những “upgrade task” (đổi cấu trúc database chẳng hạ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. Xử lý các sai sót đó một cách overview hơn để đảm bảo sai lầm không được nối tiếp sai lầm.

3. Requirement là kinh thánh

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? Những nội dung không thống nhất, không hợp lý, hướng xử lý sai lầm đều có thể tồn tại trong spec khi người viết spec đi theo một hướng nhìn khác. Nên việc bạn có những suy nghĩ khác, cách nhìn khác chỉ ra được điểm chưa hợp lý trong spec là một việc rất cần thiết. Một vấn đề luôn cần phải được nhìn từ nhiều hướng.

4. Developer là kẻ thù của QA

Dev chẳng đưa tôi thông tin để giúp mình test gì cả! Dev 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 QA! Đôi khi mình tự nhủ với mình là đừng bao giờ tin dev, 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 cứ để lộ ra mặt xấu nhất của mình, thì những người khác cũng vậy. Sau đó, mình đã nghĩ lại là với mối quan hệ như vậy sẽ giết chết mình 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 và gây ra stress nhiều hơn tưởng tượng.
• Nếu hối dev quá mức thì họ sẽ thật sự giấu bug. Hay cứ hoãn việc lại mãi trước khi có thời gian fix nó.
• Mình đã bỏ đi một nguồn thông tin tốt về hệ thống khi không có mối quan hệ tốt với Developer. Nó sẽ là một bất lợi lớn cho mình mỗi lần có update. Và cũng ảnh hưởng xấu đến những project dài hạn nữa. => Developer cũng là người và cũng giống như QA, không thể tránh được sai lầm. Cố gắng giúp dev tránh sai lầm hay làm việc với dev để có một mục tiêu, estimation rõ ràng hơn để giúp dev code tốt hơn.

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

“Tôi không quan tâm cái mà Dev 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 chỉ nhìn với tư cách là một người dùng cuối, bạn sẽ không bao giờ nghi 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 . Hơn nữa, cứ nói là team sẽ mất 1 tuần để làm Back End, 1 tuần để làm Front End, QAcó được sản phẩm sau 2 tuần và mất 2 ngày để test. Khi tìm thấy vấn đề nổi cộm nào thì đã quá trễ rồi. 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ứ

Nhiều người 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í. Điều này mình nghĩ chưa thật hợp lý Dự án vẫn sẽ 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 được. Những hoạt động mà mình muốn nói đến thật sự cần kỹ năng phân tích rất nhiều 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”. Lúc này sẽ cần một QA có kinh nghiệm giúp dự án tìm ra những vấn đề này hay giúp tổ chức lại những UAT session. Đó là lý do tại sao 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?”

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

Trước đây khi mình để sót một bug, đầu tiên, mình luôn cố gắng tìm lý do vì sao 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 Dev 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 đó, mình 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 mình đú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, 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ề sau, trong buổi Root Cause Analyst,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!

II. Những yếu tố quan trọng đối với một QA:

1. Về technical:

Được đào tạo và có kiến thức nền tảng về IT, lập trình: Nghề QA đòi hỏi kiến thức rộng hơn là kiến thức sâu. Ví dụ một QA quá tập trung vào ngôn ngữ nào đó và gặp dự án viết bằng ngôn ngữ lập trình khác, hoặc domain knowledge khác, bạn đó chắc chắn gặp rắc rối. Những kiến thức domain đặc thù như tài chính, health care, banking… đều cần thiết. Đôi khi có những dự án đặc thù về banking, thì khách hàng sẽ bỏ qua tiêu chí chọn QA có IT background, vì khi đó background về domain knowledge banking có lợi thế hơn. Kiến thức về hệ thống phần mềm và chuyên nghành QA. Ví dụ như một QA khi test ứng dụng web, nhưng không hiểu cấu trúc của ứng dụng web là thế nào, nó được hình thành thế nào, người đó sẽ không thể nào cống hiến tốt cho việc đảm bảo chất lượng.

2.Về soft skill

Kỹ năng giao tiếp tốt: Một ví dụ điển hình trong nghề là khi người test tìm thấy một bug và report cho developer, developer không đồng ý đó là lỗi và xảy ra tranh luận, ảnh hưởng đến teamwork. Một QA có kỹ năng giao tiếp tốt có thể giúp developer hiểu được đây là lỗi cần phải sửa, dù là theo yêu cầu hệ thống hay là theo bất cứ tiêu chuẩn phần mềm nào. Cẩn thận, suy nghĩ thấu đáo: Ví dụ một Tester đang thực hiện manual testing về ứng dụng web, và gặp lỗi nhỏ về UI, rồi bỏ qua nó, nhưng khi đến với khách hàng thì lỗi này làm họ khó chịu. Người QA cần kỹ năng làm việc cẩn thận + suy nghĩ thấu đáo để chú ý đến từng vấn đề nhỏ nhất. Tư duy sáng tạo: Nếu chỉ test những case thông thường thì đôi khi không đảm bảo tất cả các trường hợp xảy ra lúc hệ thống vận hành tại các môi trường bên ngoài. Do đó, tư duy sáng tạo giúp QA thiết kế test lạ, sáng tạo, và giúp tìm được những lỗi có giá trị cho việc đảm bảo chất lượng.

III. Reference:

https://itviec.com