Tester: "Người canh cổng" chất lượng phần mềm

Các SP phần mềm (PM) muốn đứng được trên thị trường phải trải qua một quy trình nghiêm ngặt từ thu thập yêu cầu, thiết kế, lập trình đến kiểm định (testing) và bảo trì. Chính vì vậy nghề kiểm thử đã trở thành một bộ phận quan trọng tại các công ty sản xuất và gia công PM. Tạp chí TGVT số này đề cập đến vai trò của nghề này và thực tế của những người hoạt động trong nghề.

Nghề kiểm định

SP PM luôn chứa các lỗi tiềm ẩn mà quá trình sử dụng thực tế người dùng có thể sẽ gặp phải. Lỗi được tìm thấy có thể rất nhỏ như font chữ, giao diện cho đến những lỗi lớn như sai chức năng, không thực thi câu lệnh... Cá biệt, có những lỗi, sự cố nghiêm trọng gây ngưng trệ hệ thống, ảnh hưởng không nhỏ đến quá trình kinh doanh của doanh nghiệp...

Tùy theo mức độ ưu tiên, người kiểm thử/chuyên viên kiểm thử (Tester), trưởng nhóm dự án (Team Leader), trưởng dự án (Project Manager) hoặc khách hàng đánh giá và yêu cầu cần phải sửa, hoàn thiện ngay. Công việc chính của một kỹ sư kiểm định PM (Tester) là kiểm tra để bảo đảm rằng PM bám sát và thỏa mãn các yêu cầu đặt ra, phát hiện những lỗi cần sửa, cũng như những đề xuất để cải tiến PM... Một Tester có thể dùng các kỹ thuật như kiểm tra tĩnh (static test), kiểm tra động (dynamic test) xuyên suốt trên các mức độ (level) test khác nhau để đảm bảo chất lượng SP.

Các nội dung test rất đa dạng: từ kiểm định hệ điều hành, các ứng dụng độc lập, đến các ứng dụng web... Đối với các công ty chuyên gia công PM viễn thông đòi hỏi tester phải có sự hiểu biết khá chuyên sâu về các hệ thống nhúng (embedded system), các thiết bị mạng, các lớp giao thức mạng lõi (network core protocols)... Bên cạnh đó ngành gia công vốn làm việc với các đối tác nước ngoài, tester còn phải có khả năng về ngoại ngữ và giao tiếp cũng như sự hiểu biết về văn hóa của khách hàng

Theo ông Ngô Quách Hy, một trong các trưởng nhóm kiểm định (Test Leader) của công ty Global Cybersoft, ngoài kiến thức chuyên ngành, một Tester còn phải có tư duy logic và tính cẩn thận rất cao trong công việc. Chúng ta chỉ có khái niệm “fix bug” chứ không có thuật ngữ “fix test” vì lập trình viên có thể mắc sai sót và sau đó sửa chữa, nhưng một kiểm định viên - người canh cổng sau cùng về chất lượng SP PM thì không có cơ hội để sửa sai, nhất là khi ứng dụng đó được đưa vào sử dụng.

Bà Nguyễn Phan Quỳnh Chi, trưởng nhóm Tester công ty TMA cho biết, thực tế có rất ít định nghĩa rõ rệt về tố chất của Tester chuyên nghiệp. Để nắm bắt tốt nghiệp vụ khách hàng Tester cần phải có tư duy phân tích hệ thống, tính logic, khả năng hình dung và khái quát vấn đề trước khi bắt đầu công việc cụ thể. Tất nhiên, tốt nghiệp chuyên ngành CNTT (hay các chuyên ngành công nghệ khác) là yêu cầu đầu tiên đối với nhà tuyển dụng. Nhưng để trở thành Tester chuyên nghiệp cần phải học tính kiên nhẫn vì không phải lúc nào công việc cũng dễ dàng và trơn tru như mong muốn... Có thể sự nhàm chán sẽ sớm xuất hiện sau một thời gian làm việc. Đơn giản vì đó là một công việc phải lặp đi lặp lại hàng ngày.

“Sẽ là một tai họa cho những người làm công việc testing khi lỗi được phát hiện và được phản ánh từ phía khách hàng”, Bà Nguyễn Phan Quỳnh Chi

Theo quy trình thông thường, các lập trình viên (Developer) sau khi hoàn tất phần công việc của mình – lập trình, các Tester sẽ phải kiểm tra thật kỹ từ đầu đến cuối vì rất có thể những phần mới lập trình sẽ ảnh hưởng đến phân hệ đã kiểm định trước đó. Công việc được thực hiện theo một kế hoạch chặt chẽ, bám sát tiến trình dự án và kết hợp chặt chẽ với bộ phận phát triển. Quá trình kiểm định gồm việc thực thi tuần tự và lặp đi lặp lại với khối lượng ngày càng nhiều các bước kiểm định. Mức độ am hiểu về hệ thống cũng như kinh nghiệm sẽ nhiều hơn, và do đó công việc kiểm định sẽ được thực hiện nhanh và hiệu quả hơn. Có lúc Tester cần phải tư duy như một hacker và cố tìm cách khai thác lỗi trên SP PM đã hoàn thành.

Một quy trình kiểm tra cơ bản có thể áp dụng rộng rãi cho nhiều hệ thống PM với những đặc trưng khác nhau. (Nguồn: Công ty Global CyberSoft )

Nghề và trách nhiệm

Cung cấp SP thỏa mãn khách hàng và không có lỗi luôn là tiêu chí và mục tiêu (dù không dễ) của các nhà sản xuất. Do vậy, bên cạnh các lực lượng khác trong dự án, Tester luôn đóng vai trò quan trọng. Trong các quy trình testing, tính năng của SP cần test sẽ được cụ thể hóa (thiết kế) thành các kịch bản test (test cases và test scripts). Từ các kịch bản test này, người ta chia nhỏ thành các bước test (test steps) trên cơ sở đã được xem xét và chỉnh sửa từ phía người viết và phê duyệt của những vị trí cao hơn. Tuy vậy không có nghĩa sản phẩm sau khi test xong là đã hết lỗi (error-free). Theo hiệp hội PM Mỹ, hơn 15% các lỗi PM được phát hiện và phản ánh lại từ phía khách hàng đang sử dụng trực tiếp SP, trong khi tỷ lệ cho phép lỗi trên một SP PM chưa tới 7%.

Dù muốn hay không Tester vẫn sẽ là những người đầu tiên bị “truy cứu” khi một SP PM vẫn còn tồn tại hoặc phát sinh lỗi khi đưa ra thị trường, mặc dù việc phân tích chi tiết để xác định chính xác “lỗi do đâu” là cả một quá trình dài sau đó. Nhiều người nói testing là một nghề đầy thử thách và khó làm lâu dài. Một lỗi nặng bị phát hiện có thể làm hỏng công việc và tương lai nghề nghiệp của một Tester nếu lỗi rơi vào phần việc anh ta chịu trách nhiệm, việc xem xét lại năng lực làm việc, hay bố trí lại công việc rất có thể được đặt ra từ nhiều phía...

Các công cụ test phổ biến: Quick Test Pro, Silk Test, Selenium, Win Runner, Load Runner... Ông Ngô Quách Hy

Đào tạo và nhu cầu

Theo ông Hy, hiện có rất ít cơ sở (cả chính quy và phi chính quy) đào tạo kiểm định viên vì đặc thù riêng của nghề là gắn với những dự án cụ thể. Cũng có một số nơi đã đưa vào giảng dạy một số đơn vị học trình về kiểm định, tuy nhiên chưa mang tính hệ thống và vẫn còn hạn chế nhiều về thực hành. Phần lớn, doanh nghiệp tự đào tạo là chính.

Kiến thức nền tảng dành cho một kiểm định viên không khác biệt nhiều với lập trình viên. Môi trường ĐH nhằm trang bị kiến thức nền tảng, không nhất thiết và không thể thiết kế để huấn luyện chuyên biệt cho lập trình viên hoặc kiểm định viên vốn rất đa dạng và chuyên sâu ở rất nhiều lĩnh vực. Điều này chỉ có thể thực hiện hiệu quả ở các lớp huấn luyện chuyên nghiệp (như các lớp đào tạo lập trình viên) hoặc tại các doanh nghiệp.

