Một người kiểm thử có tâm

Bài viết được sự cho phép của tác giả To Thi Van Anh

Bạn nghĩ thế nào là một người kiểm thử có tâm? Có giống như một người chụp ảnh có tâm mà bạn vẫn dành cho người nào chụp cho bạn bức ảnh mà bạn thấy bạn xinh lung linh nhất không?

  A/B testing và những tiêu chí chính để đánh giá sự thành công của ASO
  Automation skills cho tester già mà lười

Mình thấy là làm gì mà có tâm một chút là cũng được người ta yêu quý hết – mặc dù không biết trong lòng người ta nghĩ thế nào nhưng mà cứ khen là ta phải vui cái đã! hihi

Trong công việc cũng vậy, làm việc tốt không phải chỉ vì đồng lương mà còn là trách nhiệm đối với cái mình đang làm, đầu tiên cứ phải là cố gắng hết sức đã, kết quả có thể đạt được như mong đợi, có khi còn hơn, rồi cũng có khi không được như mình mong muốn ban đầu nhưng mà mình vẫn tin là dù thế nào tự chúng ta cũng sẽ rút ra được một số bài học nào đó cho bản thân, để lần sau tiếp tục cố gắng nhiều hơn nữa, và quan trọng là sẽ không mắc phải sai lầm giống như trước nữa. 😀

Blank poster in a white loft interior with sunlight, mock up, 3d render

Dưới góc nhìn của mình (có tham khảo một vài nơi mà mình đã tìm hiểu được) mình sẽ đưa ra một so sánh nho nhỏ để các bạn thấy được một người kiểm thử có tâm và chưa có tâm khác nhau ở những điểm nào nhé. Các bạn có thể để lại bình luận và nhận xét phía dưới cho mình về các ý dưới này nếu có điểm gì đó chưa đúng hoặc cần bổ sung nhé!

Yếu tố Người bình thường (Chị A) Người có tâm (Chị B)
1. Chất lượng test case Chị A nghĩ rằng chị chỉ cần viết test case với một chất lượng ở mức bình thường và có thể chấp nhận được là được.
Test case chị viết có thể là đã đủ theo các yêu cầu của hệ thống, nhưng chị lại không quan tâm đến việc tối ưu các test case mà chị đã viết, chị cũng không quan tâm lắm đến việc các bước thực hiện của chị nhiều chỗ hơi rườm rà và đôi khi thì lại chưa đầy đủ và không dễ để thực hiện lắm!
Có thể vấn đề của chị chị nhìn ra rồi, hoặc chưa nhìn ra. Cơ mà chị vẫn chẹp cho qua!		 Chị B thì khác, chị ciết test case với chất lượng rất tốt, chi tiết và đầy đủ các thông tin và trường hợp cần thiết, và kết quả review của người khác dành cho các test case mà chị viết không có quá nhiều comment.
Mọi người rất ấn tượng với test case của chị B vì sự chi tiết và cẩn thận từ những chi tiết nhỏ, rồi từ chất lượng cho đến sự trình bày.
2. Chất lượng bug Chị A nghĩ rằng viết bug cũng chỉ đơn thuần là viết bug, để cho thằng dev biết là mày đã làm sai, hệ thống đã có bug, đôi khi với nhiều trường hợp có thể cung cấp thêm được thông tin nhưng chị lại không đưa vào, hoặc có khi hơi sơ sài nữa. Không chỉ là viết bug, chị B còn cung cấp thêm đầy đủ thông tin giá trị đầu vào của trường hợp này, chị cũng tìm hiểu thêm và sâu hơn những nguyên nhân liên quan khác có thể gây ra vấn đề đó, giúp dev có thể debug và giải quyết vấn đề nhanh hơn.
3. Hiệu quả log bug Chị A log bug cũng tốt nhưng đôi khi chính chị hoặc dev không tái hiện lại được bug mà chị đã log.
(Đọc cột bên cạnh để thấy là chị A có thể thiếu gì nhé :v)		 Trước khi lug bug, chị B đã thực hiện kiểm tra kỹ càng nhiều lần hệ thống trên môi trường test của chị và cả ở môi trường trên máy khác nữa. Chị cũng luôn luôn cung cấp đầy đủ các tài liệu và thông tin cần thiết khi viết bug như: thông tin bản build, hệ điều hành, hình ảnh bug, các bước thực hiện để đảm bảo rằng là ai cũng có thể tái hiện được cái bug này.
(Chắc là chị B đã đọc bài về viết bug hiệu quả của mình rồi, bạn nào chưa đọc thì đọc để như chị B nhé Kaka)
4. Trong quá trình kiểm thử Chị A có phương pháp tư duy và hành động theo lối mòn, không có hoặc rất ít sự sáng tạo và cải tiến, chỉ biết đến duy nhất công việc của mình.
Qua bao nhiêu vòng test, chị vẫn chỉ làm như thế, chắc là chị chưa biết đến các nguyên tắc của kiểm thử phần mềm, hoặc là chị không quan tâm!		 Chị B thì khác, không chỉ biết đến công việc của mình, mà còn luôn suy nghĩ để hướng đến những kịch bản kiểm thử tốt hơn, tìm ra những hướng tiếp cận kiểm thử mới, để việc thực thi test case ngày càng hiệu quả hơn.
5. Thái độ đối với công việc Chị A làm việc với suy nghĩ chỉ là làm cho xong công việc của mình mà thôi. Chị B bên cạnh hoàn thiện công việc của mình, bên cạnh đó luôn suy nghĩ để cải tiến chất lượng của hệ thống. Đưa ra các quy trình tốt hơn, những sáng kiến, ý tưởng tốt hơn để đơn giản hóa công việc kiểm thử, giúp nâng cao hiệu quả và nỗ lực kiểm thử của chị cũng như của đồng nghiệp.
6. Mức độ quan tâm đến hệ thống làm việc Chị A là người kiểm thử nhưng chỉ nắm được hệ thống chỉ đến một mức hạn chế nào đó.
Ví dụ, giao cho chị các phần này thì chị chỉ biết đến phần đó, còn của người khác ra sao như thế nào thì hầu như chị không quan tâm! Cũng không suy nghĩ phía dưới hệ thống làm gì, có gì!		 Bên cạnh các phần được giao cho mình, chị B luôn luôn dành thời gian để khám phá để hiểu sâu hơn chi tiết hơn về hệ thống mà chị đang làm việc. Khi được bàn giao hệ thống, chị có thể chưa biết nhiều về hệ thống đó, nhưng chị là người mà nhất định sẽ đi sâu tìm hiểu những ngõ ngách, những chi tiết nhỏ nhất của hệ thống, và để hiểu về tất cả những cái phức tạp, sự phụ thuộc và liên quan lẫn nhau giữa các chức năng, những thông tin xử lý phí sau…
7. Góc nhìn của tester Chị A nghĩ rằng, mình là kiểm thử thì mình chỉ việc kiểm tra hệ thống với góc nhìn của một kiểm thử là đã ok rồi Chị B thì lại thực hiện kiểm tra hệ thống dưới góc nhìn của một khách hàng.
Chị B nghĩ rằng một người có tâm luôn đặt mình vào vị trí của khách hàng để kiểm thử hệ thống của mình.
Chị cũng nghĩ đây một yếu tố then chốt quyết định việc chúng ta có thể sử dụng hệ thống theo cái cách mà một người dùng thực sự mà họ sẽ dùng, để từ đó có thể  đưa ra được những kịch bản thực tế và giống thật nhất.