Sản Phẩm “Sống” Nhờ Có QC Giỏi

**thuyanh-ITviec** · 07-03-2016 12:00

“Sản phẩm mình làm ra mà không ai dùng thì sản phẩm đó chết. Mình làm QC cho sản phẩm chết thì chứng tỏ mình cũng thất bại.”

Đọc bài phỏng vấn của ITviec với chị Phan Thị Ngọc Phương – QC Lead của ASWIG Solutions – để tìm hiểu về:

- QC là gì và những kỹ năng, tố chất nào là cần thiết để trở thành 1 QC giỏi.
- Thất bại chị từng trải qua và bài học rút ra.
- Lời khuyên chị dành cho các bạn muốn trở thành QC giỏi.

Tiểu sử: Sau khi tốt nghiệp khoa CNTT chuyên ngành phần mềm ĐH Văn Lang năm 2006, chị Phương làm Developer trong một tháng rồi chuyển hẳn sang làm Testing. Đến nay chị đã có hơn 9 năm kinh nghiệm làm Testing. Hiện tại chị Phương đang là QC Lead của ASWIG Solutions.

Chị có thể cho biết QC là gì, và trách nhiệm – nghĩa vụ của người QC là gì?

“Dân gian” hay gọi QC là Tester, nhưng QC là viết tắt cho Quality Control, tức là đảm bảo chất lượng phần mềm. Đây là vị trí làm công việc:

1) Đảm bảo khi team Development làm xong một sản phẩm, thì những yêu cầu đặc tả của khách hàng đã được đáp ứng trong sản phẩm đó.

2) Còn nhiều thứ không được mô tả trong bảng mô tả của khách hàng nhưng làm một QC thì mình cần có riêng một số tiêu chí về chất lượng mà mình cần phải kiểm tra trên mọi sản phẩm. Ví dụ như theo chị, một sản phẩm tốt, ngoài việc đảm bảo yêu cầu khách hàng, thì chị còn cân nhắc haiyếu tố: a) người dùng cuối cùng có thích sử dụng sản phẩm không, b) họ có cảm thấy nó dễ sử dụng không.

Chị ví dụ một website mua bán sản phẩm mà chị từng test thì chu trình mua hàng mà khách hàng đặt ra cho chị test là: người dùng cuối (end-user) đăng nhập, xem và duyệt sản phẩm muốn mua, bỏ vào giỏ hàng, thanh toán. Đó là yêu cầu của khách hàng, là chu trình “lý tưởng” mà họ nghĩ, đồng thời họ chỉ đưa yêu cầu bắt chị test các chức năng như đăng nhập, chọn hàng, bỏ vào giỏ hàng, thanh toán…

Sau khi chị test các chức năng và thấy nó hoạt động tốt rồi thì chị đứng trên cương vị người dùng, và chị thấy là không ai vừa vào một website mua sắm là tạo tài khoản, đăng nhập ngay, mà họ sẽ xem sản phẩm trước, thích rồi mới tạo tài khoản và mua hàng. Chị đã nêu vấn đề với khách hàng, họ tiếp thu và đặt ra nhiều quy trình mua hàng khác nhau cho website đó, để đáp ứng được sở thích và hành vi mua sắm của nhiều đối tượng.

Chị tin rằng người QC giỏi cần đứng trên cương vị người dùng, sử dụng sản phẩm theo sở thích của họ để xem phần mềm có đáp ứng được hay không, từ đó đề xuất cách hoàn thiện sản phẩm. Nếu một sản phẩm ra đời mà không ai sử dụng là một sản phẩm thất bại. Mình làm QC cho sản phẩm đó, mình cũng là một QC thất bại.

QA là gì và QC khác QA ở điểm nào vậy chị?

QA là Quality Assurance. Khi em làm cho những công ty phần mềm lớn như CSC, có chứng chỉ tiêu chuẩn chất lượng CMMI, tức là công ty đó có quy trình làm phần mềm rõ ràng. Quy trình làm phần mềm ở đây ví dụ như là đến giai đoạn nào, em phải có những loại document nào. Ngoài ra còn nhiều tiêu chí khác khi làm phần mềm mà em phải thực hiện theo thứ tự rõ ràng thì phần mềm mới đạt chất lượng.

Giả sử một công ty có chứng chỉ CMMI 5 thì người làm QA phải áp dụng quy trình làm phần mềm của chứng chỉ đó vào toàn bộ quá trình làm phần mềm của công ty, và đảm bảo mọi dự án đều phải thỏa mãn quy trình đó.

