3 lời khuyên để trở thành Automation QA

“Mục đích của QA là tìm bug, nhưng vẫn hỗ trợ cho mục đích cuối cùng là làm sản phẩm tốt hơn, chứ không phải là chỉ trích, đánh giá developer.”

Đọc bài phỏng vấn của ITviec với anh Trương Minh Sử Nhiên – Senior Automation QA của KMS Technology – để tìm hiểu:

• Sai lầm mắc phải trong sự nghiệp Automation QA và cách anh vượt qua
• 6 kỹ năng cần thiết cho mọi QA + cách rèn luyện
• 3 lời khuyên thực tế cho các QA trẻ cải thiện ngay hôm nay

Xem việc làm Automation QA tại ITviec

Tiểu sử: Sau khi tốt nghiệp Đại Học Cần Thơ năm 2003 chuyên ngành CNTT, anh Nhiên lên Tp. HCM làm khoảng 1 năm cho Đại Học Bách Khoa ở vị trí Software Developer.

Trong 2 năm tiếp theo, anh làm Software QA Leader tại Global CyberSoft.

5 năm sau đó, anh công tác ở Ndex Technologies lần lượt ở vị trí QC Leader và QC Manager.

Anh làm Software Department Manager trong 1 năm tiếp theo. 1 năm sau đó anh làm Automation QA Leader tại Sunrise Software Solutions Corporation.

Trong 1 năm tiếp theo, anh tiếp tục công tác tại vị trí Automation QA Leader tại COSATECH.

Bắt đầu từ tháng 5 năm 2015, anh bắt đầu làm việc tại KMS Technology ở vị trí Senior Automation QA.

Sự khác nhau giữa manual test và automated test là gì ạ?

Lúc trước, hình thức test phần mềm phổ biến là manual test. Ví dụ để test form log in, một manual QA sẽ tự nhập tay username, password, click “log in,” xem kết quả đăng nhập thành công hay không.

Một automated QA sẽ viết script để chạy tự động tất cả các bước bao gồm nhập thông tin, click, kiểm tra kết quả, so sánh kết quả thực tế với kết quả giả định.

Nhiều loại test có thể làm auto, ví dụ như functional testing, performance/load testing, unit testing.

Điểm cộng và điểm trừ của automated test so với manual test là gì?

Điểm cộng của automated test là:

1) Đáng tin cậy. Test chạy chính xác theo quy trình đã định sẵn, vì vậy tránh được nhiều lỗi do con người tạo ra, ví dụ như nhập sai dữ liệu.

2) Mình có thể test cách phần mềm xử lý (tính năng/hiệu năng) khi gặp tình huống chạy lặp đi lặp lại nhiều lần (cùng lúc) trên cùng script test. Đây còn gọi là performance/load testing.

3) Mình có thể lập trình nhiều test tinh vi hơn để thu về những thông tin ẩn từ ứng dụng. Ở điểm này thì manual test không thể làm được.

4) Test mang tính toàn diện cao. Mình có thể tạo ra một bộ test để bao quát hết tất cả feature trong ứng dụng.

5) Mình có thể tái sử dụng test trên nhiều phiên bản khác nhau của ứng dụng, ngay cả khi có sự thay đổi giao diện.

Ví dụ như khi sản xuất phần mềm, chúng ta cần lần lượt test sản phẩm ở nhiều môi trường: 1) môi trường test, 2) môi trường beta, 3) môi trường production.

Nếu chạy manual test thì một test case mất một tiếng, ba môi trường tốn ba tiếng. Mà trong suốt quá trình phát triển sản phẩm, chúng ta phải lặp lại quá trình test vô số lần, dẫn đến mất thời gian nếu làm manual test. Thay vào đó, chỉ cần viết một script test thì mỗi lần deploy lên môi trường mới, mình chỉ cần thay đổi URL là test tự chạy được.

6) Chất lượng và hiệu suất phần mềm tốt hơn bởi vì mình có thể chạy nhiều test trong thời gian ngắn hơn với ít resource nhất.

7) Automated tool giúp chạy test nhanh hơn test tay.

8) Có tính kinh  tế cao vì có thể giảm thiểu nguồn nhân lực làm kiểm tra hồi quy.

Điểm trừ của automated test là:

1) Nhiều tool có chi phí rất cao, ví dụ như commercial tool, như là HP Quick Test Pro.

