To create effective and efficient software tools, your design must undergo a serious testing process. This procedure has to be thorough so that any issues are resolved well before the software’s distribution. Although a comprehensive evaluation is required, there are ways to optimize this task, decrease the effort and make your testing more productive. In this blog, you’ll discover useful techniques to ensure successful outcomes, even if you encounter certain challenges along the way.
One of the first obstacles many testers experience when beginning to work on a real project is the limited time factor. A built-in pressure exists to become familiar with all of the project’s details and organize vital testing within its framework on a very tight deadline. Fortunately, you can take advantage of available methods to streamline your work and accomplish all of your test objectives while meeting any target dates.
Tip Document Security
So let’s say you’ve just joined a project. Within this assignment, you have been provided with a work place, gotten an introduction to a PM and/or a project lead, became acquainted with safety rules and received a project information confidentiality policy. What’s next?
The next step is to create a tip document in which you’ll record all the helpful information on the project and the company. It’s important to note that you need to put together this vital tip document without violating the project information confidentiality policy you’ve already been given. Keep in mind that you shouldn’t just write down information on separate pieces of paper that could be lost, but make a soft copy. If you ask an expert (PM, QA lead or other tester who has already worked on this project) for some information, you may certainly take note of their answers on paper for yourself. But be sure to record this information in the e-document. If safety rules allow, you may save the document to Google Docs, for example, or save it in any other form that makes it available to other users in the company.
Whatever type of document you choose, remember not to record important passwords (i.e. computer passwords, access to project resources, passwords for live databases and servers, etc.) within this file. Otherwise, you could risk compromising your project due to the potential exposure of proprietary information. When in doubt about whether or not certain information may be shown to other members on the team, consult a PM, a project lead or your supervisor. In addition, people who are not involved in the project shouldn’t access any of its data. Therefore, make sure that you do not send your notes to outsiders. If the document isn’t supposed to be shared, just store it on your local work computer. The document format can be any type that’s convenient for you such as a Word, Excel or text file.
Since security is so essential with any tip document, what’s safe to record? Here is a sample list:
- Contact information: You can list the names and contact data (Skype, email, perhaps a service telephone number) of people related to this project. Examples of appropriate individuals include your PM, project lead, other QAs of the project, business analysts, business owners and other representatives of the customers/developers.
- Useful references: Be sure to incorporate links to wiki for the project and to articles that are especially useful for you. You can include test servers, bug tracking or time tracking systems, project version storage systems and test case trackers. Also, don’t forget that if the document is available for shared access, it should not contain personal passwords.
- Guidelines: You may consider having guidelines (or links to them) on how to install a testing environment, how to set up a test server and how to configure useful programs for your work. These guidelines can include methods other coworkers have implemented for certain key tasks. Make sure to write down the specifics because you may have to change a computer, reinstall a system or adjust a work environment at home. By having these notes accessible, you can do the work on your own instead of troubling coworkers every time.
- Useful techniques: Keeping a detailed record of valuable techniques can help you be much more efficient with your time. These approaches may include the testing of your system, important system settings and links to useful auto-tests.
- Other important information: As you move forward with your tasks, you could easily find numerous bits of information that could help you in the future. So during the initial period of your work, record everything you think might be useful while also observing your project information safety rules. If you find that you no longer need these points, you should then delete them.
Don’t worry if the document becomes large. Just make small explanations with key words for the recorded information so that you can easily use the search to find what you need. If you find that you’re lacking certain information, ask other testers or your new coworkers on the project. They may have been recording data that you can also use.
Work Optimization Tips
Now that you have set up your tip document, let’s move forward with the list of work optimization tips.
- As mentioned above, record useful information in a single, easily accessible document. It will save you a great deal of time. When you become acquainted with helpful data, write it down immediately and mark with tags. That way, you’ll easily find it using the search.
- If possible, always try to begin work on a feature or a task before the developer finishes and gives it to you for testing. You may start to prepare test cases, checklists and develop a testing plan in the necessary form. For this part of the process, use the available documents, terms of reference and a description of the functionality in a task tracking or letters from the business owner. The sooner you start working on this objective, the better. It’s ideal to study the task before the developer takes it. When working, you’ll certainly have additional questions. As you present your concerns to a business owner, a PM or a developer, you may find out that the requirements cannot be met or that they contradict other requirements. In fact, you might even find that the task should be postponed until the higher priority problem identified by you is solved. Sometimes the task may be canceled due to the issues you discover. Because of these scenarios, you should ask both the business owner and the developer about how they see the task. In certain circumstances, it can turn out that the developer did not quite understand the job at hand. So it is better for this person to make changes during the development then when many hours/days have already been spent on the implementation of a deliberately wrong functionality.
- It’s highly desirable for you to have your own test environment such as a testing server with a personal database. Perhaps it is worth spending a day to set up an environment locally, to learn how to pick up new versions from the control system and to switch branches and create databases. Although it can seem difficult to make these arrangements, the results will pay off many times over in the future. And make sure to record how you enabled these details to come together within your tip document. If it is not possible due to the fact that other testers, developers, business owners, PMs may be in your test environment, there’s a feasible alternative. Establish a rule to warn people that you are going to enter the environment and explain what you will do in general terms (generate new entities, change the time, etc.) before you start working. Make it a rule to do nothing with test data that is not created by you. However, you should remember that your colleagues may still need this information. Do not change passwords and settings for test user accounts that are accessed by other testers except for yourself. If you want to change the branch in the test environment and/or alter the database, notify all possible users of the environment about this revision. Upon testing, try to return the environment to its original state, set the current time and the original branch back in the database as well.
- When starting to test, don’t forget to clean the cache and cookies in your browser and/or mobile device, which will be used for this process. By taking this step, it will save you from having to reproduce many bugs that the developer could return to you with a “not reproduced” mark. It’s a very simple operation, but somehow this detail is often forgotten. Then a lot of time is spent on analyzing where you’ve found new bugs. Practice to clean up the cache before work until this routine becomes automatic.
- Always test using a clean database ( As long as you are not required to check how the new functionality operates with the real production database. ) Data from the old tests may include errors which are impossible to resolve during production. Therefore, you will have wasted your time examining them and they’ll be returned to you marked “not reproduced” in case you record these issues in bug tracking. You may wonder why these problems arise in the first place. The answer is that they occur when the system state was simulated in order to test other functionalities, causing the time on the server to change. This means you may have gotten the data from the future because the script that would’ve generated data for other tests could have created entities that were unreal for your functionality or contained unreal parameters. Remember that testing that uses a clean database is informative. Testing that utilizes a replica of the real database of the running application is informative, if the replica is new enough. And testing that uses database filled with information generated in the course of other tests is much less reliable. For these reasons, spend ten minutes to create and connect a new database (or re-create the existing one if the information in it is no longer useful for you).
- Always keep a screenshot program running and try to use it as often as possible. You can add screenshots to descriptions of bugs, letters with questions and comments on tasks. When you take screenshots and add them to bugs, you save your time by avoiding long descriptions of the problem. Also, the developer/business owner can then better understand the nature of the bug or question. If your project security policy allows, it is convenient to upload screenshots to the server immediately and send links instead of pictures. This is because the size of the letters may be limited while images have a wider range of acceptable sizes. If links are not allowed, add a picture. In addition, it is possible to record a short video, if you want to show the sequence of your steps. By taking the screenshots after each of your steps and studying them, you may also find additional errors. The advantage is that these discrepancies might not even relate to the changes in your task, but become more visible in the process of viewing each image. Nobody can ever see all the potential inconsistencies at once, especially when the screen contains a lot of elements. But by having such valuable screenshots, you can reduce the number of runs of your test cases, saving time in the long term.
- Though it is very convenient to add a picture, do not omit short descriptions of an error. If you simply add a blank picture to a bug description, the bug will be returned to you marked: “Add steps for reproduction.” Don’t forget that developers use the GUI of your system much less often than testers do. Another tester may quickly understand what button or screen you mean, but it’s best to write down more details for a developer to see what and how you’ve done something to achieve the actual result.
- If there is something that does not meet a certain expectation in the process of testing (an error message, the program returns incorrect values, an expected screen is loaded, etc.), take a picture of the problem immediately and save it. Then try to reproduce the issue. If you cannot recreate the situation, the problem still should be recorded with a note. For example, you can write: “the problem was encountered one out of three runs” and add the most detailed information on how the problem appeared and other circumstances of the test data. If it is possible, provide the developer with access to test data and allow sufficient time for that study. Such “emerging” bugs sometimes happen to get into production and then come back to developers. So it’s better for them to be localized before users and customers start complaining.
- If in the process of testing some feature you have found a medium or high priority bug (not a typing error in the text on the screenshot, but something more serious), then the priority of this functionality’s further testing becomes significantly lower. Since you will have to check it again after the correction, it is quite possible to record the problem and move onto another task, if necessary. However, when there are no other important tasks at the moment, you can continue testing this feature. As always, it’s important to apply common sense.
- After receiving functionality for testing, make sure to perform smoke testing, verifying that you were given an operable version. You should also have a small set of autotests. In this case, you only need a few minutes to find out whether you should start working or return the task to the developer for modification. If you cannot have a set of automatic smoke tests for some reason, write down a list that contains all the necessary checks and quickly perform them manually. Also, if the branch that the developer gave you does not even pass smoke testing, give it back. You should not waste your time since you’ll have to recheck it anyway. It is great when the developer gives a branch for testing, having preliminary run it and received a positive result of automatic smoke testing. If you’ll manage to persuade your PM to arrange the working process in this way (i.e. the criterion for a developer to acknowledge a task as ready for testing is when he wrote all the code he considered necessary to be written and when autotests returned positive results for it), you’ll save a significant amount of time.
- Automated testing is the perfect way to optimize your work. However, it can’t completely replace manual testing and will never be an adequate substitute in the process. But, for example, the so-called semi-automatic tests are very good because they help you make a wide range of checks. In other words, a classic autotest contains a set of procedures simulating the interaction of your system components and checking at key points whether the result of this interaction is correct. The semi-automatic test allows you to set some parameters manually, inputting values when it is performed in order to increase the range of checks. The process can also permit you to bring the system to a certain state and to receive access to it for further manual interactions. You may even take a screenshot that shows how the user sees it in the current state of the system, which enables you to check the interface as well as the result of the operation to use software methods and perform testing manually. In addition, you should be aware that it’s not necessary to automate and save each test case in the storage from beginning to end. This can be a long and redundant process. But you may use ready procedures that simulate certain states of a system that interact with your application. When you use this method, you can do your work faster and better.
Testing software tools can be very complex because of all of the intricate aspects of each project. But if you document wisely and follow the detailed steps outlined in this blog, you can save time and effort without diminishing the results. By optimizing the testing process, you will ensure the software product’s ultimate success.
