Nhungbunaa
Thành viên
- Tham gia
- 28/10/2015
- Bài viết
- 6
Tháng 6/1999 tôi bước chân vào FSoft (thời gian đó là FSU1) và bắt đầu với vị trí tester cho dự án LifeServ. Lần đầu làm quen với công việc test trong một dự án, mọi thứ đều mới mẻ. Chật vật lắm tôi mới viết xong một tài liệu test, hình như là test plan, nhưng viết xong rồi cũng không bao giờ dùng đến nó nữa!. Rồi tháng 5/2000, tôi tham gia test cho dự án đầu tiên của G1 - dự án ProxiGate, cùng với NganVK. Trong dự án này, tôi thực hiện tất cả các bước chuẩn bị: viết test plan, test case, làm test data. NganVK viết code giả lập front-end để test phần back-end. Sau hai dự án đầu tiên này, tôi được “trên” giao cho tìm hiểu về test. Đọc và học Tester, tôi đã biết được nhiều điều thú vị về test. Điều quan trọng nhất là tôi hiểu tester trong dự án thực sự là một nghề độc lập, một vị trí không thể thiếu trong ngành công nghiệp phần mềm.Test là một công việc khó, nói đúng ra là một công việc mơ hồ, kém xác định hơn công việc coding. Hồi còn đại học, sinh viên chúng tôi được đào tạo về thiết kế chương trình, lập trình còn khái niệm về test chương trình thì “mù tịt”, đâu có được học. Khi nhận yêu cầu xây dựng chương trình mới, tôi có thể hình dung được công việc mình sẽ làm, khi nào thì hoàn tất. Nhưng mọi việc sẽ không rõ ràng như thế khi tôi nhận test chương trình. Khi tự viết một chương trình, bạn dễ tự tin hơn khi khẳng định chất lượng của nó, nhưng khi test chương trình của người khác, việc đó không dễ chút nào. Làm sao biết được test bao nhiêu là đủ? Khi nào yên tâm khẳng định rằng chất lượng chương trình đạt để giao cho khách?
Tester phải hình dung các trường hợp có thể xảy ra với chương trình (các test scenario) để thử thực hiện chúng. Vậy làm sao đảm bảo rằng không tình huống quan trọng nào bị bỏ qua?. Lúc này, tester cần có khả năng phân tích hệ thống, hiểu kỹ về nghiệp vụ (business) của chương trình, đặc biệt, phải có quan điểm độc lập với developer. Sau đó, tester viết tất cả những phân tích của mình trong tài liệu test case (hay test design). Test case là tài liệu mô tả tất cả các bước tester làm để tạo các tình huống có thể xảy ra và kiểm tra “phản ứng” của chương trình có đúng với kết quả mong muốn không rồi tester tạo ra bộ test data dùng trong quá trình test dựa trên test case mình viết.
Viết test case và chuẩn bị test data chiếm rất nhiều thời gian, cần sự tỉ mỉ và tính cẩn thận của người test. Công việc này bắt đầu từ giai đoạn phân tích thiết kế của dự án để hoàn thành trước khi thực hiện test. Giống như developer, tester cũng phải update test case và test data khi có sự thay đổi requirement, design của dự án. Công việc của chúng tôi sẽ thuận lợi hơn nếu PL luôn nhớ thông báo kịp thời mọi thay đổi. Với một khối lượng công việc như vậy, chúng tôi có thể mắc sai sót. Vì vậy, việc development team review lại test case là rất cần thiết.
Nếu công việc chuẩn bị suôn sẻ, tester sẽ bắt tay vào test chính thức dự án. Rất nhiều tình huống khó khăn có thể xảy đến cho tester lúc này. Làm thế nào nếu tiến độ test bị chậm, không kịp test hết test case? Có thay đổi nào trong chức năng chương trình mà tester không được biết? Làm gì đây nếu developer (thậm chí cả PL) không chấp nhận lỗi do tester bắt được? Cãi nhau chăng? Xử lý sao đây nếu developer không unit test cẩn thận, giao cho chương trình quá nhiều lỗi trong khi ngày bàn giao code đã gần kề? Phải làm sao đây nếu việc bug fix kéo đến tận ngày cuối deliver sản phẩm, tester không thể bảo đảm được các phần test trước đó không bị lỗi mới? Áp lực công việc làm cho mọi người dễ nổi cáu, cãi nhau và … stress.
Một tester (chính xác hơn là Test Leader trong dự án) có kinh nghiệm, có trách nhiệm sẽ phải lường trước tất cả những khó khăn đó và có biện pháp đối phó. Tài liệu test plan sẽ giúp bạn làm việc đó. Nếu test plan được chuẩn bị tốt, nó sẽ trở thành công cụ giúp test team communicate hiệu quả hơn với development team. Development team hiểu rõ hơn công việc và khó khăn của nhóm test, tạo điều kiện tốt hơn cho nhóm test làm việc.
Cuối cùng, sau khi test, bạn sẽ lập báo cáo như thế nào? Bản báo cáo phải làm sao để có tính thuyết phục?. Nó cần phải chính xác, cụ thể và có lập luận chặt chẽ, một việc không đơn giản. Nếu trong test report bạn có thể đưa ra kết luận chất lượng chương trình chính xác thì bạn đã là một tester cao cấp rồi đấy.
Những công việc và kỹ năng trên đây của tester mới chỉ đủ đáp ứng cho functional test trong giai đoạn system test. Để thực hiện performance test, integration test, tester phải có kỹ thuật tốt, cũng như phải biết các phương pháp chuyên dùng để thực hiện test. Tuy nhiên đó lại là cả một câu chuyện dài.
Bạn thấy đấy, test đâu phải là công việc đơn giản, thuần tuý “chân tay” theo kiểu chạy đi chạy lại chương trình cần test ngẫu nhiên để xem có lỗi gì không. (Thậm chí câu hỏi “hiện tượng vừa xảy ra có thực sự là lỗi không” không phải lúc nào cũng dễ trả lời.). Để trở thành một tester “có đẳng cấp”, bạn cần phải có rất nhiều kỹ năng, từ lập kế hoạch, quản lý công việc, phân tích, viết tài liệu, communication, lên báo cáo, và tất nhiên cả kiến thức vững vàng về kỹ thuật nữa.
Tester phải hình dung các trường hợp có thể xảy ra với chương trình (các test scenario) để thử thực hiện chúng. Vậy làm sao đảm bảo rằng không tình huống quan trọng nào bị bỏ qua?. Lúc này, tester cần có khả năng phân tích hệ thống, hiểu kỹ về nghiệp vụ (business) của chương trình, đặc biệt, phải có quan điểm độc lập với developer. Sau đó, tester viết tất cả những phân tích của mình trong tài liệu test case (hay test design). Test case là tài liệu mô tả tất cả các bước tester làm để tạo các tình huống có thể xảy ra và kiểm tra “phản ứng” của chương trình có đúng với kết quả mong muốn không rồi tester tạo ra bộ test data dùng trong quá trình test dựa trên test case mình viết.
Viết test case và chuẩn bị test data chiếm rất nhiều thời gian, cần sự tỉ mỉ và tính cẩn thận của người test. Công việc này bắt đầu từ giai đoạn phân tích thiết kế của dự án để hoàn thành trước khi thực hiện test. Giống như developer, tester cũng phải update test case và test data khi có sự thay đổi requirement, design của dự án. Công việc của chúng tôi sẽ thuận lợi hơn nếu PL luôn nhớ thông báo kịp thời mọi thay đổi. Với một khối lượng công việc như vậy, chúng tôi có thể mắc sai sót. Vì vậy, việc development team review lại test case là rất cần thiết.
Nếu công việc chuẩn bị suôn sẻ, tester sẽ bắt tay vào test chính thức dự án. Rất nhiều tình huống khó khăn có thể xảy đến cho tester lúc này. Làm thế nào nếu tiến độ test bị chậm, không kịp test hết test case? Có thay đổi nào trong chức năng chương trình mà tester không được biết? Làm gì đây nếu developer (thậm chí cả PL) không chấp nhận lỗi do tester bắt được? Cãi nhau chăng? Xử lý sao đây nếu developer không unit test cẩn thận, giao cho chương trình quá nhiều lỗi trong khi ngày bàn giao code đã gần kề? Phải làm sao đây nếu việc bug fix kéo đến tận ngày cuối deliver sản phẩm, tester không thể bảo đảm được các phần test trước đó không bị lỗi mới? Áp lực công việc làm cho mọi người dễ nổi cáu, cãi nhau và … stress.
Một tester (chính xác hơn là Test Leader trong dự án) có kinh nghiệm, có trách nhiệm sẽ phải lường trước tất cả những khó khăn đó và có biện pháp đối phó. Tài liệu test plan sẽ giúp bạn làm việc đó. Nếu test plan được chuẩn bị tốt, nó sẽ trở thành công cụ giúp test team communicate hiệu quả hơn với development team. Development team hiểu rõ hơn công việc và khó khăn của nhóm test, tạo điều kiện tốt hơn cho nhóm test làm việc.
Cuối cùng, sau khi test, bạn sẽ lập báo cáo như thế nào? Bản báo cáo phải làm sao để có tính thuyết phục?. Nó cần phải chính xác, cụ thể và có lập luận chặt chẽ, một việc không đơn giản. Nếu trong test report bạn có thể đưa ra kết luận chất lượng chương trình chính xác thì bạn đã là một tester cao cấp rồi đấy.
Những công việc và kỹ năng trên đây của tester mới chỉ đủ đáp ứng cho functional test trong giai đoạn system test. Để thực hiện performance test, integration test, tester phải có kỹ thuật tốt, cũng như phải biết các phương pháp chuyên dùng để thực hiện test. Tuy nhiên đó lại là cả một câu chuyện dài.
Bạn thấy đấy, test đâu phải là công việc đơn giản, thuần tuý “chân tay” theo kiểu chạy đi chạy lại chương trình cần test ngẫu nhiên để xem có lỗi gì không. (Thậm chí câu hỏi “hiện tượng vừa xảy ra có thực sự là lỗi không” không phải lúc nào cũng dễ trả lời.). Để trở thành một tester “có đẳng cấp”, bạn cần phải có rất nhiều kỹ năng, từ lập kế hoạch, quản lý công việc, phân tích, viết tài liệu, communication, lên báo cáo, và tất nhiên cả kiến thức vững vàng về kỹ thuật nữa.