2) Thường thì lương trả cho automation QA nhiều hơn manual QA, vì công việc đòi hỏi họ có kỹ năng cao hơn, ví dụ như phải biết code, phải viết được script.

3) Chi phí để phát triển và bảo trì test script cao. Ví dụ một test case nếu test manual thì mất 1 tiếng. Nhưng nếu đổi sang chạy automated test, cần chuẩn bị test script (mà trong trường hợp khó) thì phải mất 6-7 tiếng để viết test script. Người viết test script cần có kỹ năng lập trình và tool để chạy test. Vì vậy chi phí cho automated test cao hơn manual test.

4) Đòi hỏi QA phải có kinh nghiệm technical và kỹ năng lập trình.

5) Đòi hỏi thời gian chuẩn bị dài hơn để thiết kế, cài đặt kỹ càng trước khi cần đưa dự án đi test.

6) Có những dự án không nên chạy automated test, nhưng nhiều QA vẫn hiểu nhầm và chạy automated test, dẫn đến mất thời gian, resource, công sức. Ví dụ như khi test một chức năng quá phức tạp của một ứng dụng hoặc một GUI object thì phải chạy manual test.

Anh Nhiên cùng team meeting một dự án mới

Công việc, trách nhiệm thường ngày của anh là gì?

Với vị trí Automated QA Architect, anh xác định các feature của automation testing framework, hỗ trợ phát triển framework để làm automated test.

Điểm cộng và điểm trừ của công việc automation QA là gì ạ?

Điểm cộng của nghề này là nó giúp anh nâng cao kỹ năng phân tích vấn đề, và kỹ năng quản lý sự cố. Điểm trừ là lúc đầu, anh hay vướng vào tranh cãi với team development về các bug mà anh tìm ra.

Kỹ năng phân tích vấn đề và kỹ năng quản lý sự cố được nâng cao là do ví dụ như khi làm một test plan để test log-in form, anh phải xác định tất cả các trường hợp có thể xảy ra, như là 1) nếu nhập sai username hoặc password thì thế nào, 2) nếu sai một trong hai trường đó thì sao, 3) nếu nhập ký tự đặc biệt thì sao…

Vì sao anh lại chọn trở thành automation QA thay vì manual QA hay Developer?

Từ năm 2004, anh được tiếp cận với automated test, sử dụng công cụ IBM Rational Robot. Anh thấy thích và anh nhìn nhận automated test là định hướng tốt, có tiềm năng phát triển cho nghề QA.

Vì vậy, anh tự nghiên cứu và xây dựng nhều automation testing framework dựa trên Rational Robot, HP QTP/UFT, Selenium WebDriver, Test complete, cũng như bắt đầu sự nghiệp với vị trí automated QA.

Anh nhận định xu hướng testing trong tương lai như thế nào?

Vài năm trở lại đây, vị trí automated QA đang là vị trí hot của tuyển dụng, từ những vị trí chuyên sâu về phát triển tool/framework/library đến những bạn có thể viết được script dựa trên một công cụ automated test nào đó.

Vì vậy, anh nghĩ automated test đang và sẽ là xu thế chung của ngành QA.

Sai lầm lớn nhất anh từng mắc phải là gì? Anh vượt qua thế nào và anh học được gì từ nó?

Hai năm trước, khi đàm phán xây dựng một automation testing framework cho khách hàng, anh cố đưa ra estimation rất thấp để ghi điểm cho công ty, rồi làm việc một mình để hoàn thành dự án đó, vì anh nghĩ những thành viên khác trong nhóm không chuyên về code nên nếu họ tham gia sẽ kéo tiến độ công việc xuống. Anh thường xuyên ngủ lại công ty để cố hoàn thành tiến độ đúng thỏa thuận.

Cuối cùng, dự án hoàn thành, được đánh giá cao từ phía khách hàng và công ty. Tuy nhiên từ đó, anh bị stress trầm trọng và gần như muốn xin nghỉ việc. Anh đi gặp Manager của mình và chia sẻ thì nhận được lời khuyên:

Từ đó, mỗi lần đàm phán với khách hàng, anh đều dựa trên nền tảng khả năng chung của team.

Ngoài ra, anh cũng có những buổi chia sẻ kinh nghiệm để khuyến khích anh em nghiên cứu nhiều hơn về những công nghệ, kỹ năng cần thiết của một người Automated QA.