Trong một công ty thì thông thường chỉ có 1-3 QA, nhưng lại có vô số QC để kiểm tra chất lượng phần mềm. QA là người làm về quy trình, còn QC là người làm việc với team Development để cho ra đời một sản phẩm tốt.

Vì sao chị lại chọn nghề QC?

Thông qua tự tìm hiểu, chị thấy tiềm năng phát triển của nghề QC rất lớn.

Ngoài ra, mới làm Developer có một tháng, nhưng chị nhìn thấy công việc của Developer rất stress. Nếu em không thích, không ôm cái máy tính cả ngày, không research liên tục thì em không phát triển được.

Trên hết, chị thấy tính cách của mình hợp với nghề QC hơn, vì chị đặt nhiều quan tâm cho các góc cạnh khác nhau của chất lượng sản phẩm. Ví dụ, khi đi mua hàng, chị suy xét nhiều thứ, ví dụ sản phẩm có bắt mắt không, giá tiền hợp lý chưa, nó có đáp ứng được nhu cầu của mình không, chức năng của nó có đúng là cái mình cần không, cách sử dụng có dễ không, nó có bền không… Chị tin là áp dụng những suy xét này vào nghề QC thì sản phẩm khi ra đời sẽ được nhiều người dùng đón nhận.

Điểm khác biệt lớn nhất giữa Developer và QC là gì vậy chị?

Điểm khách biệt nằm ở cách nghĩ. Developer quan tâm đến code và xây dựng sản phẩm, còn QC quan tâm đến chất lượng sản phẩm và tìm lỗi để bắt Developer sửa lỗi.

Khi làm việc, Developer thường hướng mình code theo cách ứng dụng vận hành đúng, nhưng anh ta không kiểm tra trường hợp người dùng làm sai thì ứng dụng phản ứng ra sao.

Làm QC, trường hợp đầu tiên em phải kiểm tra gọi là “happy case,” tức là kiểm tra khi ứng dụng vận hành đúng thì phần mềm có hoạt động đúng yêu cầu khách hàng không. Nếu đúng rồi thì mình phải tính tới trường hợp khi thao tác sai thì ứng dụng phản ứng ra sao.

Chị ví dụ, em lên một website tạo tài khoản, khi em điền đúng loại thông tin, tạo tài khoản thành công, đó là “happy case.” QC cần phải nghĩ đến trường hợp em điền sai loại thông tin thì trang web phản ứng thế nào. Có một lần chị test thì thấy website báo lỗi “Error” rồi xoá hết dữ liệu chị điền, mà chị không được báo là điền sai thông tin ở phần nào. Chị lại điền lại, thay thế giá trị ở một vài chỗ, website vẫn báo lỗi rồi xoá hết dữ liệu mà không hiện thông báo chính xác là chị sai ở phần nào.

Mỗi lần website báo lỗi rồi xoá dữ liệu mà không chỉ rõ chỗ sai như vậy sẽ làm người dùng bực mình. Sau vài lần thử lại, họ có thể bỏ đi luôn. Vì vậy, người QC cần test ứng dụng bằng cách thao tác sai để xem thông báo lỗi hướng dẫn người dùng thao tác lại như thế nào, có báo chính xác lỗi mà người dùng mắc phải, để người dùng thao tác đúng lại không, thông điệp báo lỗi có thân thiện với người dùng không.

Làm phần mềm rất khó và áp lực nhưng test phần mềm còn quan trọng hơn. Nếu QC không chỉ được những điểm sai và thuyết phục Developer, thì người dùng cuối không muốn sử dụng, dẫn đến phần mềm của mình cũng chết.

Vậy theo chị, nghề QC có điểm trừ nào không?

Thứ nhất, chị thấy ở những công ty nhỏ, QC hay bị xem thường và bị sai vặt, bắt viết document, chờ ứng dụng ra rồi test rập khuôn theo yêu cầu khách hàng.

Thứ hai, chị thấy QC cũng là một nghề cần được đào tạo bài bản nhưng lại chưa được coi trọng. Ở các trường đại học hiện nay dạy nhiều ngôn ngữ lập trình, mà không có trường lớp nào đào tạo chính quy về testing hay quality control. Theo chị biết thì chỉ có RMIT và đại học Khoa Học Tự Nhiên là có lớp dạy ngoại khóa về testing. Toàn bộ kiến thức testing chị có được do tự nghiên cứu và học hỏi trong quá trình làm việc.