“Với một sinh viên mới tốt nghiệp và bắt đầu công việc Tester, bạn sẽ có cơ hội phát huy tối đa khả năng tự học và nghiên cứu (một kỹ năng còn khá khiêm tốn của sinh viên). Vì ở bất kỳ công ty nào, việc đào tạo nội bộ cho Tester thường mang tính định hướng về giải pháp, cách tiếp cận SP, kiến thức và kỹ năng kiểm định cần thiết và một số chỉ dẫn khác, còn lại phải tự học mọi cái và cố xoay xở với vốn thời gian ít ỏi của mình, nhất là khi làm việc với những hệ thống phức tạp. Điều này hoàn toàn không dễ dàng đối với sinh viên mới tốt nghiệp. Tuy nhiên, sinh viên sẽ sớm có tác phong làm việc chuyên nghiệp, cách sắp xếp thời gian để có thể làm được nhiều việc cùng lúc và trên hết là học cách xây dựng tính tự tin khi giải quyết công việc”, ông Hy nói.

Nghề testing thường bắt đầu từ vị trí đơn giản đến phức tạp. Theo bà Chi, khi mới vào nghề, Tester sẽ có một thời gian để làm quen và sẽ bắt tay vào việc sau đó vài tuần. Khoảng thời gian từ 6 tháng đến 1 năm thường là mốc để đánh giá năng lực của một Tester trước khi anh ta bước vào một ngưỡng cửa mới của nghề nghiệp để thể hiện năng lực bản thân. Và cần từ 2 đến 3 năm nữa, anh ta sẽ có cơ hội để trở thành một chuyên gia am tường về lĩnh vực mình theo đuổi và đi xa hơn trong lĩnh vực kỹ thuật hay quản lý một nhóm nhân viên dưới quyền (Leader, Project Manager), hoặc anh ta sẽ chuyển sang một công việc khác nếu thấy mình phù hợp hơn trong lĩnh vực quản lý như trưởng bộ phận đảm bảo chất lượng (Quality Assurance Manager) hay trưởng dự án PM (Project Manager) thường là các chức danh cho các vị trí này.

Bất cứ công việc nào cũng cần có những công cụ làm việc thích hợp, testing cũng không phải là trường hợp ngoại lệ. Việc làm quen với các công cụ dùng trong testing và sử dụng thành thạo sẽ giúp Tester tiết kiệm được rất nhiều thời gian để phân tích và tìm lỗi trong SP.

Tester -“Tỉnh táo viên”

Chất lượng của một PM là kết quả của quá trình bao gồm nhiều bộ phận và các nhóm tham gia dự án khác nhau. Do đó, khi một lỗi xảy ra, nhất thiết lỗi đó phải được phân tích kỹ lưỡng trước khi kết luận Tester hay bộ phận nào khác phải chịu trách nhiệm.

Một SP PM trước khi được ứng dụng trên thị trường phải trải qua một quá trình phát triển với nhiều giai đoạn khác nhau với sự tham gia của rất nhiều người, việc loại bỏ lỗi trong quá trình phát triển rất khó bảo đảm mức 100%. Một Tester nếu tham gia dự án ngay từ ban đầu và áp dụng các kỹ thuật test tĩnh có thể phát hiện được rất nhiều lỗi trong thiết kế cũng như từ yêu cầu của khách hàng. Các lỗi này nếu không được phát hiện sớm sẽ trở thành trở ngại lớn cho chất lượng dự án trong các giai đoạn phát triển gần cuối.

Trường hợp có sự can thiệp của Tester suốt dự án mà PM vẫn mắc lỗi cơ bản hay nghiêm trọng khi sử dụng trong thực tế là điều khó thể chấp nhận. Trừ các trường hợp đặc biệt, khách hàng vì lý do kinh doanh có thể chấp nhận một số lỗi nhỏ đã được phát hiện trong quá trình phát triển và vẫn cho phép PM hoạt động trên thị trường, sau đó cung cấp các bản vá để sửa các lỗi đó sau.
Trường hợp lỗi gây ra do sự khác nhau của môi trường, điều kiện vận hành hay do PM không còn tương thích với các cập nhật mới của các nhà cung cấp thứ ba (third party), thì phải có được sự thảo luận kỹ càng của khách hàng và công ty cung cấp để tìm ra giải pháp và lên kế hoạch khắc phục chi tiết. Các lỗi này nằm ngoài dự tính của cả hai phía nên không thể quy trách nhiệm đơn phương cho bộ phận testing.

Hồng sơn