Điều này giúp anh em cảm thấy được tin tưởng giao việc, được khuyến khích cùng nhau phát triển. Anh cũng không cảm thấy áp lực nặng nề nữa.

Một thử thách mà mọi automation QA nào khi vào nghề cũng gặp phải là gì?

Thử thách chính là giao tiếp với developer. Khi mới vào nghề, tìm được bug, anh chỉ nói với developer là ‘tôi thấy có lỗi ở chỗ này, kia, nọ, anh sửa đi’. Lúc đó anh thường xuyên dính vào tranh cãi với developer vì 1) anh không chỉ ra chi tiết lỗi đó là gì, bị lỗi ngay bước nào, 2) thái độ khi làm việc với developer của anh không mang tính tích cực xây dựng sản phẩm, mà lại hơi có phần chỉ trích và đánh giá developer.

Sau này, khi được cấp trên hướng dẫn, mỗi khi tìm thấy bug, anh đều giao tiếp với developer theo trình tự thế này:

1) Tóm lược vấn đề

2) Chỉ ra các bước cụ thể trong quy trình test của mình

3) Giải thích cụ thể là nó xảy ra lỗi gì

4) Nêu kết quả mong đợi

5) Cho developer thấy hình ảnh screenshot bug mà mình tìm được

Anh nhận ra rằng mối quan hệ giữa QA và developer là quan hệ hỗ trợ lẫn nhau. Mục đích của QA là tìm bug, nhưng vẫn hỗ trợ cho mục đích cuối cùng là làm sản phẩm tốt hơn, chứ không phải là chỉ trích, đánh giá developer.

Những kỹ năng nào là cần thiết dành cho một automation QA?

1) Hiểu nguyên lý nhận dạng test objects. Nếu làm web automated test cần nắm rõ HTML và XPath. Bạn có thể học hai mảng này ở W3School.

2) Hiểu nguyên lý lập trình, và thành thạo ít nhất một ngôn ngữ lập trình. Web Automation engine được dùng phổ biến ở thị trường hiện nay là Selenium WebDriver, có kết hợp cho các ngôn ngữ Java, C#, Ruby, Python… Ngoài ra các bạn có thể tham khảo thêm các ngôn ngữ scripting phổ biến như VBScript, JavaScript hoặc Groovy nếu cần.

3) Không bỏ qua SQL và XML. Hai mảng này bạn có thể học tại TutorialsPoint và W3School. Đa số các dự án lập trình đều cần có cơ sở dữ liệu. XML được hiểu như một phần của portal database và SML cũng được sử dụng khá nhiều hiện nay.

4) Những bạn muốn đi sâu vào thiết kế tốt framework/common library thì nên tìm hiểu sâu về software design pattern.

5) Làm automated QA là liên quan đến coding nên các bạn cần quan tâm đến những kỹ năng của code như debug, source version control, coding convention, unit testing… Tìm kiếm các từ khoá này trên Google là thấy ngay tài liệu.

6) Nên ham học hỏi những cái mới trong chuyên môn. Ví dụ, xu thế automated test và software development hiện tại là kỹ thuật tích hợp (integration). Đó là một chuỗi khép kín, tương tác giữa development, deploy và test. Anh đang nghiên cứu kỹ thuật này, vì nó là xu hướng chung, mình không học hỏi sẽ bị tụt hậu.

Team anh Nhiên bàn việc và phân công dự án

3 lời khuyên anh dành cho các bạn automation QA trẻ để các bạn có thể thực hành ngay và cải thiện bản thân mình?

1) Phải xác nhận thông tin cẩn thận với khách hàng.

Có một lần, khi khách hàng đưa yêu cầu mới cho automation framework anh đang đảm trách. Mọi thứ trao đổi qua Skype, và dù mỗi tuần, anh báo cáo đầy đủ việc đã làm xong – đang làm – sẽ làm và vướng mắc nếu có, nhưng đến khi bàn giao sản phẩm, họ nói ‘đó không phải là cái chúng tôi muốn.’

Từ đó anh rút ra bài học là mỗi khi trao đổi với khách hàng, mình đều phải viết meeting minutes, gửi cho khách hàng và yêu cầu họ trả lời xác nhận email đó, để tránh xảy ra vấn đề hiểu nhầm hoặc khách hàng chối bỏ những yêu cầu mà họ đưa ra trước đó.

