Tôi nhận được một email từ một sinh viên: “Em sẽ tốt nghiệp trong Khoa học máy tính năm nay và tìm việc làm. Có thể là em sẽ bắt đầu làm người kiểm thử phần mềm. Có khác biệt giữa trường học và công nghiệp liên quan tới kiểm thử phần mềm không? Kiểm thử thực tế được thực hiện trong công ti phần mềm thế nào? Thầy có ‘lời khuyên thực hành’ nào không?”
Đáp: Phần lớn sinh viên tính toán bắt đầu nghề nghiệp của họ là người kiểm thử phần mềm nơi họ học về dự án phần mềm trước khi chuyển sang vị trí khác. Sau đây là một số lời khuyên, tôi dùng vòng đời thác đổ vì nó vẫn được dùng trong hầu hết các công ti, tôi sẽ thảo luận về kiểm thử agile trong bài viết khác:
Giả sử rằng bạn bắt đầu một dự án mới. Mọi dự án đều bắt đầu bằng cuộc họp “khởi động”. Trong cuộc họp này người quản lí dự án sẽ giải thích về khách hàng và người dùng của dự án (nội bộ hay bên ngoài), phạm vi dự án, thời gian, lịch biểu và khi nào nó phải được chuyển giao. Người quản lí sẽ phân công các vai trò, trách nhiệm và thẩm quyền cho từng thành viên. Chẳng hạn người quản lí dự án, lãnh đạo kĩ thuật, đảm bảo chất lượng, lãnh đạo tổ, người phát triển, người kiểm thử v.v.
Phần lớn các dự án bắt đầu từ đặc tả yêu cầu phần mềm Software Requirement Specification (SRS) nơi kế hoạch dự án được phát triển. Điều đầu tiên người kiểm thử phải làm là kiểm điểm SRS và tạo ra bản kế hoạch kiểm thử phần mềm. Bản kế hoạch kiểm thử có thể được tách rời hay được đưa vào trong bản kế hoạch dự án. Bản kế hoạch kiểm thử bao quát mọi hoạt động kiểm thử: mục tiêu, phân công kiểm thử (ai sẽ kiểm thử mô đun nào), loại kiểm thử nào được tiến hành theo lịch (như, tích hợp, an ninh, rà lại v.v..), số các chức năng được kiểm thử, tiêu chí rủi ro, lịch biểu kiểm thử, phương pháp kiểm thử, công cụ kiểm thử, và môi trường kiểm thử (hỗ trợ nền). Bản kế hoạch kiểm thử sẽ được người quản lí dự án kiểm điểm để chấp thuận. Điển hình, người lãnh đạo kiểm thử sẽ viết ra bản kế hoạch kiểm thử nhưng mọi người kiểm thử đều có thể tham gia và đóng góp vào bản kế hoạch này. Cho dù bạn là người kiểm thử mới, bạn nên làm quen với bản kế hoạch kiểm thử bởi vì đây là tài liệu đầu tiên bạn phải hiểu rõ để làm việc của mình.
Dự án sẽ chuyển sang pha kiến trúc (mức cao) và pha thiết kế (mức chi tiết) nơi công việc dự án được chia thành các mô đun khác nhau hay các nhiệm vụ nhỏ hơn và được phân công cho người phát triển viết mã. Người kiểm thử phải tham gia vào cả kiểm điểm kiến trúc và thiết kế để hiểu cách công việc dự án được chia ra, cách từng chức năng được chia thành các mô đun nhỏ hơn, cách từng mô đun được chia thành các nhiệm vụ nhỏ hơn (nếu cần). Bằng việc hiểu các công việc dự án này, người kiểm thử có thể tạo ra kịch bản kiểm thử và trường hợp kiểm thử tương ứng với từng mô đun hay nhiệm vụ được phân công. Những trường hợp kiểm thử này sẽ được tổ hợp lại về sau trong các trường hợp kiểm thử chức năng tương ứng với SRS.
Nhiều người kiểm thử không thích tham gia vào kiểm điểm, nhưng đợi cho tới khi việc viết mã được hoàn thành rồi bắt đầu viết trường hợp kiểm thử. Đó là sai lầm lớn. Nếu người kiểm thử KHÔNG tham gia vào kiểm điểm, họ sẽ KHÔNG hiểu dự án đủ rõ để viết trường hợp kiểm thử tốt. Nếu họ bỏ lỡ cái gì, điều đó sẽ tạo ra nhiều vấn đề hơn về sau trong hoạt động kiểm nghiệm. Điều bản chất cho mọi thành viên dự án, kể cả người kiểm thử và người phát triển, là tham gia vào kiểm điểm dự án bởi vì đây là lúc họ thực sự học về dự án. Nhiều người kiểm thử mới bảo tôi rằng họ KHÔNG thích kiểm điểm vì chúng có quá nhiều chi tiết kĩ thuật tới mức họ không hiểu, và họ không muốn ngồi yên tĩnh và “có vẻ ngu”. Câu trả lời của tôi là: “Không ai chú ý tới bạn vì bạn chỉ mới bắt đầu việc mới của bạn. Tuy nhiên, mọi người sẽ hỏi bạn các câu hỏi và có mong đợi sau khi bạn đã làm ở việc này trong vài tháng. Cho nên điều quan trọng với bạn, như người kiểm thử mới, là học cái gì đó nhanh chóng, nếu bạn KHÔNG muốn “có vẻ ngu” sáu tháng sau khi làm việc ở đó mà vẫn không thể trả lời được cái gì.
Khi người phát triển hoàn thành từng mô đun riêng của họ, họ sẽ kiểm thử mã riêng của họ (kiểm thử đơn vị) trước khi phân công cho người kiểm thử về trắc nghiệm độc lập. Người kiểm thử sẽ bắt đầu kiểm thử mô đun bằng việc thực hiện trường hợp kiểm thử riêng của họ để chắc chắn rằng các mô đun này làm việc. Nếu chúng không làm việc, mô đun được gửi trả lại cho người phát triển để sửa chúng. Kiểm thử mô đun là không thể vét hết được, chỉ kiểm tra liệu mô đun có chạy tương ứng và không đi vào chi tiết. Vào lúc này, bất kì lỗi nào được tìm thấy đều phải được ghi lại trong công cụ theo dõi vết để trắc nghiệm về sau. Điều quan trong là đảm bảo rằng mọi lỗi đã được nhận diện đều được sửa trước khi đưa ra cho khách hàng. Sau khi người phát triển đã sửa lỗi, người kiểm thử phải thực hiện kiểm thử của họ lần nữa để trắc nghiệm rằng nó đã qua được và lỗi sẽ được đánh dấu là “đóng”. Bằng không, nó vẫn còn “mở” nghĩa là nó còn chưa được chữa. Loại kiểm thử rà lại này là rất quan trọng để tìm lỗi sau khi thay đổi hay sửa chữa đã được thực hiện. Nó được thiết kế để giả định rằng thay đổi hay sửa chữa không tạo ra lỗi mới. Mọi thông tin về lỗi đều phải được làm tài liệu trong báo cáo trạng thái lỗi (báo cáo lỗi) và gửi cho người quản lí dự án trên cơ sở hàng tuần (Đôi khi hàng ngày nếu đó là qui trình dựng hàng ngày).
Có vài kiểu kiểm thử, tuỳ theo yêu cầu của dự án và khách hàng. Thông thường, vài mô đun được tổ hợp rồi người kiểm thử sẽ thực hiện kiểm thử tích hợp hay kiểm thử tích hợp mô đun. Nếu vài mô đun được tổ hợp thành chức năng thì người kiểm thử sẽ thực hiện kiểm thử chức năng. Có kiểm thử phụ đi vào chi tiết hơn trên các phần cứng khác nhau, phiên bản hệ điều hành, các nền, hay các trình duyệt khác nhau v.v. Tất cả những kiểm thử này phải được lập kế hoạch và làm tài liệu trong bản kế hoạch kiểm thử dựa trên SRS.
Cuối cùng nếu mọi kiểm thử đều qua, toàn bộ sản phẩm phần mềm được trải qua kiểm thử hệ thống trong môi trường kiểm thử tương tự như môi trường của người dùng. (Thỉnh thoảng nó có thể được thực hiện trong “môi trường” người dùng thực tại, nếu dự án là nội bộ hay phát triển tại chỗ). Nếu sản phẩm qua được mọi trường hợp kiểm thử, người kiểm thử sẽ viết báo cáo kiểm thử cuối cùng và người quản lí dự án sẽ ra quyết định đưa ra sản phẩm cho khách hàng.
Lời khuyên của tôi là: “Nếu bạn bắt đầu làm việc như người kiểm thử mới, bạn phải học về vòng đời dự án phần mềm được dùng trong dự án. Bạn phải kiểm điểm đặc tả yêu cầu phần mềm (SRS) để hiểu dự án (tôi biết rằng việc đó là chán, một số SRS sẽ làm cho bạn buồn ngủ nhưng nhớ rằng bạn đang học làm việc và đây là việc thực). Bạn phải hiểu mục đích và mục tiêu dự án, cũng như lịch biểu và ngày mục tiêu để đưa ra. Là người kiểm thử mới, bạn phải biết chi tiết kế hoạch kiểm thử để cho bạn hiểu mục tiêu dự án, phương pháp kiểm thử, tính năng hay chức năng được kiểm thử, hay KHÔNG được kiểm thử. Rủi ro kiểm thử, lịch biểu kiểm thử, môi trường hỗ trợ và nền được dùng để kiểm thử và mọi chi tiết kĩ thuật về kiểm thử phần mềm. Điều rất quan trọng cho bạn là tham gia vào mọi cuộc kiểm điểm dự án. ĐỪNG đợi cho tới khi pha viết mã xong rồi mới bắt đầu làm việc trên các trường hợp kiểm thử của mình. Bạn phải bắt đầu viết các trường hợp kiểm thử vào cùng lúc người phát triển bắt đầu thiết kế của họ rồi thêm nhiều chi tiết hơn khi nhiều thông tin hơn là sẵn có. Bạn phải học cách dùng công cụ theo dõi lỗi (công cụ dõi lỗi) và có khả năng viết báo cáo tình trạng lỗi (báo cáo lỗi).
Điều đó có thể dường như là nhiều nhưng có nhiều điều hơn mà bạn sẽ phải học trong công nghiệp phần mềm để thăng tiến nghề nghiệp của bạn. Xin giữ thái độ tích cực và nhớ rằng bạn vẫn học vì nghề nghiệp chuyên môn của bạn chỉ mới được bắt đầu.
—-English version—-
What does a new tester need?
I received an email from a student: “I will graduate in Computer Science this year and look for job. It is likely that I will start as a software tester. Are there differences between school and industry regarding software testing? How would the actual testing be done in a software company? Do you have any “practical advices” ?
Answer: Most computing students start their careers as software testers where they learn about software project before move on to other positions. Following are some advices, I am using the waterfall life cycle since it is still being used in most companies, I will discuss agile testing in another writing:
Assume that you are starting on a new project. Every project starts with a project “kick off” meeting. In this meeting the project manager will explain about the customers and users of the project (Internal or external), the project scope, time, schedule and when it must be delivered. The manager will assign roles, responsibilities and authority of team members. For example Project manager, Technical leaders, Quality Assurances, Team leaders, Developers, Testers etc.
Most projects start from the Software Requirement Specification (SRS) where the project plan is developed. The first thing testers must do is to review the SRS and create a Software Testing Plan. The testing plan can be separated or included in the project plan. The testing plan covers all testing activities: Objectives, testing assignments (Who will test what module), what kinds of test to be conducted according to the schedule (i.e., Integration, security, function, regression, etc.), the number of functions to be tested, risk criteria, testing schedule, testing methods, testing tools, and testing environment (Platform support). The testing plan will be reviewed by project manager for approval. Typically, test leader will write the testing plan but all testers could participate and contribute to the plan. Even if you are a new tester, you should be familiar with the testing plan because this is the first document that you must understand well to do your job.
The project will go to the Architecture phase (High level) and Design phase (Detailed level) where project work is divided into different modules or smaller tasks and distributed to developers to code. Testers must participate in both architecture and design reviews to understand how the project work is broken down, how each function is divided into smaller modules, how each module is divided into smaller tasks (If needed). By understand these project works, testers can create test scenarios and test cases according to each assigned modules or tasks. These test cases will be combined later into functional test cases according to the SRS.
Many testers do not like to participate in reviews, but wait until coding is done then start writing test cases. That is a big mistake. If testers do NOT participate in reviews, they will NOT understand the project well enough to write good test cases. If they miss anything, it will create more problems later in the validation activity. It is essential for all project members, including testers and developers, to participate in project reviews because these are the time where they really learn about the project. Many new testers told me that they do NOT like reviews as they have too many technical details that they do not understand, and they do not want sit quiet and “look stupid”. My answer is: “No one would pay attention at you since you just start on your new job. However, people will ask you questions and have expectations after you have been on the job for several months. So it is important for you, as new testers to learn something fast, if you do NOT want to “look stupid” six months after working there but still could not answer anything.
When developers complete their individual modules, they will test their own code (Unit Test) before assigned to testers for independent verification. Testers will start Module Testing by execute their own test cases to make sure that these modules work. If they fail, modules are reassigned back to developers to fix them. Module testing is non-exhausting, only to check if the module run accordingly and not go into the details. At this time, any defect found must be logged into a tracking tool for later verification. It is important to ensure that all identified defects are fixed before release to customers. After developers fixed defects, testers must execute their tests again to verify that it passes and the defect will be marked as “closed”. Otherwise, it is still “Open” means it is not fixed yet. This kind of Regression Test is very important to find defects after changes or fixes have been made. It is designed to assure that a change or a fix do not create new defects. All information about defects must be documented in Defect status report (Bug Report) and send to project manager on a weekly basis (Sometime, daily if it is a daily build process).
There are several types of test, depending on the project and customer’s requirements. Usually, several modules are combined then tester will execute Integration test or Module integration test. If several modules are combined into a function then testers will execute the Functional tests. There are additional tests that get into more details such as tests to check for compatibility, interfaces, security, and sometime testing on different hardware, Operating System versions, platforms, or different browsers etc. All these tests must be planned and documented in the Test plan based on the SRS.
Finally if every test passes, the entire software product is undergoes the System Test in a testing environment similar to the users’ environment. (Sometime it can be done in the actual user’s environment, if the project is internal or in-house project). If the product passes all test cases, testers will write a final test report and project manager will make decision to release the product to customer.
My advice is: “If you start to work as a new tester, you must learn about the software project life cycle being used in the project. You must review the software requirement specifications (SRS) to understand the project (I know that it is boring, some SRS will make you sleepy but remember that you are learning on the job now and this is real). You must understand the project goals and objectives, as well as schedule and target date for release. As a new tester, you must know the test plan in detail so you understand the test objectives, testing methods, features or functions to be tested, or NOT to be tested. Testing risks, testing schedule, supporting environment and platform to be used for testing and all the technical detail about software testing. It is very important for you to participate in all project reviews. Do NOT wait until coding phase to start working on your test cases. You must start writing test cases at the same time developers start their design then add more details when more information is available.. You must learn how to use defect tracking tools (Bug tracking tool) and be able to write a defect status report (Bug report).
It may seems like a lot but there are more things that you will have to learn in the software industry to advance your career. Please keep a positive attitude and remember that you are still learning as your professional career is only just begun.
