As a Software Tester you might have faced a situation where the deadline to release a product/module is close and you have been asked to deliver your report in ‘n’ days.
To accomplish the goal of delivering a bug free project you need Planning, Effort, and a considerable team size so that the major things that needs to be covered during the testing can be accommodated. Allocating the components to different members in your team might reduce the total effort to half. Basically, when projects get delayed, the time decided for testing also get squeezed, but we do not have to panic at that moment. If we keep complaining about the rescheduled testing time, then we would be wasting our time instead of thinking something productive. Anyone working on a software project is familiar with the various reasons for delay during the process of software development. We can say that delays are the part of Software Development (which is not documented in the books or the Internet).
Facing a tight schedule for testing, we have to make the best use of the time and the team available with us. We could start with identifying the areas where the user base would be negligible. Considering a criterion we can lay down the sequence with which we will be going to proceed the testing. Risk Analysis is an important part here. You can identify the areas which are critical, important from the end user’s perspective and important for the stakeholders.
You can create a checklist in order to remind the major functionalities, which must not be missed while performing the testing. I have listed some of the points that can be helpful for a software tester in a tight testing schedule.
- Cover the functionalities where the number of users is going to hit the most (You may confirm the same with developers, or fetch a report if tracking codes are used in the site).
- Check the components which will be often used by a user (That may be a Login, Search etc.).
- Any module which is important from the standpoint of Stakeholders.
- Cover the major risky areas that can stop the show, as they can get affected due to a bug (ex: Payment Transaction gateway).
- The areas with the financial impact on the users (and hence on the project stakeholders).
- Any new functionality which has been developed and delivered to testers recently. This area may result in the area with the highest number of bug count.
- Any functionality that has been created in a rush from the developers.
- Any functionality that had recent bug fixes (Regression should be done very carefully during this period, as there is a chance that a new bug might have entered in the system while fixing the previous bugs).
- Functionalities which are more important for the stakeholders (Sometime a current release may contain a functionality whose results are important for the clients to decide how they are going to proceed further in the project?
- If you have an experience of working on a similar kind of functionality then you can apply the same scenarios to see if there is any major flaw.
- Check the functionalities which are mostly reported by the end user to the customer support.
- Automation can also help you cover the multiple functionalities and flows with lesser resources used and in minimal time.
All the above-mentioned points are not part and parcel of a testing schedule, but it covers quite a lot of important areas that usually needs attention.
You may also like: Is Software testing a Challenging job?
image credit: lifehack.org
