Lại nữa, tôi muốn chia sẻ kinh nghiệm của tôi với các bạn về 1 chủ đề thú vị trong lĩnh vực kiểm thử phần mềm. Nó là 1 chủ đề nóng trong bất kỳ tổ chức nào nếu như là 1 Tester hay QA thì bạn có thể đoán được nó – không có gì khác đó là – Testers với Developers.
Testers ư? Những kẻ gây rắc rối
Thật buồn cười là, bằng cách nào đó mà hầu hết mọi nơi các dev luôn coi các tester là những kẻ gây rắc rối =))
Thực ra thì đó không phải là lỗi của họ, không ai muốn nghe thấy rằng tìm thấy lỗi của họ trong sản phẩm của chính họ cả. Cơ mà đó lại là việc của chúng tôi (tester) đang làm, tất nhiên, ý định chỉ là muốn mang lại chất lượng sản phẩm tốt nhất cho khách hàng mà thôi. Một cách thường xuyên, đó là có sự thù oán xảy ra những người ở 2 vai trò (dev vs tester) này.
Tại sao thế nhỉ?
Khi số lượng bug tăng lên hoặc các bug là nghiêm trọng và nó gây khó khăn cho các dev trong việc giải quyết chúng, làm cho họ cảm thấy thất vọng cho dù họ có là dev giỏi đi chăng nữa.
Thật nhé nhiều lúc có bug báo dev cứ nửa đùa nửa thật tính năng đó không phải bug đâu.
Vậy thì làm sao để tạo ra một mối quan hệ tốt đẹp và hiểu nhau giữa các Tester và Developer đây?
Kinh nghiệm của tôi đó là tinh thần làm việc nhóm và tình bạn là các giải pháp tốt nhất.
Nếu bạn có thể trở thành 1 người bạn tốt của 1 dev thì bạn có thể thách thức anh ta (Dev) và chắc chắn là người đó sẽ đón nhận việc đó một cách tích cực và làm nó tốt hơn. Nó sẽ là trách nhiệm của cả 2 để đảm bảo rằng đầu ra là tốt nhất. Trong khi đó các dev nên đảm bảo rằng sẽ chẳng có bug nào được sinh ra từ những cái họ đã làm ra.
Nói vui thế thôi chứ, làm gì có phần mềm nào là không bug, Dev mà làm ra cái sản phẩm không bug thì Tester cũng lo đấy =))
Các tester thì cũng nên đảm bảo rằng nếu có bug thì những bug này nên được chỉ ra, xử lý đúng thời điểm và phạm vi. Khi bạn là 1 QA và đang làm việc với một nhóm trong 1 thời gian dài, thì mối quan hệ giữa bạn và các dev sẽ trở nên thân thiết hơn.
Là một nhóm, bạn có thể làm việc cùng nhau để tìm ra các khiếm khuyết trước, việc này luôn luôn được đánh giá cao. Không chỉ thế, ngồi cùng nhau thảo luận về thiết kế và giải pháp có thể làm cho các dev nhận thức được các vấn đề và lĩnh vực khác nhau để nâng cao chất lượng sản phẩm. thus taking the quality mindset a step further.
Là một tester, bạn có thể tìm ra các khiếm khuyết nhưng sẽ thật là tốt nếu như bạn chia sẻ với các dev một số chiến thuật để kiểm thử ứng dụng. Có lẽ điều này sẽ giúp các dev kiểm thử tốt hơn trước khi giao sản phẩm. Nhưng mà điều này chỉ có tác dụng nếu tất cả mọi người có sự hợp tác đủ để có một cái nhìn chung về mục tiêu cuối cùng, ví dụ như là giao sản phẩm chất lượng.
Hãy cùng nhau chia sẻ những suy nghĩ của các bạn
Bạn nghĩ cách tốt nhất để làm cho mối quan hệ của dev và QA suôn sẻ là gì nào?
Đây là một số suy nghĩ của tôi về điều này:
#1) Chia sẻ chiến lược của bạn với các dev. Đừng giữ những suy nghĩ trong đầu và nghĩ rằng bạn đánh dấu nó như là một issue ở giai đoạn sau đó.
Kiểu như có thể bạn thấy nó có vấn đề nhưng không chia sẻ với dev mà lại ỉm đi để sau log bug đó. Thường trong trường hợp không rõ ràng hay nghi ngờ có vấn đề tôi thường hỏi dev để xác nhận xem liệu đó là spec hay không rồi sau đó mới log bug. Nếu không phải thì khỏi log tránh rác list bug.
#2) Cố gắng xây dựng một mối quan hệ thân thiết với các dev, như thế thì họ có thể thoải mái chia sẻ bất kỳ thứ gì với bạn.
#3) Hãy báo cáo các issue 1 cách tích cực, không nên làm tổn thương cảm xúc của người khác.
Cái này thì rõ rồi, cùng là bug nhưng mà cách nói sao cho dev không cảm thấy bị tổn thương thì chắc là việc tiếp nhận và fix nó sẽ nhẹ nhàng hơn rất là nhiều đó =))
6 cách để QA có thể làm việc với Dev tốt hơn
1. Tập trung vào chất lượng chứ không phải là việc kiểm thử
Kiểm thử chỉ là một phương tiện để kết thúc. Thường thì, các QA chạy các thử nghiệm như thể là họ đang mong đợi sẽ lấp đầy vào một số hạn ngạch để hoàn thành các thử nghiệm. Chúng ta phải nhớ rằng mục tiêu thực tế là nâng cao chất lượng của sản phẩm.
Hãy chắc chắn rằng bạn hiểu điều gì là quan trọng đối với khách hàng và kiểm thử nó. Đừng chỉ nhìn vào bản định nghĩa nhu cầu người dùng. Cố gắng suy nghĩ như một người dùng và chắc chắn rằng ứng dụng sẽ có ý nghĩa từ quan điểm của họ.
Luôn nghĩ về các người dùng của bạn và không kiểm thử chỉ để nói rằng bạn đã thực hiện kiểm thử. Người dùng không quan tâm bạn kiểm thử trên ứng dụng của bạn bao nhiêu lần – cái họ quan tâm là chất lượng sản phẩm và nó có đáp ứng nhu cầu của họ hay không mà thôi.
2. Chia sẻ trách nhiệm
Rất là đơn giản: Mọi người nên có trách nhiệm đối với chất lượng của sản phẩm. Trong một nhóm Agile, sẽ không có “chúng tôi” và “họ” nữa. Các Dev phải chịu trách nhiệm về code của họ và đảm bảo rằng họ viết các kiểm thử đơn vị có liên quan. QA nên kiểm tra toàn bộ hệ thống.
Vâng, QA tuy là những người gác cổng, nhưng khi đã thuộc cùng 1 nhóm Agile thì tất cả mọi người nên có trách nhiệm như nhau đối với chất lượng của sản phẩm.
3. Chọn các trận đánh của bạn
Là một người gác cổng, bạn không thể chiến đấu với mọi khiếm khuyết đơn lẻ. Bạn phải hiểu trận đánh nào đáng để chiến đấu và nơi bạn có thể buông tay. Bằng không, mọi người sẽ mất nhiều thời gian để sửa những thứ không quan trọng.
Đây là một mẹo: Xác định “Red line” của riêng bạn về những thứ mà bạn đơn giản sẽ không thỏa hiệp và chỉ tập trung vào chúng.
Nhiều nhóm thiết lập một “ủy ban khiếm khuyết”, xác định trước các lỗi trước mỗi sprint hoặc phiên bản được release. Điều này giúp tập trung được nỗ lực của mọi người lại.
4. Có tính xây dựng đối với các khiếm khuyết
Có một sự thật là: dù là kiểm thử bao nhiêu đi chăng nữa thì cũng không đảm bảo được rằng phần mềm không còn khiếm khuyết nào. Một số luôn luôn bị lack ngay cả khi sử dụng những quy trình kiểm thử nghiêm ngặt và sau đó chúng thường được phát hiện bởi người dùng bên ngoài.
=> điều này là chắc chắn luôn thi thoảng nhận được bug của Khách hàng trả về mà tim đập chân run và không tự đặt ra hàng ngàn câu hỏi vì sao lại có thể lack được.
Chìa khóa ở đây là hãy giữ bình tĩnh, rút kinh nghiệm thật nhiều từ những khiếm khuyết bị lack đó và nâng cao chất lượng hơn nữa ở những lần release tiếp theo.
Dev thích hỏi QA các câu kiểu như “Làm thế nào mà cái này vượt qua được bạn? Bạn đã không kiểm thử cái đó à?” Thực tế là phần mềm đó trở nên phức tạp và bạn không thể luôn luôn kiểm thử mọi kịch bản và cấu hình đơn lẻ được. Chúng ta tiến hành kiểm thử trên rủi ro và kiểm thử các luồng người dùng mà chúng ta thấy là quan trọng và phổ biến nhất dựa theo thời gian chúng tôi có.
Trong một số trường hợp chúng ta nên tham khảo ý kiến của quản PM (quản lý sản phẩm), các bên liên quan tới thương mại (sales, pre-sales, v.v.) hay thậm chí là chính khách hàng. Nếu một cái gì đó được thông qua trang web của chúng tôi, chúng tôi làm một cuộc phỏng vấn để tìm ra những gì đã xảy ra và tại sao chúng tôi bỏ sót nó, và, chúng tôi tạo ra một bản kiểm tra tự động cho các lỗi đã lack đó.
5. Tạo tầm nhìn vào các hoạt động của bạn
Tầm nhìn nâng cao sự hợp tác và tin cậy trong bất kỳ team nào, và các team Agile thì không phải là ngoại lệ. Bạn không nên cho rằng các nhà phát triển hoặc bất kỳ bên liên quan nào khác biết bạn đang làm gì, kiểm thử như thế nào hay các tiêu chuẩn của bạn là gì. Hãy cùng dev xem lại những gì bạn định kiểm thử nhé.
Khi bạn chia sẻ công việc của mình với các dev, họ có thể sẽ bắt đầu để tâm tới những thứ quan trọng. Có những ngày săn lỗi, cùng với các bên liên quan được bổ sung vào từ PM cho tới đội hỗ trợ và các kiến trúc sư, việc này không chỉ mở rộng phạm vi thử nghiệm hiệu quả, mà còn có nhiều ánh mắt hơn để xem xét sản phẩm 1 cách kỹ lưỡng. Rút ra những bài học quan trọng đã học được từ khách hàng, nó sẽ có lợi hơn bởi bạn đã như là một người đại diện cho những người dùng cuối.
6. Đừng buộc tội dev hay là người dùng
Tôi thường nghe QA đe dọa rằng họ sẽ không chấp nhận 1 tính năng vì nó có chất lượng thấp. Theo quan điểm của tôi thì, điều này thực sự là điều tồi tệ nhất bạn có thể làm như là 1 Tester. Hãy nghĩ tới kết quả ở đây: Với việc bạn không chấp nhận một tính năng, bạn xa lánh dev và tệ hơn là các người dùng của bạn cũng sẽ không có cơ hội để dùng nó.
Có nhiều thứ bạn có thể làm trong trường hợp mà chất lượng thấp: Có một nhóm được chọn lựa ra để nâng cao chất lượng; chỉ release phần đầu của một tính năng (phần mà chất lượng đủ tốt); và lập một danh sách để đi tiếp. Một chiến thuật phổ biến đó là đánh dấu một tính năng như “alpha”, “beta”, hay “truy cập sớm” để thiết lập nên những kỳ vọng.
Điều này có nghĩa là các người dùng sẽ có thể bắt đầu sử dụng tính năng mới, hiểu rằng điều này có lẽ là một chiếc bánh nướng được một nửa. Tôi nghĩ đây là việc giúp cho cả 2 bên cùng có lợi: Người dùng thì có được tính năng mới, rồi chúng ta thì sẽ nhận được phản hồi từ họ và cái được gọi là “lương tâm chất lượng” của chúng ta vẫn còn nguyên vẹn.
Tóm lại là cho dù có release 1 phần nhưng vẫn đảm bảo chất lượng tốt còn hơn là release toàn bộ sản phẩm nhưng lỗi tùm lum thì cũng chả để làm gì cả đâu ^_^
Kết luận
Vốn dĩ mối quan hệ giữa Dev và QA trước giờ thường khó hòa hợp. Nhưng hãy nghĩ tới mục tiêu chung cuối cùng của cả team đó là chất lượng sản phẩm. Chính vì thế đừng để những cảm xúc cả nhân làm ảnh hưởng tới tiến độ và chất lượng sản phẩm nhé.
Bài viết được dịch từ link:
https://www.softwaretestinghelp.com/how-to-make-developer-and-qa-relationship-healthy/
https://techbeacon.com/app-dev-testing/6-ways-qa-can-work-better-developers