Release testing là gì
ND: Em tưởng cái này cả team dev và test đều chịu trách nhiệm? DT: Mình nghĩ, cả Test, DEV và PM đều phải chịu trách nhiệm. PM là nặng nhất rồi đến Test và đến DEV. MH: Lòi bug hay là release không đúng business của khách hàng? TVT: Cáci này phải xem xem bug đó là loại bug gì, tại sao lại bỏ sót. Tester bỏ sót hay DEV update gì đó dẫn đến việc lòi bug mà Tester không biết. PQC: Mình ghét cái kiểu này. Tại sao có vấn đề là bắt đầu đổ thừa. Cho dù là ai, vai trò gì trong dự án, thì dù thành công hay thất bại cũng là thành quả chung của cả team. Note: mình là QC - không có ý bênh DEV nha. DT: Ừm, đúng rồi. QH: Mình không có ý là do team test, nhưng không hiểu sao bên dev mình đã xong gần 3 tháng, từ đó đến nay là bên kia test, mọi việc đánh giá OK. Giờ release ra có bug, quay lại chỉ có team dev là chịu trách nhiệm. QH: => ý kiến này là chính xác nhất. DT: Chính xác là suy nghĩ của mình á. Mỗi Công ty đều có luật riêng của họ. Có thể sót bug do lỗi của DEV. Có thể là do DEV làm thay đổi source code hoặc fix bug này lòi bug kia. HN: Nếu có team QA riêng chỉ nhận project test thì lúc này QC có tội. DT: Hoặc thay đổi yêu cầu mà không thông quan QC/QA. Hoặc là do merge code bi conflict. Trong trường hợp này, chuyện lòi bug thì DEV chịu trách nhiệm là đúng. HN: Chuẩn, mà đổ qua đổ lại chẳng giúp được gì, thay vào đó nên tìm cách khắc phục trước đã, rồi các team mới review lại xem trong quy trình nguyên nhân là do đâu. Do update code không đưa QC test hay do QC test thiếu case. Tiếc là thường ng ta đỗ thừa trước cái đã, xong điều tra ra là do mình xong cười trừ... Rồi còn trường hợp khôn nhà dại chợ, mình kêu fix không fix tới chừng client kêu fix cái rồi cắm cúi, trong khi issue raise lên từ rất là lâu. Thế là mình ngồi OT chung với DEV cả tuần lễ... Và còn thể loại nữa là: comment vào issue trên Jira this is a stupid bug, will not be fixed TVT: Bên mình không làm việc trực tiếp với khách hàng nhưng làm với bộ phận khác (tạm gọi là A). Những bug mình nghĩ là critical hoac comment không chính xác, mỗi tuần đều gửi danh sách này cho bộ phận A xem lại. NDH: Hai bạn cho mình hỏi chút thôi, sau khi raise lên cho cấp trên của Developer, có ai hỏi bạn đó là tại sao bạn ấy lại có những action như vậy không? Lý do bạn đó ghi ra là gì? TVT: Thường thì sẽ có 2 lý do. Tester không hiểu về thiết kế nên post bug sai gây ức chế. Việc này thường xảy ra với những bạn tester mới => trường hợp này bên mình không xảy ra vì khi tester báo cáo lỗi, QA lead phải kiểm tra lại rồi mới post lên hệ thống. NDH: Mình tin là QA khi post bug đều luôn xem xét kỹ. Nhưng Dev có nghĩ như vậy không? Ý là mình biết bên mình lý do là gi rồi. Nhưng mình muốn hỏi là Dev nói gì kia. Người ta giải thích gì về action của người ta? TVT: NDH: Không có process nào train để dev nói đó là stupid bug cả. Vậy Dev người ta có giải thích là tại sao người ta nghĩ vậy không? Mình biết là process là good, mình không hỏi về process. Mình hỏi là TVT có bao giờ hỏi tại sao Dev nghĩ vậy khi post những câu đó không? Người ta trả lời thế nào? TVT: Do ức chế NDH: Oh, là developer nói vậy? Vậy thì có vẻ ổn. Vậy bạn thấy Developer nói có hợp lý không? Ý là, yeah mình phải bắt hết bug, nhưng raise lên bug nhỏ lúc đó liệu có hiệu quả? Hay là những bug đó thật sự không nhỏ? Cho mình nói 1 lời công bằng, trong project chúng ta thường "làm hại" nhau mà không biết, chỉ đến khi chuyện phảil rồi thì thường mọi người chỉ review last recent actions để xem là ai đúng ai sai. - Đặc biệt là giữa QA và Dev. Dev ra build trễ --> QA test bug trễ --> Kéo theo Dev tiếp tục làm chồng task --> build trễ .... Nếu ở 1 node tụi mình review xem là lỗi của ai thì sẽ có lúc là lỗi của Dev có lúc là của QA. Thậm chí có khi là của PM, BA đã không làm tốt từ trước dẫn đến 1 trong 2 group kia phảil commiment. Nếu mình play trò blaming, mình đảm bảo là cả team bị đuổi việc thôi. Đưa lên cấp trên thì thực ra họ cũng có cách nhìn giống bạn thôi, chỉ là vì họ có nhiều authority để force được. Bạn thuận là QAPM chắc bạn cũng biết chuyện đó TVT: Khi mình gửi mail => sẽ có cuộc họp với bạn đó, người post bug, cấp trên của bạn đó để đả thông tư tưởng TVT: Vậy bạn thấy Developer nói có hợp lý không? Ý là, yeah mình phải bắt hết bug, nhưng raise lên bug nhỏ lúc đó liệu có hiệu quả? Hay là những bug đó thật sự không nhỏ? NDH: Khả năng cao là bạn đó sẽ nhận ra mình không đúng khi dùng những từ ngữ đó, cách hành xử đó. Nhưng mà bạn có chắc trong cuộc họp đó bạn có giải quyết được cái làm Developer "bực mình"? @TVT: Cho mình hỏi 1 câu cuối, bạn có thấy cách mình hỏi như vậy là hợp lý và nên dùng khi gặp vấn đề? NDH: Khi mình nói câu này thực lòng là mình không có ý nói móc gì đâu. Ở trường hợp của mình, Dev chỉ câm nín, nuốt tức vào và im lặng chấp hành. Chỉ mãi về sau này, khi Hải thân với Developer họ mới chịu nói riêng. Nên Hải thấy, nếu trong meeting mà bạn khuyến khích được Dev nói ra đã là hay lắm rồi. Chỉ là kn riêng của mình. TVT: Nó đã chịu nói ra thì phần lớn là giải quyết được. NDH: Là QA, Hải thấy lúc nào cũng có bug mình dáng lẽ có thể tìm ra sớm hơn, hoặc là ghi ra kỹ hơn, hoặc BA (cũng là mình) nên viết spec tốt hơn. Lỗi chẳng phải của chỉ Dev. mặc dù họ cũng đầy lỗi ra. That's it! Hải chỉ nói tới đây thôi. TVT: Cái này hoàn toàn đồng ý. Phải tìm hiểu theo nhiều hướng khác nhau. TVT: Đúng là sẽ có bug mình đáng lý ra phải tìm thấy sớm hơn nhưng mình sẽ không thể nào tìm hết tất cả các lỗi. Bên mình làm game, trung bình mỗi dự án có khoảng 10.000 bugs. Với tầm đó bug, không ai có thể đảm bảo được tất cả các bug sẽ được post mà không bị bỏ sót. Trong khi số lượng tester là hạn chế. Không thể nào test hết tất cả các chức năng trong tất cả các lượt test. Còn vấn đề ghi bug không kịp, mình có thể kiểm soát được bằng cách train nay từ đầu Đa phần những hiểu lầm là do bên này không hiểu qui trình làm việc của bên kia, một khi 2 bên hiểu thì vấn đề sẽ được giải quyết. TVT: Cuối cùng là khi dự án kết thúc tổ chức meeting tất cả các bên trong hợp lại, tất cả các vấn đề của dự án và cách giải quyết để tránh gặp lại những vấn đề tương tự trong các dự án khác trong tương lai. Những gì làm tốt thì nên phát huy,... Bên mình gọi là 'post mortem'. Công việc của mình có 50% là bên QA, và 50% là bên DEV nên khi bên nào có gì sai, mình đều phải tìm cách giải quyết NQD: Theo mình thì do QA đã post bug mà Dev không fix thì => do dev không đủ time thôi. Trừ khi nào bugs miss thì đó là do QA. Còn nếu DEV fixed hết rồi mà kh còn report bug nhiều thì dem QA ra xử. HN: Ở đây mình giải thích trường hợp của mình thôi nhé, 'this is a stupid bug' ấy, ở đây mình nói luôn cái issue là, mình muốn nút OK và CANCEL - nút OK phải nằm ở bên trái, vì tất cả những bảng confirmation khác đều như vậy. Còn raise lên leader thì anh chàng đó là leader rồi, còn các sếp họ nghe theo anh ta (dev) chứ không nghe theo mình (qc), và họ cho là những câu từ như vậy chẳng qua thể hiện 'thân mật' mà thôi. Còn mà trường hợp này post issue ở đầu dự án, không phải ở cuối hay giữa dự án luôn ạ, cty mình không có BA, chỉ có anh PM (là một trong các sếp mình đề cập ở trên) -> không phải ở đâu cũng có môi trường tốt... HN: -> Hoàn toàn đồng ý, nhưng cũng không có gì để bảo đảm 100% được là mình có thể phát hiện nó sớm, có thể ở version này không bị, ver sau mình bảo đảm 100% cover chỗ đó rồi nhưng quay lại thì lòi bug, cái này xảy ra cũng hơi nhiều... Còn về giải quyết như thế nào thì, ở đây mình nói luôn, bó tay nhìn bug mình post biến thành một tính năng. Mình raise issue, cung cấp thông tin, -> dev không fix -> các sếp đồng ý không fix thì thôi chứ sao giờ :d Vấn đề sỉ vả cá nhân kia mình cũng tiếp nhận luôn cách giải quyết đó là những từ ngữ 'thân mật'. Còn về vấn đề khác, lỗi không phải tại mình thì cũng 'chẳng phải tại ai' cả, nhất là 'không phải tại dev'. -> mình thì cười trừ và tiếp tục task thôi. Vì mình thực sự bị đỗ lỗi nên mới phải chứng minh bằng cách lôi các version cũ ra nói chuyện. ML: ý kiến của riêng mình thôi nha, bạn NH cố gắng đi, 2 bên không có tư tưởng giống nhau, thì đành theo ý kiến số đông, quan trọng là Sếp chốt như thế thì cứ y thế làm, và sau này gặp bug đại loại vậy, thì mình hiểu 'style' của team mình là vậy, thì mốt đừng raise cùng issue nữa. nói chung, kiến thức QC cứ giữ nguyên, chưa có đất để tung hoành thôi, 'mình hòa nhập nhưng không hòa tan' , sau này tìm dc môi trường lý tưởng, thì 'bay'đến nơi mình có thể làm việc hết mình, nơi có thể dùng hết tinh túy kiến thức mà thể hiện, giống như con tằm chăm chỉ nhả tơ, đến sợi tơ cuối cùng !!! |