Cuối cùng, khái niệm về “quality control” hiện tại còn khá mơ hồ. Nhiều bạn trẻ chỉ làm công việc như một Tester thuần tuý, dựa trên yêu cầu đặc tả của khách hàng, xem phần mềm hoạt động có gì khác thì họ bắt bug. Họ không nghĩ đến trường hợp người viết ra yêu cầu đặc tả này vẫn có sai sót. Lúc đó người QC không chỉ làm công việc bắt bug nữa mà là nêu lên vấn đề về phần mềm cho người viết yêu cầu đặc tả để họ điều chỉnh, rồi chuyển sang team Development làm lại.

Có điều gì mà mọi người thường hiểu lầm về nghề QC không chị?

Nhiều người hay hiểu nhầm rằng làm QC rất dễ và QC là những người “failed Developer,” tức là code không nổi nữa mới chuyển qua làm test. Nhưng chị nghĩ không phải vậy.

Công việc của người làm “quality control” rất quan trọng. Như nãy giờ chị cũng nhắc đi nhắc lại là nếu sản phẩm mình làm ra mà không ai dùng thì sản phẩm đó chết. Mình làm QC cho sản phẩm đó, mà nó chết thì chứng tỏ mình cũng thất bại.

QC là nghề đòi hỏi những kỹ năng, tố chất mà không phải Developer nào cũng đáp ứng được.

Vậy những kỹ năng và tố chất nào là quan trọng nhất với một người QC vậy chị?

Thứ nhất là kỹ tính. Làm QC nghĩa là mình đang kiểm tra lại phần việc của mọi người. Mình cần kiếm hết tất cả bug để Developer sửa. Nếu có bug nào mà người dùng cuối phát hiện ra sau khi sản phẩm đã lên production thì team Test bị la, vì vậy cần hết sức kỹ càng trong việc phát hiện bug.

Thứ hai là kiên nhẫn, nhất là trong giai đoạn làm manual test. Quá trình develop sản phẩm, ban đầu có thể rất khó, nhưng lúc sau, giống như đã có sẵn nền tảng, Developer implement ít nhưng QC phải test lại rất nhiều. Với lại mình phải làm regression test, nên phải test những chu trình lặp lại, thì thỉnh thoảng nó hơi nhàm chán nên đòi hỏi người QC phải kiên nhẫn và kỹ tính thì mới tìm ra bug được.

Thứ ba là kỹ năng phân tích vấn đề. Chị ví dụ như khi tìm ra một bug, không phải mình chỉ ghi hiện tượng bug là gì mà mình còn phải phân tích con bug đó. Cụ thể hơn là, có nhiều cách để lặp lại một bug, QC cần tìm cách lặp lại bug ngắn nhất để Developer có thể dễ dàng thao tác tạo lại bug đó.

Thứ tư là anh văn phải tốt, vì nếu anh văn của mình không tốt, mình hiểu sai vấn đề thì sẽ test sai. Team development trước khi làm sản phẩm thì đều có meeting để nắm yêu cầu của khách hàng, nhưng ở nhiều công ty, QC không được tham gia vào những buổi meeting đó. QC thường nhận được sản phẩm, kèm với yêu cầu khách hàng cùng lúc. QC có thời gian rất ngắn để hiểu requirement và test sản phẩm. Nếu tiếng anh không vững dẫn đến hiểu sai, rồi test sai, không tìm ra bug, sản phẩm không được người dùng cuối chấp nhận thì nó chết, QC cũng thất bại.

Cuối cùng là phải giao tiếp tốt để Developer không hiểu lầm rằng mình đang cố tìm lỗi và tố giác cái họ làm sai. QC cần làm cho Developer hiểu rằng lỗi họ tìm ra cũng nhằm mục đích hoàn thiệt sản phẩm, làm khách hàng hài lòng, và làm người dùng yêu thích sản phẩm. Vì vậy khi giao tiếp với Developer, chị luôn giữ thái độ hoà nhã, tích cực, cẩn thận phân tích vấn đề.

Chị từng mắc phải sai lầm nào, chị đã vượt qua như thế nào và chị học được gì từ nó?

Lúc chưa có nhiều kinh nghiệm, có một lần, sau khi meeting với khách hàng thì chị hiểu sai yêu cầu của họ. Sau đó chị hướng dẫn lại cho team sai. Khi phát hiện ra, chị xin lỗi khách hàng và cùng team làm lại từ đầu. Mọi người phải làm nhiều việc hơn, vất vả hơn rất nhiều.

