Xuất phát điểm là sinh viên ngành Công nghệ thông tin, nhưng chưa khi nào mình đủ tự tin khi nghĩ đến việc sau khi ra trường sẽ tìm được cho mình một công việc liên quan đến ngành học. Căn bản là mình không giỏi trong việc viết code, rất sợ code, mà đa phần khi xin việc toàn yêu cầu khả năng code ổn. Cho đến một hôm mình bén duyên với nghề QA (Software)/QC. Thoạt đầu, khi tìm hiểu về ngành nghề này, mình thấy toàn các thông tin như nghề này ấy không cần biết code đâu, làm nhàn lắm, ngồi nghịch mấy các sản phẩm Dev làm ra rồi tìm bug, defect báo cáo thôi, đơn giản dễ làm, ai cũng có thể apply, cũng chẳng cần học IT mà vẫn làm được,… Vâng và mình tin sái cổ cho đến khi đi phỏng vấn mới chợt té ngửa nhận ra, đó chỉ là những nhận định có phần chủ quan của một số ít khi đã thành thạo trong nghề. Thế là sau những lần bầm dập lên xuống, tất tả ngược xuôi phỏng vấn fail, mình đã ngồi suy nghĩ, sắp xếp lại những câu hỏi khi phỏng vấn được hỏi, tìm hiểu kỹ càng, tường tận hơn và từ đó rút ra kinh nghiệm để quyết tâm phỏng vấn thành công. Có lẽ may mắn đã mỉm cười với mình khi cuối cùng mình cũng được nhận vào vị trí QA của Sun, sau hơn hai tháng thử việc, nhờ sự chỉ dẫn tận tình của các chị Leader và các bạn đồng nghiệp, mình nghiệm ra vài điều thú vị về nghề này, và mình rất muốn chia sẻ đến mọi người, hy vọng có ích cũng như cổ vũ tinh thần những bạn đang hoặc sẽ có ý định đến với nghề QA.*

Xác định mục tiêu trước khi test và đừng chỉ test:

• Mình nhớ lần phỏng vấn đầu tiên, câu hỏi đầu tiên mình được hỏi là “ Em nghĩ thế nào là Tester, và tại sao cần phải Test”. Cho đến những lần phỏng vấn sau câu hỏi ấy luôn là câu hỏi tiền đề quan trọng. Và bây giờ câu hỏi ấy luôn trong tâm trí mình, mỗi khi nhận task của Leader giao, việc đầu tiên mình làm là nhớ về câu hỏi đó. Vì sao ư? Là vì khi bạn mong muốn trở thành một QA/QC bạn phải luôn hiểu về việc mình đang làm và sẽ làm, đóng góp như thế nào vào việc hoàn thành một sản phẩm hoặc kết thúc một project thành công . Nói dễ hiểu để trả lời câu hỏi ấy, bạn cần xác định mục tiêu khi tiếp nhận kiểm thử một sản phẩm – lấy ví dụ là một ứng dụng, không phải khi bắt đầu công việc, bạn lao vào tìm kiếm lỗi sai của ứng dụng, tìm mọi cách để moi móc những lỗi thiếu sót, thay vào đó, bạn hãy đặt mình vào vị trí của người dùng (user), dành một chút thời gian để sử dụng ứng dụng theo hướng chân thật nhất. Chỉ ra mục tiêu mà ứng dụng mong muốn đem đến user là gì. Khi bạn hiểu mục tiêu, mục đích sử dụng, bạn sẽ có thể hiểu mục tiêu của từng tính năng riêng lẻ. Khi bạn hiểu các chi tiết phức tạp của các ứng dụng thì khi ấy bạn sẽ có thể lên kế hoạch kiểm thử hiệu quả bằng một một kịch bản kiểm thử rất hiệu quả.
• Khi mục tiêu của bạn với tư cách là người kiểm thử phù hợp với mục tiêu của ứng dụng, bạn sẽ có thể mang lại kết quả thành công to lớn.

