Câu trả lời của tôi: “Cách tiếp cận Agile có tác dụng tốt cho dự án nhỏ (3 tới 8 người). Khi tới việc kiểm thử, bản thân tổ phát triển làm việc kiểm thử riêng của mình. Không có phân biệt giữa người phát triển và người kiểm thử vì các thành viên thường chuyển đổi vai trò. Nói cách khác, với cách tiếp cận Agile “người phát triển” và “người kiểm thử” là một phần của tổ phát triển. Chẳng hạn với Lập trình cực đoan, có cách tiếp cận có tên là “Lập trình cặp đôi” nơi hai người cùng làm việc với nhau trong một nhiệm vụ. Người này đóng vai trò của “người phát triển” (hay người dẫn lái) còn người kia đóng vai trò “người kiểm thử” (hay người quan sát). Họ quan sát công việc của nhau, học từ nhau, kiểm điểm mã của nhau, và đưa ra phản hồi cho nhau. Người phát triển học kĩ năng kiểm thử từ người kiểm thử và người kiểm thử cũng học kĩ năng viết mã từ người phát triển. Chung cuộc họ chuyển đổi vai trò khi họ tiếp tục làm việc với nhau. Tuy nhiên, điều đó KHÔNG có nghĩa là việc làm của người kiểm thử bị khử bỏ. Là người kiểm thử, bạn sẽ được đưa vào trong tổ phát triển nơi bạn cũng sẽ học lập trình và làm việc như người phát triển nữa.
Tôi biết rằng đây là khác biệt so với cách tiếp cận thác đổ nơi người phát triển chỉ kiểm thử mã riêng của họ (kiểm thử đơn vị) rồi đưa nó cho người kiểm thử để làm các kiểm thử thêm (trắc nghiệm và kiểm nghiệm). Trừ phi công ti của bạn CHỈ hội tụ vào dự án nhỏ, sẽ có các dự án lớn hơn nữa (có thể 20, hay 50, hay 200 người) cho nên vẫn sẽ có nhu cầu về tổ kiểm thử độc lập. Dự án lớn thường phức tạp, găng, với nhiều khó khăn kĩ thuật cho một người được giữ nhiều vai trò. Các dự án lớn cũng yêu cầu những tri thức chuyên gia nào đó và yêu cầu người có kinh nghiệm, người có chuyên môn nào đó cho nên bạn KHÔNG nên lo lắng rằng việc kiểm thử sẽ mai một đi sớm.
Với hầu hết các dự án lớn, tổ phát triển sẽ hội tụ vào yêu cầu, kiến trúc, thiết kế, viết mã và kiểm thử đơn vị. Tổ kiểm thử làm việc song song với các hoạt động phát triển nhưng hội tụ vào các vấn đề riêng mà thường khó cho tổ phát triển tìm ra và cung cấp phản hồi cho tổ phát triển. Kiểu kiểm thử này là tương tự với cách tiếp cận “lập trình cặp đôi” trong Agile nhưng tổ kiểm thử có kinh nghiệm và được đào tạo để thực hiện những kiểm thử nào đó (trắc nghiệm và kiểm nghiệm) để đảm bảo chất lượng là “có sẵn”. Chẳng hạn, tổ kiểm thử sẽ hội tụ vào vấn đề tích hợp (kiểm thử tích hợp) để đảm bảo rằng giải pháp của tổ phát triển sẽ làm việc tốt với hệ thống hiện có hay giải pháp được thực hiện bởi tổ phát triển khác. Với hệ thống phức tạp, tổ kiểm thử có thể hội tụ vào vấn đề an ninh (kiểm thử an ninh) và chắc chắn rằng nó được thiết kế tốt và khớp với hệ thống hiện thời. Trong hầu hết các dự án lớn, có vài tổ phát triển, từng tổ tập trung vào chức năng nào đó hay khu vực đặc biệt, nhưng phải có một tổ kiểm thử độc lập để giám sát mọi thứ và chắc chắn rằng hệ thống phát triển sẽ làm việc (kiểm thử trắc nghiệm và kiểm nghiệm).
Trừ phi bạn thực sự thích làm việc mãi mãi là người kiểm thử, tôi tin việc học kĩ năng mới, tri thức mới là tiến bộ tự nhiên trong nghề phần mềm. Tôi sẽ KHÔNG ngần ngại học về Agile và chuẩn bị làm việc trong các vai trò mới như người lập trình, người phát triển, hay thậm chí Thầy Scrum. Bạn càng có nhiều tri thức, việc làm của bạn càng an ninh hơn. ĐỪNG lo về chiều hướng của công ti chuyển sang Agile mà hội tụ vào điều bạn có thể học và điều bạn có thể làm để cải tiến nghề nghiệp của mình. Bạn muốn là nhà chuyên nghiệp phần mềm giỏi nhất, vai trò và trách nhiệm nào không thành vấn đề.”
I received an email where the sender wrote: “Someone told me that in Agile method, there is NO jobs for tester. As a tester, I am worry about my future since my company is planning to use Agile method (Scrum) soon. Please advise.”
My answer: “The Agile approach works well for small projects (3 to 8 people). When it comes to testing, the development team itself does its own testing. There is no distinguish roles between developers and testers as team members often switch roles. In other world, with Agile approach “developers” and “testers” are part of the development team. For example, with Extreme Programming, there is an approach called “Pair programming” where two people work together in one task. One plays the role of “Developer” (or Driver) and the other play “Tester” (or Observer). They observe each other’s works, learn from each other, review each other’s code, and provide feedbacks to each other. The developer learns testing skills from tester and the tester also learns coding skills from the developers. Eventually they switch roles as they continue to work together. However, it does NOT mean the tester’s job is eliminated. As a tester, you will be included in the development team where you will also learn programming and work as developer too.
I know that this is different from the waterfall approach where developers only test their own code (Unit test) then give it to testers for additional tests (verification and validation). Unless your company is ONLY focusing on small projects, there will be larger project too (Maybe 20, or 50, or 200 people) so there is still a need for independent testing team. Large project is usually complex, critical, with many technical difficulties for one person to assume many roles. Larger projects also require certain expertise and experienced people who has certain specialty so you should NOT worry that testing job will go away soon.
For most large project, the developing team would focus on requirements, architect, design, code, and unit tests. The test team is working in parallel with the development activities but focuses more on specific problems which are difficult for the development team to find and provide feedbacks to the development team. This types of testing is similar to the “Pair programming” approach in Agile but the testing team is experienced and trained to performs certain tests (Verification and Validation) to ensure quality is “built in”. For example, the test team will focus on the integration issues (Integration tests) to ensure that the development team’s solution will work well with existing systems or solutions done by other development teams. For complex system, the test team may focus on the security issue (Security testing) and make sure that it is well designed and fits into current systems. In most large projects, there are several development teams, each is concentrating on certain functions or specific area, but there should be only one independent test team to oversee everything and make sure that the develop system will work (Verification and Validation tests).
Unless you really like to work permanently as a tester, I believe learning new skills, new knowledge is a natural progression in a software career. I would NOT hesitate to learn about Agile and prepare to work in new roles such as programmer, developers, or even Scrum Master. The more knowledge you have, the more secure is your job. Do NOT worry about the company’s direction to move to Agile but focus on what you can learn and what you can do to improve your career. You want to be the best software professional possible, no matter what roles and what responsibilities”.