2) Không được bảo thủ.

Do có nhiều kinh nghiệm về tạo automation testing framework, nên có một lần, khách hàng đề nghị anh là để tốt hơn cho người sử dụng, framework của anh nên hỗ trợ việc bắt các test object bằng nhãn, những chữ hiện thấy (visible text) trên web page thay vì bắt người dùng phải tìm thông tin mang tính kỹ thuật như XPath.

Nghĩ mình có nhiều kinh nghiệm trong việc bắt XPath, anh cố gắng bảo vệ quan điểm của mình và thuyết phục khách hàng rằng như vậy là không chính xác + mất nhiều thời gian xử lý.

Nhưng sau một thời gian trao đổi + suy nghĩ, anh thấy cách của khách hàng là một hướng đi mới cũng rất khả quan.

Dù có nhiều khó khăn, nhưng mình nên tìm cách giải quyết thay vì bác bỏ ngay từ đầu.

Cuối cùng, anh quyết định làm theo yêu cầu của khách hàng, và dự án đó thành công.

3) Tư vấn không có nghĩa là quyết định.

Có lần anh làm việc với một khách hàng Mỹ, và xảy ra tranh luận về quan điểm, họ muốn anh làm cách A, nhưng với kinh nghiệm của mình, anh biết đó không phải là lựa chọn tốt, anh thuyết phục họ làm theo cách B của anh.

Cuộc tranh luận ngày càng gay gắt, và sếp anh kịp thời can thiệp để chỉ cho anh biết rằng: là người tư vấn, anh nên chỉ cho khách hàng biết họ có những lựa chọn nào, thuận lợi – khó khăn của từng lựa chọn. Rồi khách hàng mới là người quyết định chọn cái nào, và chính họ chịu trách nhiệm về sự lựa chọn đó.

Cuối cùng, anh làm theo cách A của khách hàng, nhưng sau khi chạy dự án một thời gian, họ nhận ra cách của họ không phù hợp, nên họ yêu cầu chuyển sang làm cách B của anh.

Cuối cùng, dự án phát sinh thêm một số chi phí, nhưng khách hàng hiểu vấn đề là do họ chọn sai cách nên họ sẵn lòng trả thêm. Dự án vẫn thành công.

Trong suốt sự nghiệp của mình, anh có thường xuyên tham khảo sách/ resource nào không?

Anh có tham khảo hai quyển sách.

1) Automated Testing Handbook. Quyển sách này mô tả rõ ràng và đầy đủ các đặc điểm chính và các tính năng tìm kiếm trong một bộ kiểm tra tự động.

2) Experiences Of Test Automation. Những cách tiếp cận vấn đề phù hợp, các ứng dụng nào có thể áp dụng automated test, và automated test thay đổi như thế nào. Đây là ba vấn đề trọng điểm được bao quát trong quyển sách này.

Một bạn nếu chọn phát triển sự nghiệp theo định hướng QA thì bạn đó sẽ có những hướng phát triển nào?

Trường đại học ít khi dạy kỹ năng testing để trở thành QA. Thông thường các bạn phải tham gia một chương trình đạo tạo ngắn hạn, ví dụ như Launch Program ở KMS Technology để chuẩn bị bước vào nghề QA.

Từ junior QA, các bạn có thể phát triển lên senior QA. Rồi từ đó có hai hướng chính cho bạn phát triển.

1) Đi theo hướng management, tức là bạn thăng tiến lên làm QA Lead, sau đó là QA Manager.

2) Đi theo hướng technical, giống như anh, hiện tại anh là QA Architect.

Bạn có đang gặp khó khăn trong sự nghiệp QA của mình? Hãy cùng thảo luận với anh Nhiên và các bạn khác tại phần bình luận cuối bài.

Xem thêm các việc làm Automation QA tại ITviec

P.S. Thỉnh thoảng, anh Nhiên tổ chức thêm các lớp dạy automated test dành cho các bạn manual QA muốn chuyển hướng sự nghiệp sang làm automated QA, bởi vì hiện nay chưa có trường lớp chính quy nào dạy về vấn đề này. Đến hiện tại anh đã dạy được 4-5 lớp. Bạn nào có nhu cầu học thì có thể liên hệ anh qua email tmsnhien@gmail.com.