Từ đó, chị rút ra kinh nghiệm là sau khi meeting với khách hàng xong thì phải tóm tắt lại những cái cần làm, hoặc có vấn đề chưa hiểu rõ thì phải xác nhận lại rồi gửi email xác nhận cho khách hàng, sau đó mới truyền đạt lại cho team.

Ngoài ra, dù có nghĩ rằng mình hiểu đúng yêu cầu của khách hàng, thì mình cũng phải lặp lại yêu cầu của họ theo cách diễn đạt của mình. Bởi vì tiếng anh không phải là tiếng mẹ đẻ của mình, nên để đảm bảo mình hiểu đúng vấn đề, chị không lặp lại y chang lời của khách hàng, mà chị hiểu rồi diễn đạt lại theo văn phong của mình. Đây cũng là cách tốt nhất để khách hàng xác nhận là QC hiểu đúng yêu cầu của họ hay không.

Nếu một Developer muốn chuyển sang làm QC thì bạn đó cần phải chuẩn bị những kiến thức, và rèn luyện kỹ năng gì?

Thông thường có một số bạn làm Developer 2-3 năm rồi chuyển sang làm QC. Giai đoạn đầu rất khó khăn để bạn đó tìm bug, vì tư duy của Developer là làm đúng. Lúc đó Developer cần học cách nhìn sản phẩm dưới góc nhìn của người dùng cuối, tức là thử sử dụng sản phẩm theo nhiều cách khác nhau.

Ngoài ra, chị nghĩ các bạn nên tham gia các khoá training dành cho QC ở các công ty, hoặc là học các khoá học ở RMIT hay đại học Khoa Học Tự Nhiên. Thêm vào đó, chị nghĩ các bạn nên tự tìm kiếm tài liệu và học online. Chị thường xuyên tham khảo các nguồn sau:

Software Testing Help – Đây là website chuyên về Testing.

Guru 99 – Trang này có nhiều kiến thức khác nhau, có cả phần căn bản về Testing cho các bạn mới bắt đầu.

Tutorials Point – Trang này cũng có nhiều kiến thức Testing mà chị hay tham khảo.

Chị thấy các bạn Developer có logic rất tốt, vì vậy các bạn chỉ mất khoảng nửa năm đến một năm tương đối khó khăn ban đầu thôi, còn sau đó các bạn đều làm rất tốt.

Ngoài ra, chị thấy có tài liệu ISTQB, là tài liệu chuyên dành cho Testing rất hay, nhưng chỉ khi có kinh nghiệm rồi thì em đọc mới thấm và dễ hiểu hơn, vì vậy chị đề xuất bộ sách này cho các bạn QC đã có kinh nghiệm. Ngoài ra, một khi đã đọc, các bạn nên đọc lại nhiều lần ở nhiều thời điểm khác nhau. Bởi vì càng có nhiều kinh nghiệm, bạn sẽ càng hiểu vấn đề sâu hơn, khi đó kiến thức trong sách sẽ in sâu hơn vào tiềm thức của bạn.

Chị có lời khuyên nào dành cho các bạn QC trẻ để cải thiện bản thân mình ngay hôm nay?

Chị chỉ khuyên các bạn là ngay cả khi chỉ làm một thành viên trong team thì cũng nên “take ownership,” tức là làm việc với tinh thần như một người Lead, thì lúc đó mình sẽ làm được nhiều hơn điều mà người Lead mong đợi. Mình sẽ quan tâm đến nhiều loại quality khác của dự án, dẫn đến thể hiện nhiều hơn khả năng của mình.

Chị ví dụ, các thành viên trong team chị, khi làm xong task A, các bạn đều sang hỏi chị để làm thêm task khác. Ngoài ra, có bạn còn dành thời gian, nghiên cứu tổng quan dự án để phát hiện những vấn đề quan trọng và nêu lên với chị, để chị làm việc lại với khách hàng.

Trong một team, nếu ai cũng “take ownership,” thấy vấn đề thì nêu lên thì sản phẩm cuối cùng của dự án sẽ tốt. Bên cạnh đó, sau này, khi dự án lớn lên, tăng thêm thành viên, thì chính các bạn đó được nắm chính các component, và đóng vai trò của một QC Lead trong component đó.

Bạn có gặp khó khăn trở ngại gì trong sự nghiệp QC của mình? Hãy cùng chia sẻ và thảo luận với các QC khác tại phần bình luận cuối bài.

Xem thêm một số bài chia sẻ hay tại Blog ITviec.