Bài gốc được đăng tại: https://www.kms-technology.com/blog/testing/q-a-with-james-bach.html
Lời người dịch:
James Bach ghé thăm KMS Technology Việt Nam vào mùa hè năm 2016. Vài tháng sau thì tôi mới gia nhập KMS (tiếc ơi là tiếc), và mãi đến năm 2018 thì tình cờ tôi mới được một tiền bối giới thiệu bài viết này và đề nghị tôi dịch thử. Quả thật là một thử thách cho một cô nàng chẳng biết gì nhiều về thế giới IT vào thời điểm đó, nhưng bài viết này cũng tạo phần nào cảm hứng để tôi tiếp tục dấn thân vào chuyện bếp núc của ngành làm phần mềm. Cảm ơn James Bach và chị Hòa Lê 😀
—
Tôi có vinh dự được nói chuyện cùng James Bach vào mùa hè năm 2016 khi ông đến thăm Việt Nam. Ông là cha đẻ của siêu nhận thức (metacognition) về kiểm thử phần mềm và cũng là người thầy đã khai sáng cho nhiều người về lĩnh vực này. Kiến thức của ông bao hàm nhiều lĩnh vực trong kiểm thử phần mềm, từ kiểm thử theo ngữ cảnh (context-driven testing), heuristics (tự nghiệm), sự nghiêp của tester, cho đến cuộc sống bí mật của tester. Nếu bạn có cơ hội được học hỏi từ ông, chắc hẳn bạn sẽ hoàn toàn đồng ý với tôi rằng ông thật tài năng.
- Ông làm thế nào để đảm bảo chất lượng của một dự án Agile đa vùng (co-located Agile project)?
James: Bạn sẽ cần giao tiếp có kế hoạch trước rất nhiều, vì giao tiếp không tự nhiên xảy ra khi người ta ở xa nhau. Tôi đề nghị nên điện đàm (conference call) hàng ngày. Những dự án được phân bổ (distributed projects) cần có bộ phận lãnh đạo mạnh mẽ để đưa mọi người lại gần nhau. Tôi cũng đề nghị những người then chốt nên đến thăm nhau định kì, thay vì chỉ dựa dẫm vào giao tiếp qua phương tiện điện tử.
(“Dự án Agile đa vùng (co-located Agile) có nghĩa là các thành viên nhóm Agile làm việc ở những địa điểm khác nhau hoặc nhiều nhóm Agile đang làm những phần khác nhau của sản phẩm từ những địa điểm khác nhau”).
Chúng ta đều biết trong môi trường Agile, tốc độ cao và chất lượng cao là ưu tiên hàng đầu. Người ta có khuynh hướng làm không nghỉ, nhưng vì chất được được đo dựa trên những đặc điểm của dự án và nhóm, nên yếu tố con người là nhân tố then chốt để đảm bảo chất lượng dự án. Điều này nghĩa là giao tiếp hiệu quả và tư duy sắc bén có thể ảnh hưởng lên sự thành công của dự án. Ý kiến của James đem đến một số ý tưởng về việc giao tiếp được củng cố trong các dự án.
Thứ nhất, giao tiếp hiệu quả được quyết định dựa trên ngôn ngữ, sản phẩm, công cụ/công nghệ, và kiến thức về quy trình (process knowledge) của nhóm. Để giao tiếp một cách hiệu quả vượt qua khoảng cách địa lý và múi giờ, các nhóm được phân bổ cần nói cùng một “ngôn ngữ”. Ngôn ngữ ở đây không chỉ nói đến thuật ngữ về mặt ngôn ngữ (speaking terms) như tiếng Anh, Đức hay Pháp, mà còn là thuật ngữ về sản phẩm và những tính năng hay quy trình của công cụ/công nghệ, mà mỗi nhóm sẽ cần ở trình độ hiểu biết tương đương nhau để nói và hiểu lẫn nhau.
Để đồng bộ, cần làm thêm một số bước. Các nhóm cần hỏi những câu hỏi súc tích và hợp lý, để làm rõ các yêu cầu hay đề nghị và để xem lại các kết quả trước khi phát hành (release). Sự đồng đều về kiến thức giữa các nhóm được phân bổ nên tạo điều kiện cho họ ra quyết định ở các vấn đề nội bộ, thực hiện “nguyên tắc tự quản lý”. Một nhóm không nên bảo nhóm khác cái gì [cần] và/hoặc làm thế nào để hoàn thành một task.
Thứ hai, áp dụng những công cụ và cách thức giao tiếp thích hợp cũng đóng một vai trò quan trọng đối với việc giao tiếp của nhóm. Có khá nhiều lựa chọn từ giao tiếp trực tiếp (nói chuyện mặt đối mặt hay Video call) cho đến những dạng gián tiếp (Email, Forum, hay Text chat). Có nhiều công cụ phổ biến và hữu dụng để cân nhắc, bao gồm: Skype, Slack, Confluence, GoToMeeting, hay Google Drive, những thứ hỗ trợ giao tiếp và cộng tác một cách dễ dàng giữa các nhóm onshore và offshore. Những cách thức và ứng dụng này có thể giúp thu hẹp khoảng cách múi giờ và địa lý.
Thêm vào đó, để giao tiếp được hiệu quả hơn, phạm vi công việc cần được sắp xếp một cách hợp lý để hoàn toàn hỗ trợ khách hàng một cách thích hợp và đem lại sự kết nối suôn sẻ. Bạn nên lên lịch cho các chuyến thăm onshore/offshore đều đặn để thiết lập mối quan hệ với các thành viên và phản hồi ngay với các thay đổi trong việc phát hành, các cột mốc quan trọng (milestone), hay công nghệ. - Ông định nghĩa code kiểm thử được là như thế nào? Các tiêu chí của ông là gì?
James: Mọi code đều kiểm thử được. Một số code dễ kiểm thử hơn các code khác. Tính có thể kiểm thử trong code chỉ có nghĩa là nó dễ kiểm thử như thế nào. Code dễ kiểm thử hơn khi nó có thể quan sát (observable) được và có để kiểm soát được. Hãy hỏi về logging ở mức độ chức năng (functional-level logging) và giao diện scriptable (scriptable interface). Đồng thời, code dễ kiểm thử hơn khi chúng đơn giản và có thể phân tích được. Tính có thể phân tích được (decomposability) là khả năng có thể phân tích các thành phần và kiểm thử biệt lập một cách tương đối.
Cụ thể hơn, có nhiều cách đơn giản để định nghĩa code có thể kiểm thử, chẳng hạn: logic của code (code logic), quy ước đặt tên code (code naming conventions) và cấu trúc/kiến trúc của dự án (project structure/architecture). Code kiểm thử được luôn bao gồm khả năng mở rộng, tính dễ bảo trì, tính có thể sử dụng lại, và tính có thể nâng cấp (ability of extension, easy maintenance, re-usability, and upgradability). Burak Guzel của EnvatoTuts đã liệt kê 15 cách tốt nhất để viết code có thể đọc được. - Một tester cần loại kĩ năng nào để có thể tiến vào thế giới DEVOPS?
James: Tôi không biết nhiều đến thế về thế giới DEVOPS. Nhưng thế giới đó không chào đón tester. Nó chào đón lập trình viên. Do đó kĩ năng được yêu cầu đầu tiên là lập trình. Sau đó bạn cần tìm kiếm những công cụ để hỗ trợ công việc kiểm thử của mình.
Có một số chiến thuật mà tester cần nắm bắt để tiến vào thế giới DEVOPS:
· Live site testing: Testers cần phải kiểm thử sản phẩm trong quá trình sản xuất, ngay khi nó được phát hành (release).
· Thu thập và phân tích phản hồi từ người dùng trong lĩnh vực đó. Phản ứng nhanh với bất kì vấn đề phát sinh nào của người dùng.
· Ủng hộ tính có thể kiểm thử. Việc xây dựng sản phẩm với tư duy kiểm thử trong đầu là thứ có tính quyết định.
James đã đưa ra những luận điểm vững chắc. Tester cần nâng cao khả năng hiểu coding, build-production, công cụ, và hệ điều hành như Linux và Windows. - Ông làm thế nào để quyết định loại thông tin nào nên đưa vào báo cáo cuối cho khách hàng? Loại thông tin nào thì hữu ích và loại nào thì không?
James: Không có báo cáo nào là hoàn hảo. Chỉ có báo cáo đem đến giá trị cho khách hàng.
Dưới đây là một số lời khuyên của tôi:
· Xây dựng lòng tin (bằng cách trở nên đáng tin).
· Biết ngữ cảnh của việc kiểm thử của mình (test framing).
· Không bao giờ dùng một con số không nằm trong ngữ cảnh (ví dụ: no test case counts).
· Nhấn mạnh những hoạt động test về mặt tổng thể (đặt test vào đúng ngữ cảnh).
· Nhấn mạnh rủi ro của sản phẩm (đặt bug vào đúng ngữ cảnh).
Chúng ta có thể xây dựng báo cáo cuối với 3 cấp độ:
- Cấp độ 1: Thực trạng và sự thật (facts and truth) về bug và những điều quan sát được (observations)
- Cấp độ 2: Làm thế nào mà bạn nắm được những thực trạng đó? Làm thế nào để kiểm thử những thực trạng đó
- Cấp độ 3: Làm thế nào mà bạn biết việc kiểm thử có tốt không? Tại sao nó đủ tốt, tại sao không?
- Ông ước lượng công sức bỏ ra cho việc kiểm thử trong một dự án như thế nào?
James: Không có một bảng tính thần kì nào có thể cho bạn biết việc kiểm thử sẽ mất bao lâu, nhưng ước lượng tốt bắt đầu từ sự hình dung (visualization). Bạn có thể hình dung ra quy trình kiểm thử trong đầu không? Nhiều tester gặp vấn đề khi làm chuyện đó. Nhưng nếu họ không rõ ràng về cái mà việc kiểm thử sẽ trông ra sao hay cảm thấy như thế nào, họ sẽ không nảy ra được ý nào về việc nó sẽ kéo dài bao lâu.
Đi kèm với điều này là một danh sách những câu hỏi khác cùng câu trả lời, có thể giúp ước lượng công sức dành cho việc kiểm thử trong một dự án:
· Thật sự cần bao nhiêu thời gian để kiểm thử?
· Sẽ tốn bao nhiêu thời gian để hoàn tất việc kiểm thử?
· Lượng thời gian tối thiểu có thể dùng để kiểm thử là bao nhiêu?
· Cần kiểm thử bao nhiêu để đảm bảo giải pháp đạt chất lượng cao?
· Cần bao nhiêu test case?
· Cần bao nhiêu tester?
· Yêu cầu những kĩ năng test nào?
· Việc kiểm thử sẽ tốn bao nhiêu tiền?
· Ta có cần phải kiểm thử tất cả không?
Cảm ơn James đã dành thời gian trả lời những câu hỏi của chúng tôi. Kiến thức và kinh nghiệm sâu sắc của ông đã mở rộng kiến thức về kiểm thử của chúng tôi và quả là một cơ hội tuyệt vời khi được học hỏi từ ông.
Cảm ơn James rất nhiều.
HOA LE
Người dịch: Trà Giang, 20180517