Dogfooding là gì

🐾 Lần đầu tiên mình nghe cụm từ Dogfooding là lúc vào làm QA (Quality Assistant) tại Atlassian, khoảng đầu năm 2014. Khi nghe cụm từ “dog food” mình rất ngạc nhiên và không hiểu nó nghĩa là gì. Hôm nay vô tình gặp lại, quyết định chia sẻ cho bạn nào chưa biết thì bây giờ biết nhé.

Dogfooding (còn gọi là Eating your own dog food.) là mô tả việc một công ty sử dụng sản phẩm hoặc dịch vụ do chính họ làm ra. Ví dụ trong quá trình phát triển các sản phẩm/dịch vụ của họ như Jira, Confluence, Bitbucket, v.v… thì Atlassian sử dụng Jira để quản lý dự án, Confluence để quản lý và chia sẻ yêu cầu, Bitbucket để lưu trữ source code (mã nguồn) và Bamboo để quản lý CI/CD (ngày nay thì Bitbucket làm tốt luôn việc đó). Tương tự, chắc tập đoàn Google họ sẽ không sử dụng Outlook hay Hotmail mỗi ngày.

Vậy có thể định nghĩa ngắn gọn, dogfooding hay eating your own dog food là việc sử dụng chính sản phẩm hoặc dịch vụ của chính mình, kể cả các phiên bản mới nhất (thường còn nhiều lỗi) trước khi đưa đến tay người dùng.

Lịch sử của từ này

Theo một bài viết mình đọc được trên trang IEEE Software thì cụm từ này được sử dụng từ những năm 1980, lúc mình còn cởi truồng tắm mưa và nhiều bạn ở đây còn đang ở dưới đầu gối ^^

Trích nguyên văn

Back in the 1980s when actor Lorne Greene served as the pitchman for Alpo dog food, the TV commercials were careful to point out that he indeed fed Alpo to his dogs. So, the idea that someone would use the products they were making became known as “eating your own dog food.” 

Tạm dịch (Becky tài trợ chương trình này)

Từ “dogfooding” đến từ diễn viên Lorne Greene, khi ông ấy làm người đại diện bán hàng cho thức ăn cho chó hiệu Alpo vào những năm 1980. Để đảm sự uy tín cho sản phẩm, các chương trình quảng cáo trên TV đã nhấn mạnh rằng chính thú cưng của Greene đã trực tiếp dùng các sản phẩm này của hãng. Vì vậy ý tưởng người ta sử dụng các sản phẩm do chính họ làm ra được gọi là “ăn thức ăn cho chó của chính bạn.”

Hiện nay có nhiều công ty phần mềm nổi tiếng, nhất là những Công ty phát triển sản phẩm (Product-led company, mà tiếng Việt chúng ta hay gọi là “công ty product” khi so sánh với các “công ty outsource”) cũng đã chấp nhận rộng rãi cụm từ dogfooding này. Có thể kể đến Microsoft, Atlassian, hay JetBrains.

Lợi ích của eating your own dog food

Tại sao các công ty phát triển sản phẩm thì nên áp dụng dogfooding? Lợi ích của việc này là gì?

Trước tiên có thể nói, chính việc sử dụng sản phẩm, dịch vụ của chính mình cung cấp thì đỡ tốn tiền (free). Ở Atlassian mình sử dụng “tẹt ga” (full topping như các bạn order trà sữa) riết quen rồi. Khi ra công ty khác thì các sản phẩm Jira, Confluence lại thấy tù túng, thiếu nhiều “đồ chơi” nếu họ không mua những plugin đó như Capture for Jira và Team Calendar trên Confluence.

Thứ hai, vì sử dụng sản phẩm, dịch vụ do chính mình làm ra, nếu mình không thấy hài lòng (ví dụ khó sử dụng, không mang lại lợi ích thật sự cho mình) thì ai sẽ bỏ tiền ra để sử dụng đây? Những người làm chủ Airbnb không nên sử dụng khách hạng hạng sang khi đi công tác ở thành phố khác, mà họ nên sử dụng phần mềm Airbnb để đặt phòng và trải nghiệm dịch vụ của họ như một người dùng cuối thật sự. Nếu họ cảm thấy ít nhất một trong những điều này như: phần mềm phức tạp (với người “mù công nghệ”), khó khăn trong việc tìm kiếm, đặt chỗ, di chuyển không thuận tiện, v.v… thì mình tin rằng những vấn đề này sẽ được khắc phục rất sớm.