Đa tác vụ:

• Một QA luôn có khả năng đa tác vụ, nghe có vẻ hơi khó hiểu phải không nào, đừng lo, đa tác vụ mình nhắc đến ở đây là tất cả những thế mạnh về kỹ năng mà một QA cần xác định trau dồi, để ngày càng phát triển bản thân. Lấy ví dụ khi được giao task, bạn cần xác định độ ưu tiên của từng task, khi bắt tay vào công việc bạn cần xác định vấn đề nào cần được ưu tiên giải quyết trước, bạn không thể cứ làm theo bản năng và khiến mọi việc rối tung lên, khi ấy bạn sẽ rất khó hoàn thành công việc với hiệu quả cao, thay vào đó bạn cần cân nhắc kỹ lưỡng và sắp xếp thứ tự theo mức độ ưu tiên của công việc. Bên cạnh đó, bạn cần luyện tập khả năng động não suy nghĩ và liên tục đặt câu hỏi cho mình về đối tượng mình đang kiểm thử, chẳng hạn như: Làm thế nào để hiểu yêu cầu của khách hàng, để hiểu những thay đổi được thực hiện trong quá trình làm việc, để nhận biết đó là bug và cần phải fix,… tất cả những câu hỏi ấy sẽ khiến bạn tư duy liên tục, và nhanh chóng xác định được mình cần làm gì và làm như thế nào. Từ đó giúp bạn tạo ra được số lượng lớn ý tưởng táo bạo, thú vị, và hứng thú với công việc hơn. Bạn cũng cần phải có khả năng phân tích, phân tích dữ liệu, và đam mê thử nghiệm, nhờ vậy bạn có thể liên hệ từ những gì app hoặc dự án mình đang làm có mối liên hệ như thế nào đến thực tế, giúp bạn có cái nhìn bao quát hơn, và giúp bạn suy nghĩ tạo ra nhiều kịch bản kiểm thử (test case) xác thực, chính xác hơn.

Khả năng báo cáo:

• Môi trường làm việc của công ty mình chú trọng các yếu tố Báo cáo – Liên lạc – Bàn bạc, vậy nên từ đó giúp mình hình thành kỹ năng báo cáo khi làm việc. Bạn đừng nghĩ đây là yêu cầu khó khăn và gượng ép. Một QA thực hiện tốt công việc được giao là khi bạn hoàn thành công việc, bạn chỉ ra được kết quả chính xác bạn đạt được. Có nghĩ là trong quá trình làm việc, bạn cần thường xuyên trao đổi liên lạc, chia sẻ những gì bạn đang trải qua cùng team dự án hoặc gần hơn là Leader của mình, kỹ năng này sẽ giúp chúng ta luôn chủ động trong công việc, nhất là khi bạn gặp trở ngại, thay vì một mình bạn loay hoay với mớ lộn xộn, nếu bạn nói lên vấn đề của mình, chắc chắn mọi người sẽ hiểu và không ngại giúp đỡ bạn gỡ rối. Bạn cũng cần có kỹ năng có thể báo cáo những điều tiêu cực theo cách tích cực, nhưng không có nghĩa là khiến cho mọi thứ trở nên mù mờ, ở đây ý mình là bạn cần có thái độ tích cực, linh hoạt nhận biết vấn đề và nêu rõ cụ thể vấn đề chính từ đó giúp cho việc giải quyết thành công tốt đẹp hơn.

Thái độ tích cực:

