Software testing is the process of finding defects in the application and meeting the requirements of end users. Simply saying ‘we do software testing’ does not magically make your software better. For that we need to do it actually in an efficient manner. Here are some tips to do so:
1) Involvement of Testers from beginning: It is a good practice to have testers involved in all stages of the software development life cycle (SDLC). It helps testers meet the requirements of application under test due to which a tester can cover all the possible test cases. It is very important to start testing activities right from the requirement phase to avoid the count of defect in the next phases.
2) Have a good test plan: It is necessary to have a test plan written by an experienced person like a QA lead or manager. While creating a test plan, you need to follow an organized approach to make it a good test plan. A good test plan must cover scope of testing, test objectives, budget limitations, deadlines, test execution schedule, risks identifications and more.
3) How to store documents: It will be good if you store all the requirements, change request documents and reports on a centralized location instead of keeping them in a mailbox. It helps avoid scattering of documents over email and file server. If stored intelligently, it will help us to increase productivity and availability of documents.
4) Test early, test often: It is imperative to start testing software as early as possible. This ensures that the defects can be captured and fixed within the given time-frame. This allows developers to deliver the software to the clients on time. Defects identified in the later phases of SDLC are costly to fix. So the testing process should start early to avoid the multiplication of defects in the later phase.
5) Start writing test cases in the early phases : If you start writing test cases during requirement or design phase of SDLC, then you will understand whether all the requirements are in a testable condition or not. While writing test cases, first consider positive test scenarios which cover the happy path of application under test. After that, you can consider negative test scenarios.
6) Write simple and good test cases: Writing effective test cases is a skill which can be gained by experience and in-depth study of the application. You should write detailed steps in a simple and smart way while writing test cases, so that both developer and tester can understand and reproduce the same cases. If the test cases written are difficult, it will create a problem for both developer and tester.
7) Start testing with positive mindset: When you start testing an application, keep a positive attitude. One that says – “I will definitely get a bug or errors in the code.” You should start testing the application passionately. Always have a positive attitude and don’t assume that there will not be a bug in the code. If you are testing the application with the intention of finding a bug, you will definitely get bugs in the code. At the same time, keep a negative attitude for breaking the code in the application. Try to break the code effectively. Find out what is the major pillar of the application. If you happen to break it, then the whole application will collapse.
8) Divide the functional modules into smaller parts: Application under test should be divided into small functional modules which will help understand the coverage of testing. If possible, make sure that the functional modules are divided into smaller logical parts if possible. Test cases should be written in a single module. There is one testing principle that says “a small number of modules contains most of the defects discovered during pre-release testing or shows the most operational failures.”
9) Easy to available Test cases: The testing team is aware of every scratch of the application under test. When you are writing test cases, make sure that you keep it in a central location where the entire team can access the test cases. If a developer misses any scenario, they can get it by accessing these cases. As an effective test case contains all possible positive/negative scenarios, there would be a very little chance to go wrong.
10) Writing a Defect report will help make your software testing more efficient. How you are writing a defect report represents the skill of a tester. Whatever efforts you put in writing a good defect report will create a good relationship between you and developers. Whenever you write a defect report, try to add all the information properly. Give examples and test data wherever needed. Additional information must be provided along with bug-like browser version, login details if required, environment etc. Defect report should not be too descriptive or too long to read. You can use a proper bug report template for reporting a bug or any defect tracking tool as per requirement.
12) Identify Regression Test cases: Regression testing is the process of testing changes to application to make sure that the application still works with the new changes. If there is any change in environment when a developer fixes defects, you must do a regression testing of your application at least once. To do effective manual regression testing, prepare a set of regression test suit.
13) Increase communication with peers to avoid misunderstandings: Communication is the most important skill for a tester. In the daily meetings, discuss all points which are not clear or need some additional information. Face-to-face communication will resolve problems more easily than any other communication tool. All communications regarding the application should be kept in your email so that you can use it for future reference.
14) Set the timelines: Setting timelines in your work will help you to accomplish your task speedily and easily. Initially, it will take more time to finish your work but it will get easier. If you are finishing your task on time (or before time), you will get more time to do testing without any pressure.
15) Over to You: This tip is intentionally kept blank to share your experience or any point I missed.
References: