• info@helpingtesters.com
  • helpingtesters

Tight deadlines and Last-minute Testing

last-minute testing

In today’s article, we will discuss some points a testing team / QA / tester can adopt for the last-minute testing or when there is not enough time to perform the complete testing activity. 

As per the software development lifecycle rule, the development and testing ratio is 60 / 40. If you are an experienced tester / QA you must have faced the last-minute testing situation in which the development team takes more time than the estimated timeline. Or you are engaged in so many project meetings that your time dedicated for testing is compromised and just for the sake of meeting the client’s deadline the testers do exploratory testing or execute only the main business scenarios that should work in that particular release.

With the ongoing growth in the software industry and especially with the introduction of Agile methodology, the deployments and release cycles have become smaller and pretty quick and are often occurring weekly or bi-weekly or sometimes even daily builds are being pushed.

Approaches to overcome last-minute testing

Here are some approaches a tester should use to overcome the last-minute testing situation.

1.      Create Automated test scripts

Automating testing has now become a necessity for every project. May it is in any environment, a desktop application, a web-based or a mobile-based application, every client demands to have automated testing scripts created as part of the project. Whether they are backend API scripts, UI automation scripts or mobile app scripts, they will definitely save a lot of time of the testers when they need to test for last-minute releases.

With the increasing demand and with the shortage of testing time, test automation should be done by the testing team.  

Being a test lead, you should always plan and include test automation time in providing testing estimates. A projects which requires regression testing (a testing in which bugs are verified after getting fixed and their impact is monitored on other parts of the system) to be done too often, or has large set of data to be input every time to execute a test case, or a project having short deployment cycles demands creation.

2.      Create test plan

One of the must-have documents every project should include is the creation of a test plan, which also acts as proof for testing estimation. This helps in overcoming the last-minute testing situation to the greater extent. This does not only benefit the testing team but the client, project manager and even the development team, in short, it stands out to facilitate all the stakeholders.

A standard IEEE test plan format includes eight steps to be followed which are:

i.      Analyze the product

Being a tester you need to know the complete inside out of your application so all the areas are thoroughly tested and the delivered product is a quality bug-free product. Analyze all the requirements and do the brainstorming session with the assigned team on that project. Define all the possible test cases and their output.

ii.      Design the Test Strategy

This is made by the test manager. Testing in scope and out of scope items are defined i.e. on which operating systems, browsers, devices the application will be supported and on which the application will not be supported. Testing types are defined, it can be multiple for example if it’s a banking application so special hardware and software integration testing, installation testing and security testing need to be carried out. If there is any risk involved in the testing phase that is documented along with the bugs

iii.      Define the Test Objectives

This phase ensures the defined scope items are met and thoroughly tested and now no bugs exist in the delivered product.

iv.      Define Test Criteria

The test team also needs to define some benchmarks against which actual test results will be compared. How much pass and fail percentage of test cases will be considered the application stability. And at what point the testing team will say the testing has been completed on the basis of this set of test case execution.

v.      Resource Planning

It includes human and machine resources that will be utilized on the application. Define the entire team structure from top to bottom including the project managers, design and front-end user interface team, development team, SQA team, network and all other resources which will be required in the successful completion of the project.

System resources are the physical application, database and web servers, any additional tools installation (an automation tool or a load testing tool) internet connection, additional system requirements etc.

vi.      Plan Test Environment

Test environment is a testing server dedicated for the QA team. All the test cases and core testing is done on this server and the developer can meanwhile continue development on a development server.

vii.      Schedule & Estimation

The time required by each team member of the application is defined here. The application tasks are divided and the estimated effort is defined. 

viii.      Determine Test Deliverables

This includes defining and creation of all the test documents which include test design document, test cases, test plans, test data, test scripts, bug reports and release notes.

3.      Manage individual testing / Staging environment

The testing environment is the separate setup on a separate server of the project under development. The testing team should always be provided with a separate server so that testing is not disturbed. If both the testing and development teams use the same server and the developer keeps on deploying code and database changes, the testing will be affected.

The testing server is considered to be a copy of staging server. If all the code works fine on the testing server then the code is deployed to staging. Also if any bug is found on the staging server it can easily be replicated without affecting client’s data on the QA server.

Make sure your team has a separate server to ease testing and bug identification.

4.      Create user acceptance testing checklist

This is the first thing you should plan to do while the application is under development. This can be shared with the client too so he/she has the knowledge that these QA scenarios are executed and passed by the QA team and there will be no error in them. 

In Agile, the user stories actually contain the acceptance criteria separately for each story which makes it easier for the QA team to maintain a checklist.

5.      Create prior sample test data

If your application has an upload control that needs to be tested. You can prepare the sample data prior to testing. For example, you can create/download large excel file having 100 MB size or a video/audio file having 100 MB or even larger size. If you are short of testing time and your sample data is already available, then during last-minute testing you can directly execute the test cases.

I always make a separate Sample files folder on my system having all type of files PNG, JPG, GIF, DOC, DOCX, PPT, PPTX, TXT, 0KB file, a big name file, a file having all special characters in the name, an exact allowed size file and so many more. This does not only help me, it also helped my fellow team members. 

6.      Beta test your application

 Beta testing is done by the client in his environment, but here what I mean is you can make your organization a client-based environment. Before launching it on clients end, deploy the application on all the systems of your organization and ask all the colleagues to use and provide feedback on the application. This way your application is tested in a live environment and you will get to hear different types of suggestions/ issues from all type of people

This approach should only opt if you are following a well-defined timeline and you have enough testing time available. This can also be done if you have a week ahead of the deadline. I would suggest this approach to be followed if you particularly are building and testing a client-server application. In this way, you can check how your application is behaving under load and fix all the loopholes prior to giving it to the client. Real-time and large-scale applications are usually tested this way.

7.      Test main business functions having an impact

If you have a day to test the application you must test the areas which are committed being delivered in the build, they should work without breaking any flow or impacting other areas of the application. So make sure you have your test cases written with a priority of 1 and they are executed and passed.

When the application demo is presented to the client he himself is interested in seeing the execution of its main business requirements first. Verify, validate and make sure they work smoothly and as required by the client.

8.      Brute cause Analysis (BCA)

This technique can be done when there is more than one tester in the team. This is a brainstorming technique in which if a bug is found by one tester, other one analyzes all other areas of the application which can be impacted by this bug. If you are running out of time and at the last-minute testing stage, so you work as a team and test the application.

As this technique requires to be tested in conjunction, I would recommend this when you have at least 2 to 3 days of testing timeline.

How to handle high severity bug before deployment

There can be times the QA team finds out a bug having a large impact on the application is scheduled to go live. This makes the situation critical for the entire team, the developers, QAs, managers and if the issue is very high its impact reaches top management too. So what should be the responsibility of the QA in such a situation?

  1. First, the important thing is not to panic and not to make the team panic.
  2. Report the issue with all the steps to reproduce and high severity
  3. If the issue persists earlier and was not identified by the QA team, accept your mistake and be nice to the development team. They might point out fingers towards you but sooner or later the issue will be identified and that is what should be important for everyone.
  4. The issue fixing priority will be decided by the client. Inform the client about the issue and its impact, if he agrees to deploy the build with the issue, go for it and if he asks to fix it first and then deploy the release then make sure the issue is fixed as soon as possible and thoroughly tested.
  5. Sometimes when the client gets angry and does not agree on deploying the release with the bug, involve your top managers, who can calm down the client and buy some time.

So these were some of the points which a testing team can follow when running out of time and are at the last-minute testing stage.  Let me know what other options you have used in such situation, and how was your last-minute testing successful.

About the author

Aisha Mazhar author

Leave a Reply

Your email address will not be published.

Recent Posts