Tại sao tester quan trọng? Làm sao để chia sẻ tầm quan trọng của việc test với team của bạn?
Để tôi hỏi bạn 1 câu nhé: "Bạn có nhận được giá trị thực của việc test bạn đang làm?" Câu trả lời của bạn tùy thuộc vào team của bạn đang tham gia. Nếu bạn là một PM hoặc 1 dev, bạn sẽ nghĩ là "ồ, không, testing thực sự là vừa tồn kém vừa mất thời gian". Nhưng nếu bạn là một tester, bạn sẽ nói là ...
Để tôi hỏi bạn 1 câu nhé: "Bạn có nhận được giá trị thực của việc test bạn đang làm?" Câu trả lời của bạn tùy thuộc vào team của bạn đang tham gia. Nếu bạn là một PM hoặc 1 dev, bạn sẽ nghĩ là "ồ, không, testing thực sự là vừa tồn kém vừa mất thời gian". Nhưng nếu bạn là một tester, bạn sẽ nói là "Đương nhiên là testing rất quan trọng, nhưng team tôi dường như chỉ có tôi là người biết điều đó"
Vấn đề chia sẻ tầm quan trọng của việc testing
Trong 1 bài servey gần đây, tôi đã hỏi một số tester "bạn có thể đánh giá về tầm quan trọng của công việc bạn đang làm?" thì trên 80% trả lời là "không". Với cảm giác áp đảo như thế này, nó khiến tôi tự hỏi là điều gì khiến họ trả lời như vậy? Làm thế nào mà họ cảm nhận được "được đánh giá cao?" và "'tầm quan trọng của họ được định nghĩa như thế nào?"
Chắc chắn, dự án phát triển phần mềm nào nào thì cũng sẽ có manager, dev và QA thôi, nhưng khi nhắc đến câu hỏi "Chúng ta nên đầu tư vào QA?", thì câu trả lời chỉ là ý kiến chủ quan của người trả lời thôi chứ không có tài liệu nào đánh giá chính xác được mức độ quan trọng của QA trong dự án cả.
Bây giờ, tôi sẽ làm một thử nghiệm như thế này, tôi mời 1 người, 1 người là tester kiểm thử phần mềm tại Framgia (gọi là A), 1 người không phải là tester (gọi là B) cùng test 1 số cases/functions của dự án. Thật thú vị khi thấy sự khác biệt giữa cách thức làm việc giữa 2 người này. Người B hiểu rằng công việc kiểm thử này chính là tìm ra các lỗi không có giá trị và sẽ không được fix trong khi lãng phí thời gian quý giá để chạy các testcase. Trong khi đó, người A có thể nhận thấy được giá trị trong việc thu thập thông tin và trình bày thông tin về sản phẩm để giúp các bên liên quan đưa ra quyết định tốt nhất. Bugs là 1 sản phẩm và việc test là 1 điều cấn thiết.
Như bạn thấy, có các khoảng cách vô hình giữa team dev và test, và theo kinh nghiệm của tôi, đây chính là kết quả của việc thiếu liên kết, nói chuyện giữa các team.
Đừng nói chuyện với cái máy điều hòa
Chia sẻ tầm quan trọng của việc test nó không đơn giản là việc trò chuyện trong bữa ăn trưa. Coi đối phương như cái điều hòa, chỉ để bạn xả stress hay làm dịu mát. Các nhà truyền thông vỹ đại biết cách làm thế nào để chia sẻ thông tin theo cách tạo hiệu ứng cảm nhận được cho tất cả những người tham gia? Vậy tester chúng ta làm việc đó như thế nào? Chúng ta cần đặt ra chiến lược: thu thập dữ liệu mà các bên liên quan cần có, tổ chức sắp xếp các thông tin này phù hợp và sâu đó đảm bảo những thông tin này được xử lý đúng cách.
Trong nhiều trường họp, chúng ta thấy rằng dữ liệu test không thực sự có giá trị vì tester không thể truyền tải được mức độ quan trọng của task mà họ đang làm, cũng như mức độ quan trọng của công việc họ đang làm.
Vì vậy, hãy cởi mở hơn, tiếp xúc và giao tiếp nhiều hơn, và đương nhiên bạn phải tự tin rằng, nếu không có bạn thì sản phẩm chắc chắn không bao giờ có chất lượng cao cả. Bằng cách truyền đạt các thông điệp đó một cách chân thành và chính xác. Đồng thời hãy thể hiện tầm quan trọng của bạn qua công việc. Càng ngày giá trị của bạn sẽ được khẳng định.
Thông điệp của bạn rất quan trọng - đảm bảo rằng bạn có đủ dữ liệu để khẳng định điều này
Công việc của chúng là là tester, chúng ta phải thu thấp dữ liệu về sản phẩm và tình trạng của dự án. Một số thông tin ấy rất quan trọng, trong khi các dữ liệu khác có thể không thích hợp với các bên liên quan. Với tư cách là 1 tester hay 1 tester leader, điều quan trọng là không ngừng học hỏi, trau dồi kiến thức về testing mà dự án hiện tại của bạn cần, và đảm bảo rằng hoạt động test của bạn đang diễn ra theo các thông tin bạn đã thu thập và xử lý chúng. Và, nếu dữ liệu của bạn nằm rải rác trên nhiều nguồn, bạn có thể gộp chúng lại như 1 bức tranh toàn cảnh để bạn có cái nhìn tổng quan và đương nhiên là truyền đạt nó đến mọi người một cách rõ ràng nhất.
Ví dụ, bảng dưới dây trình bầy một loạt các thông tin giúp bạn truyển tải được giá trị của công việc bạn đã làm. Trong trường hộp cụ thể này, tester đã thu thập được các thông tin quan trọng về các loại bugs đã được tìm thấy, số lượng các issues mà dự án gặp phải, status của các issue này, và thậm chí cả ai đang giải quyết issue nào. Sự ngắn gọn và rõ ràng trong bảng dưới dây giúp cung cấp thông tin liên quan cho cả dự án trong quá trình họp, và đương nhiên sẽ là cái quan trọng để mọi người trong dự án có thể đánh giá công việc của test team.
"Giải thích" cũng không kém phần quan trọng
Theo kinh nghiệm của tôi, tất cả các thông tin truyền tải tốt nó sẽ phải tuân theo một vài tiêu chí quan trọng. Làm việc với các bên liên quan, tôi muốn tuân theo tiêu chí "SMART"
- Đơn giản
Hãy cố gắng truyền tải thông điệp của bạn bằng 1 dòng thay vì 1 đoạn văn dài loằng ngoằng. Bất cứ lúc nào bạn cũng có thể sử dụng biểu đồ thay vì sử dụng từ ngữ. Giả sử người đọc của bạn có rất ít thời gian và người ta chỉ chú ý đến những gì bạn nói trong 1 khoảng thời gian rất ngắn.
- Có thể đong đếm được
Các con số và thông kể có sức mạnh hơn là các quan điểm hay các mô tả. Điều này không có nghĩa là quan điểm/ý kiến của bạn không có giá trị - đôi khi với kinh nghiệm bạn chỉ cần biết câu trả lời dựa trên cảm giác của bạn - nhưng hỗ trợ cảm giác này với dữ liệu cứng và bằng chứng thì có sức thuyết phục và tin cậy hơn.
-
Có thể thực hiện được Phân tích số liệu có hiệu quả nhất định khi nó gợi ý một phương pháp giải quyết thay vì chỉ ra những điểm sai sót. Trong nhiều trường hợp, bạn, là 1 tester, là nguồn kiến thức vô hạn. Sự khiêm tốn luôn là điều quan trọng, nhưng nếu bạn có một phương án giải quyết, thì đừng ngại nói ra.
-
Có thể lặp lại Khi bạn cung cấp thông tin về các vấn đề/issue xảy ra, bạn chắc chắn được hỏi về tình trạng trước kia của issue đó. Câu hỏi thường gặp nhất bạn nghe được đó là "Đây có phải là một sự lặp lại?" Điều này có nghĩa là việc test của bạn cần được lặp lại và bạn nên cố gắng lưu lại các thông tin thay đổi, lịch sử update bất kỳ khi nào có thể.
-
Thời điểm hợp lý Cung cấp thông tin trong khi nó có liên quan đến các vấn đề, mà các vấn đề này được manager hoặc leader hoặc đồng nghiệp của bạn có thể đưa ra được các quyết định đúng đắn hơn. Nếu bạn nói điều đúng, nhưng sai thời điểm thì đương nieen nó sẽ có hoặc là rất ít hoặc là không có tác dụng gì cả. Ví dụ, bạn tìm ra 1 issue mà nó phải mất nhiều tuần để giải quyết trong khi chỉ còn có vài ngày nữa là phải release, có nghĩa là nhóm của bạn sẽ bỏ qua vấn đề hoặc là hoãn release. Bạn nên nhớ rằng, hãy luôn giữ đúng lịch release, vì bất kỳ issue nào cũng đều có thể được giải quyết.
Nhớ rằng cái bạn đưa ra là thông tin chứ không phải là việc testing
Chúng tôi - những tester phạm tội lỗi gì à? mà sao tổ chức lại luôn đánh giá thấp chúng tôi?
Nếu tất cả những gì chúng ta đang làm là execute test, phàn nàn về việc thiếu môi trường test hoặc đơn giản là đặt lại các bảng với hàng tấn dữ liệu mà mọi người không thể hiểu được, thì thực sự chún ta không giúp gì được cho quá trình deliver sản phẩm Đã đến lúc chúng ta hiểu 1 điều căn bản này, công việc chính của chúng là là giúp đỡ đưa ra những quyết định để có thể deliver sản phẩm đúng deadline và đúng scope. Đây là công việc khó chứ không chỉ đơn giản là execute test và report hằng ngày. Chúng ta có trách nhiệm giữ đúng hướng cho dự án, cũng giống như giữ đúng hướng cho thuyền buồm ra khơi.
Refer: http://blogs.atlassian.com/2017/03/software-testing-important-share-value-team/