• Bạn cần là một cá thể hòa đồng, linh hoạt có khả năng giao tiếp tốt và có thể hỗ trợ bất cứ khi nào các thành viên khác cần sự giúp đỡ, một dự án thành công không phải chỉ với một cá nhân, mà chúng ta làm việc theo tập thể, chúng ta là một team, mọi người cùng nhau tìm ra cách giải quyết khi gặp vấn đề khó khăn cũng như cần có sự đồng cảm lẫn nhau để thấu hiểu nhiều hơn, tạo cảm giác thân thiện môi trường làm việc sẽ chuyên nghiệp và đạt hiệu quả công việc cao hơn. Bạn cũng nên rèn luyện khả năng học hỏi thường xuyên và nhanh chóng nắm bắt kiến thức cũng như không ngừng trau dồi học hỏi. Trở thành nguồn cảm hứng và hình mẫu như mình mong muốn là yếu tố thúc đẩy chúng ta luôn xây dựng và hoàn thiện bản thân theo hướng tốt đẹp hơn mỗi ngày. Và một điều quan trọng hơn hết là hãy luôn cố gắng suy nghĩ theo hướng của khách hàng, việc đó giúp bạn sẽ có cái nhìn toàn vẹn hơn đối với yêu cầu của họ, khi đặt bản thân vào vị trí người dùng, bạn sẽ có nhiều hơn một mong muốn, và chính những suy nghĩ về lợi ích dành cho người dùng sẽ giúp bạn kiểm thử đạt hiểu quả cao và kết quả sẽ như mong đợi. Góp phần đem lại thành công cho dự án và chó cả team.

Làm thế nào để khi Dev nhận ticket mà vẫn vui vẻ?

• Từ trước đến nay, mối quan hệ luôn nhận được sự quan tâm nhiều nhất trong team dự án là giữa DEV và QA/QC, không phải tự nhiên mà mọi người thường hay lấy chủ đề về sự đối lập nhau giữa Dev và QA. Thật ra đây là vấn đề rất dễ hiểu, lấy ví dụ nếu đặt mình vào vị trí của Dev, khi một chức năng được mình ngày đêm bỏ công bỏ sức code nên, vậy mà trong chốc lát có thể bị đập bỏ, vì QA báo bug/ defect, họ có thể sẽ rất tức giận, và đau buồn. Và tất nhiên dẫn đến mâu thuẫn khi bên Dev cho rằng đó là tính năng còn QA nhận định là bug. Vậy thì ý chính mình muốn nói là gì? Để tránh các trường hợp tranh luận không đáng có, với vị trí của một QA, hãy nghĩ đến yếu tố tâm lý trước tiên, hãy luôn mang một tinh thần và mục tiêu là cùng đóng góp để xây dựng một sản phẩm chất lượng, đừng gay gắt ra lệnh, nó dễ làm ảnh hưởng đến tâm lý người nhận và dễ gây căng thẳng giữa hai bên, và như vậy chúng ta cần:
  
  Đây là một sơ đồ minh họa thú vị về việc tìm ra bug của chúng ta
• Về mặt test case, khi viết chúng ta cần clear những yêu cầu chính, bám sát yêu cầu khách hàng, các bước khởi tạo để test được chức năng hoặc module, tránh trường hợp test case không rõ ràng, dẫn đến sự xác định sai hoặc bỏ sót, đến khi gặp phải vấn đề sẽ gây tranh cãi với bên Dev.
• Tránh log trùng bug, bạn nên hạn chế thấp nhất vấn đề này, một vài lần xảy ra sẽ khiến dev “mất niềm tin” ở bạn, và làm mất cả thời gian của đôi bên nữa. Vì vậy, cần kiểm tra và lọc kỹ thông tin trước khi log bug, một vài chục bug có thể nhớ được chứ khi đã lên đến hàng trăm thì không thể chủ quan được! Và nhớ là mỗi bug/ defect chỉ nên tập trung vào một vấn đề, việc bạn tận dụng một ticket cho nhiều điều muốn diễn đạt sẽ làm người nhận khi đọc bị rối thông tin và không xác định được yếu tố nào quan trọng và cần xử lý ngay. Thế nên, bạn cần tránh việc này nhé!
• Về mặt log ticket bug/ defect, một bản report bug đầy đủ, chính xác, cụ thể các nội dung từng mục sẽ giúp cho việc tái hiện bug trở nên dễ dàng, và thuyết phục hơn. Vậy một bản report bug hoàn chỉnh là như thế nào, mình cũng xin được chia sẻ với các bạn chi tiết cách log bug để khi đến tay Dev họ vẫn vui vẻ nhận và fix bug.
  Một bản report bug gồm các nội dung sau:

