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.
Sources
- Blogs of Prof. John Vu, Carnegie Mellon University