Chính vì những điều trên, dogfooding được sử dụng như một quá trình UAT (User Acceptance Testing) trước khi quyết định phát hành chúng đến tay người dùng. Thời điểm mình làm QA trong nhóm Confluence, thì Confluence và các plugin do Atlassian phát triển, luôn được dogfooding tối thiểu một tuần trước khi được release trên môi trường có tên là PUG và EAC.

Giả sử, dev mới merge một nhánh code có lỗi nghiêm trọng ví dụ “gây mất hoặc lỗi dữ liệu cũ”, thì chính nội bộ Atlassian sẽ là người đầu tiên “lãnh đủ.” Nhánh Master (main) luôn được deploy tự động lên PUG, vì thế dữ liệu trên môi trường PUG thường là không quan trọng (1. PUG hay down do deployment nên gây gián đoạn quá trình sử dụng, 2. Nó hay gây mất dữ liệu do DB thường bị thay đổi như thêm table, cột,…). Cao hơn môi trường PUG là EAC, đây là Confluence chính thức của công ty, nên phiên bản lên đây phải đạt được chất lượng ở mức nào đó, ví dụ đã được chạy mọi regression testing từ Unit Testing đến E2E Testing, thậm chí SLAT (Suite Level Acceptance Testing, tương tự Contract Testing – Xem thêm Pactflow).

Mỗi chức năng mới (epic) đều được trải qua các hoạt động kiểm thử ở từng ticket (DoTing = Peer Testing), đến Blitz Test (giống khái niệm Alpha testing, kiểm thử chấp nhận ở phía nhà phát triển phần mềm nhưng không phải do chính nhóm phát triển đó thực hiện), sau đó được dogfooding ở PUG, lên EAC, rồi mới đến tay người dùng (Production) nên thường chất lượng của chúng luôn ở mức cao. Và nhóm phát triển luôn tự tin vào chất lượng của mỗi bản release. Dù luôn còn rất nhiều lỗi chưa fix, đa phần chúng là minor bug hoặc lỗi chỉ xảy ra với một vài user cụ thể nào đó mà người khác không gặp và nhóm phát triển không tái hiện được.

Một số bất lợi của eating your own dog food

Các hoạt động sử dụng chính các sản phẩm do công ty mình làm ra thì có những bất lợi gì?

Thứ nhất, như mình đề cập ở trên, thì nếu bạn quản lý, phân chia môi trường không hợp lý có thể dẫn đến những “tổn thất” lớn do những phiên bản chưa được kiểm thử kỹ gây ra, như mất dữ liệu hoặc gián đoạn quá trình sử dụng và làm việc.

Thứ hai, việc nghiêm cấm nhân viên sử dụng các sản phẩm của đối thủ có thể làm cho đội ngũ phát triển (PM, BA, Developer, và Tester) không nhận ra sản phẩm của chính mình ngày càng kém xa các sản phẩm, dịch vụ của đối thủ. Gây cản trở việc sáng tạo, đổi mới.

Thứ ba, đôi khi các nhóm phát triển ỷ lại “đội ngũ tester đông đảo” (chính là hàng trăm, hàng ngàn nhân viên của công ty) nên họ không kiểm thử kỹ. Nhất là những lỗi liên quan đến các sản phẩm, dịch vụ khác trong hệ sinh thái (đây là mức system integration testing được đề cập trong tài liệu ISTQB CTFL)

Cá nhân mình thấy có thể bất lợi cho nhân viên, khi họ nghỉ công ty này sang công ty khác. Các bộ công cụ sử dụng trong quá trình làm việc không được đa dạng hoặc trước đó mình sử dụng sản phẩm A (từ mẫu giáo đến giờ), nay vào công ty làm sản phẩm B, nên buộc phải sử dụng sản phẩm B. Thì phải từ bỏ phần mềm yêu thích của bản thân mà làm quen với sản phẩm mới. Cũng giống như bạn đã quen sử dụng iPhone hơn 10 năm, nay làm cho Samsung thì buộc phải xài điện thoại sử dụng hệ điều hành Android làm cho bạn rất khó chịu, và ngược lại.

Nếu bạn có câu chuyện gì muốn chia sẻ, chúng tôi luôn sẵn lòng lắng nghe và giúp mang chúng đến với Cộng đồng Tester Việt Nam chúng ta. Vui lòng liên hệ admin@testing.vn hoặc chat qua Skype này.