1. Title của ticket: cực kì quan trọng vì đây sẽ là nơi Dev chú ý xác định bước đầu về bug/ defect, bao gồm vị trí xuất hiện bug (ở đây cụ thể là màn hình, chức năng,…), miêu tả lỗi bạn cần viết ngắn gọn nhưng dễ hình dung hoặc xác định mục tiêu gửi gắm, qua title này Dev phần nào sẽ hiểu được bug mình gặp và hình dung nhanh nhất:
   VD: [Bug/Defect][Màn hình X] Display screen default is wrong.
2. Pre-condition – Description (Điều kiện tiên quyết): Mục này sẽ là nơi chúng ta xác định môi trường test, tài khoản dùng để test, thiết bị test, thời gian test,…
3. Step to be executed: Đây sẽ là nơi bạn trình bày lại các bước tái hiện chính xác bug/ defect bạn gặp phải, tuyệt đối quá dài dòng, nhưng dễ hiểu và Dev có thể theo đó để tái hiện chính xác.
4. Actual result: Là kết quả thực, hoặc còn được gọi là kết quả bạn nhận được khi test. Đây là nơi bạn xác nhận bug mình đang gặp.
5. Expected result: Là kết quả bạn mong muốn nhận được, hay còn gọi là kết quả chính xác.
6. Priority/ Severity: Đây là nơi bạn xác định độ ưu tiên fix bug, bug quan trọng cần fix gấp hoặc ticket này cần fix nhưng chưa cần ngay trong đợt release này,…
7. Evidence: Đây là nơi bạn có thể thêm hình ảnh minh họa, video,… để diễn tả cụ thể chi tiết hơn việc tái hiện bug. Bạn cũng có thể dẫn chứng thêm về design, spec để cụ thể hóa yêu cầu đúng đắn cho kết quả test mong muốn
8. Ngoài ra bạn cũng cần gắn nhãn (tag) cho bug, để phân loại bug (bug type), việc này cũng quan trọng trong việc Dev tiến hành fix bug/ defect. Ngoài ra bạn cũng nên kiểm tra kỹ hơn trên các máy test khác để đảm bảo là nó không phải chỉ gặp vấn đề ở mỗi máy của bạn thôi, còn trên máy của người khác vẫn không vấn đề gì. Phải đảm bảo là bug này có thể tái hiện lại được.

• Nhưng vậy bạn đã có thể tự tin vào bản thân, tin là khi những anh Dev nhận được ticket từ bạn sẽ vui vẻ, sẵn sàng đón nhận đóng góp của bạn. Chẳng còn gì gọi là hiềm khích hoặc cau có không vừa ý nhau khi QA hiểu và cảm thông cho những nỗ lực của Dev, từ đó giúp hai bên giải tỏa căng thẳng hợp tác bền vững và đích đến là thành công hơn mong đợi.

Trên đây là những gì mình được học, được chỉ dẫn trong suốt quãng thời gian thử việc vừa qua, tất cả những gì mình đúng kết đều là từ sự chỉ dẫn tận tình của các chị, các bạn đồng nghiệp. Và quan trọng nhất là mình tìm được nguồn cảm hứng và thúc đẩy bản thân cố gắng nỗ lực hơn, xây dựng và phát triển các kỹ năng cần có, như vậy thì mình mới có thể phấn đấu vì mục tiêu tiến xa hơn trong sự nghiệp. Mình hy vọng các bạn cũng sẽ tìm được mục tiêu và lý tưởng công việc, và thành công với lựa chọn của bản thân nhé!

Tham khảo:

https://testlio.com/blog/how-to-be-an-efficient-software-tester/
https://www.softwaretestinghelp.com/10-qualities-that-can-make-you-a-good-tester/