RSS Feed

5 Excuses Every Software Tester Must Stop Giving

5 Excuses Every Software Tester Must Stop Giving

I have unlocked a pattern from my experience of hiring around hundred testers over a period of time and interviewing some thousand others.

From all the discussions I had with fellow testers during interviews, I felt happy numerous times seeing the quality talent which we have in our community of testers.

But let me also share the other side of the story, the patterns I am talking about. It makes me sad. 

I never feel happy watching potential performers being locked into a virtual cage of responsibilities. I feel discontent seeing the rock stars performing on a controlled stage.

If you are still wondering what’s the matter and what is the baseline, it is this- Considerably big part of our testing community is not having enough growth on multiple fronts for years after they start their career as a Tester. Forget 360 degree, it is not even near half of that.

Sorry for being harsh, but it is real.

Who is to blame for this? Maybe awareness in the industry to some extent. Company policies and senior management too may be. But more than anything else, it is the Tester himself/herself.

Read it again, it is YOU. It is us. Because we become victim to the excuse.

Below are the few patterns/excuses I uncovered.

5 Excuses Every Software Tester Must Stop Giving

Note: I nowhere mean that this is the case with every tester and every organization. But I have seen enough examples to say most of us are victims here.

#1) We don’t control our Test Environment, we have (read ‘very’) limited access

I often hear the statements/excuses- ‘We have just Read-only access to the environment’. Even worst- ‘We only have access to logs and nothing else’.  Everything else is done by either a Development team or some other team.

The work which will give us so many beautiful and fruitful insights about testing and many other technical kinds of stuff is not done by us. And maybe we are happy this way, but we should not.

Tell me one reason why you shouldn’t control your test environment and take maximum benefits of same.

Here are few possible benefits if you are wondering what I am talking about-

  1. You have full control over your test environment to make sure personally that it is exact or near replica of the production environment. This will help you avoid few surprises at least when your deliverables hit production.
  2. You know all involved components, all software used along with their versions for your product to function. With time, trust me you will have many insights about their working, limitations and possible failure points.
  3. You have enough access to do at least first level debugging in case there are Infra level issues. E.g.: Setup running slow, Checking CPU, Memory utilization and logs at every level of flow are no rocket science.
  4. You own control over setup, so you know what you are changing and what build you are deploying. You are much more confident than before while shipping the release ahead.
  5. You learn it and you learn it all. Though it is Linux based or Windows based.

Makes sense? Let me continue if you have at least agreed that there are benefits.

Now the question is what change you can make in your team/organization to make this work. And how exactly you will do it.

Well, I Don’t Know. I don’t know your team, your leads/managers, and your organization so I won’t be able to help you on this. I can surely share few things which might work. You try working very closely with your Dev or whichever team owning this and see what and how they do stuff. Everything.

The way they login to the environment (server), the way they logout and everything in between. Once you gain some knowledge, you will have the confidence to say few words, give some suggestions when a similar situation occurs again or if a similar activity is to be done again.

Obviously sooner or later your this confidence will be seen by your developers/leads/managers. That is the time you can ask for the control. And tell me one strong reason why they won’t give you that? They should be more than happy to do so if you have shown the needed capabilities.

Believe me, they have much more work to do, so it shouldn’t be hard for them to release the control to you. At least I hope so.

#2) We don’t deploy a build, some other team does it for us

You come to office on a Monday morning. You notice there are few issues in build causing blocker. You need new build from your Build repository. You raise request or contact your Dev team or deployment team. Ohh, they are busy with something. But they manage and do it after some time.

Now tell me, why all this? It is not as complex as it looks.

When to take a new build is surely something a Developer can suggest as he is the one who will be committing a feature or a bug fix. But when you simply need to trigger it and deploy it, why should you wait or depend on someone.

Having ability and authority to deploy whenever you want makes your work lot easier without any wait. Do you see that? It will also increase your Turnaround time in daily testing. Though it is debugging some defect with added logger, or taking the new build to verify resolved bugs. Or be it taking fresh build and starting with testing of a new feature.

Let me tell you something from my personal experience. It is not only about time. Deployment teaches you so many things that you can’t imagine. The reason is, it fails often. The application stops working with new code sometimes. Many times deployment itself fails. And every time something fails, it pushes you to debug it. It pushes you to search for something on Google or ask someone a question or the best ask yourself a question.

It makes you think.

Of course, it is not really a software testing, but it surely is testing your abilities.

I will say a large portion of my learning apart from pure software testing are from Deployment and Maintenance of environments.

  • I don’t remember how many trial and error attempts I performed for something, count must be few hundred.
  • I don’t remember how many times I went to check some release manual of some software.
  • And I don’t remember how many times I hit that Google search button or navigated to that stack overflow link.

All I know is- it gave me a lot, taught me a lot.

The remedy for this is very similar to the first excuse we talked about.

Learn it, show it and ask for it. It might work.

#3) We don’t debug an issue, we find steps and log it

I won’t go very hard on this as in an interview you don’t get a chance every time to discuss particular defect from candidate’s own experience and investigation/debugging done by him/her.

However, I can surely say that not all of us challenge our senses before passing on the defect to the developer.

Many times the log says it all. Many times the pattern of an issue says it all. Many times it fails because some prerequisite service was down.

So in short, many times it is actually possible for us to get to the exact root cause or at least reach near it.

So please ask yourself a few questions, not for helping developer but for making your test cycles fast and for your own growth.

You are the remedy here. No one else.

#4) I don’t know why it happened. Developer resolved it and I simply verified it

Ohh, come on. Sorry but hearing this annoys me a lot.

Every single time, it annoys me when I ask Tester a question- Why particular defect was faced or what was the RCA (Root Cause Analysis) and he/she answers ‘I don’t know’.

Have we taken Black box word this literally? How can we not ask Developer about what exactly he fixed? Why can’t we ask it if the authority is an issue?

I am damn sure that 99% times we don’t know the Root Cause Analysis (RCA) or fix because we don’t ask for it.

Believe me, knowing the exact fix, module in which fix was done, whether it was in the front end or back end, whether it was injected in any feature development or some other defect’s fix, will always help you in your testing. Always.

Apart from this, this information helps you know a lot of technical stuff which may be otherwise you will never come across.

Remedy? Ask it. Demand it. Whichever works.

#5) I didn’t get the opportunity to work on anything else than Manual Testing

Maybe this excuse is valid to some extent considering the possible workload on you or restricted responsibilities given, but not completely valid.

The problem here is, we say that we didn’t get the opportunity to perform non-functional types of testing, or we are not supposed to do it or we don’t have time.

Agreed, learning always demands time. But isn’t there anything you can change?

While testing that new feature or while testing that one API,

  • Isn’t it possible for you to keep watch on the response time?
  • Isn’t it possible that you ask your Business Analyst about the load this particular feature/module/API is expected to handle in production so that you can test it?
  • Isn’t it possible to perform at least basic security checks like session expiry, URL tampering or XSS handling on that website form you are supposed to test?
  • Isn’t it possible to at least say that this particular ‘Submit’ or ‘Help’  button doesn’t seem to be properly located or not easily noticeable and play your small role in making the product more usable?
  • Isn’t it possible for you to start with something and then keep learning it more and more?

The answer is YES, small or big depending on various factors surrounding you but it is surely not NO.

If your responsibility doesn’t demand it (because there is some other team for it), no one will stop you investing extra time for your own learning. Self-learning in extra or free time is always possible I think. So find those possible extras, and start doing it. Now.


I hope I triggered some thought process and some learning ambitions within you.

Please forgive if you found any of my words harsh, but believe me, I wanted to be 100% clear so that it reach out to you all with needed seriousness.

Hope it works positively for you all.

I will be more than happy to know any uncovered aspect around possibilities I talked about.

7 Important Points You Should Remember About Virtual Objects

Posted on

1. A group of virtual objects that is stored in the Virtual Object Manager under a descriptive name is known as virtual object collection.

2. Virtual objects for analog or low-level recording are not supported by QuickTest.

3. Recognition of virtual objects can be disabled without deleting them from the Virtual Object Manager.

4. Virtual objects can only be used when recording and running a test. Any type of checkpoint on a virtual object cannot be inserted.

5. The virtual object collections shown in the Virtual Object Manager are stored on your computer and not with the tests that include virtual object steps. This means that if you use a virtual object in a test step, the object will be recognized during the run session only if it is run on a computer containing the appropriate virtual object definition. To copy your virtual object collection definitions to another computer, copy the contents of your \dat\VoTemplate folder (or individual .vot collection files within this folder) to the same folder on the destination computer.

6. Virtual objects can only be defined for objects on which you can click or double-click and that record a Click or DblClick step. Otherwise, the virtual object is ignored. For example, if you define a virtual object over the WinList object, the Select operation is recorded, and the virtual object is ignored.

7. You cannot use the Object Spy to view the properties of Virtual objects.

How to add object repository in qtp

Posted on

How to add object repository in qtp

Hi friends, I got very good response from you on my previous post “object repository in qtp”. So today also I am going to give you some advance knowledge in context to object repository in QTP.
I am going to teach you two following things in context to object repository.

1. How to add object repository in qtp manually.
2. How to add or load object repository in qtp during runtime.

Procedure to add object repository in qtp manually

1. Go to Edit->Action->Action Properties window.
2. Than switch to “Associated Repositories” Tab.
3. Click on “+” sign.
4. Now click on right most side button and add object repository file (in .tsr format)

Procedure to add object repository in qtp during run time:

Just write following lines of code in your script.

Dim qtApp

Set qtApp = CreateObject(“QuickTest.Application”)

qtApp.Test.Actions(1).ObjectRepositories.Add “C:\Repository1.tsr”

Note: Above script will add “Repository1.tsr” file to your test during run time. Please note that this object repository file will be loaded during run time so you can see it attached only during run time. During stop mode you will not be able to see attached object repository.

If you want to verify that object repository is added or not during runtime you can verify. When your script is in running mode just Go to Debug->Pause and then you can verify by going to Edit->Action->Action Properties and then associated repository tab.

Agile Testing Mindset And The Role Of The Agile Tester!!

Posted on

Agile tester in an agile team plays a very important role towards the end product quality testing. He or she should be able to collaborate well within the agile team members and other project’s stakeholders. In order to collaborate well with the team members, the tester is expected to have an agile mindset in terms of testing skills and other quality assurance activities that a tester should perform as being a part of the agile team.

Agile Testing Mindset:

To play a role of agile tester, the tester should have the Agile testing mindset which will help him to break free from the traditional project methodologies such as SDLC, V model, waterfall etc. In order to develop the correct mindset, the agile tester should possess the following characteristics.

  • Prevention is better than cure”. An agile tester should be focused on preventing defects rather than finding defects.
  • An agile tester should provide the Quality Assistance over the Quality Assurance.
  • An agile tester should not believe in enough testing but should believe in the continuous testing approach instead of starting testing at the last moment.
  • An agile tester should not play as an individual player but the agile team player and should work closely with the whole team in collaboration.
  • Responsibility wise in agile testing mindset, it should be team responsibility instead of an individual tester responsibility.
  • Testing focus should be on automation rather than manual testing when it comes to regression.
  • An agile tester should prefer the Exploratory Testing over the Scripted Testing approach.
  • It is not SDLC methodology therefore; agile user stories from product owner should be used for customer requirement gathering over the traditional requirements specification.
  • When it comes to web testing, the focus should be on Technical, API Testing and GUI Testing in order to ensure complete end to end testing.
  • The mindset of an agile tester is to make sure that the software is built correctly instead of breaking the software like Monkey testing.
  • An agile testing approach does not wait for the testing phase to start therefore, with the agile mindset the tester should be involved into testing as early as possible.
  • An agile testing approach does not require providing the detailed testing report after the end of testing instead Short Feedback helps the team to get the idea that they are building the software in the right direction. This approach gives lots of time to fix the defect if it is identified in the early stage as a short feedback.

After all it is “Attitude that makes the altitude”. Therefore, if a tester has the above Agile testing mindset then definitely he or she is a perfect fit to the project’s agile team.

Role Of The Agile Tester:

So far, we have discussed about the agile testing mindset, now let’s grill on the various roles of the agile tester. An agile tester is responsible for the following roles.

  • First of all, an agile tester should comply with the agile project methodology i.e. the active participation in daily standup meetings, joining session based on the grooming on user stories, retrospectivesteam meetings, continuous improvement suggestion to make the process the best.
  • Active collaboration with the agile team which involves the developers, business stakeholders, etc. which may help in making the requirements on the product functionality crystal clear and help the testing team to widen the scope of testability.
  • Clear understanding of the agile testing strategy at the project level.
  • Close working with the product owner in order to capture the acceptance criteria which will later evolve into the acceptance tests.
  • Measurement of the overall test coverage that the acceptance tests cover.
  • Well versed with the use and implementation of the automation testing tool in order to help in the regression testing.
  • Setting up of the test environments, test data for functional and the volume testing and the maintenance of the existing test cases and scenarios.
  • Execution and the development of the automation test scripts to automate the acceptance tests.
  • Preparing the test report and sending the report across the agile team. So that the team isinformed about the defect and the testing progress on the current product.
  • If as an agile tester you are leading a team then it comes under your role to coach or train the testing team so that they can collaborate well in the current testing expedition.
  • An agile tester should help in testing sign off from the stakeholders for the project release and should also participate in iteration planning for the product testing.


An agile tester should not forget that though it is working in collaboration with the developers as an agile team but still he or she is a tester and should comply with testing roles and health online pharmacy without prescription responsibility with the appropriate testing mindsets. A tester failed to follow the above roles and responsibilities may result in insufficient testing and hence the failed software end product.

The following could be the risk to the organization with the agile testing methodologies.

  • As we know, testers work in collaboration with the development team then it may happen that they lose their testing mindset and start thinking as a developer. Both has different mindset should follow their assigned responsibilities in order to develop the correct software product.
  • Being a tester, one should not hesitate to escalate inappropriate or ineffective practices within the team. No matter whether the tester is collaborating in the best way with the developer, the incorrect thing which cannot be made correct and therefore, should be discussed in the Daily scrum meetings.
  • In agile methodologies, the sprint is of the short duration. The small sprint may sometime result in sparing very less time for tester to test the developed product in the current sprint or to run the complete regression.

All the above risks should be well discussed with the agile team as a part of the daily meeting.

Over to you:

In this article, we have discussed about the various roles and the agile mindset that an agile tester should possess in order to become an asset to the agile team.

QTP Tutorial – Using Virtual Objects and Recovery Scenarios in QTP Tests

Posted on

Virtual Objects in QTP

Do you see Object not found error while running QTP tests? Well, this is because during playback QTP can’t recognize non-standard objects. To solve this object recognition problem we use Virtual Objects. Using Virtual Object Wizard we can map these unrecognized objects to standard class which then can be used as standard object to record the test.

How to solve object recognition problem in QTP?

Example of Virtual Object:
Here is a scenario: I am recording a test on a Microsoft word document. I activate the already opened MS word doc and I click on any of the icons in the top menu. For example, I click on “Format Painter”. The code that gets recorded into QTP is:

1 Window("Microsoft Word").WinObject("NetUIHWND").Click 132,120
2 Window("Microsoft Word").WinObject("NetUIHWND").Click 672,101

In cases like this we would go for a virtual object. By definition, a virtual object is an object that is recognized by QTP as non-standard but is instructed explicitly by the tester to behave like a standard object.

Virtual Object Wizard Steps:

Step #1) Go to the menu option “Tools->Virtual Objects-> New Virtual Object” and click “Next” in the following window.

Before you hit “Next” take a minute the read what this wizard will do.

Virtual Objects

Step #2) Here you will find a list of classes. You can choose any class depending on how the object in your application is behaving like. In our case, the “Format Painter” Icon is more like a button. So I am going to choose “Button” from the list.

Virtual Objects

Step #3) In this screen you can mark the screen where the object is on your AUT. Click “Mark Object” and choose the object from your AUT.

Virtual Objects

Step #4) The width and height values for the marked object will be populated once the selection is made. Hit “Next”

Virtual Objects

Step #5) You can now configure the way in which you would want the selected object to be recognized with reference to its parent. As you can see, you have a choice to see identify it based on its parent alone or the entire hierarchy. I am just going to keep the default values and click “Next”

Virtual Objects

Step #6) Give your virtual object a name and add it to a collection (nothing but a consolidated list of Virtual objects). I keep the default  values and click “Finish”

Virtual Objects

This completes the process for creation of a Virtual object.

Step #7) Go to “Tools->Virtual Objects->Virtual Object Manager”. Here you can see all the collections that are available and the objects within them.

Virtual Objects

Clicking on “New” will take you back to the creation process that we have just seen. You can delete a collection using the “Delete” button.

Once you are done creating the virtual object, repeat the recording process on your AUT for the same object. This is how the code looks:

1 Window("Microsoft


Now you will be able to perform all the operations on this VirtualButton that you can on a standard button object.

A few points to note:

1) This feature is not available for Analog and low level recording modes.

2) From the example you can see that the virtual object completely relies on the width and height factors, so it is not highly reliable.

3) To disable QTP from recognizing the virtual objects while recording, choose the option “Disable recognition of virtual objects while recording’ under “Tools->Options->General”.

Virtual Objects

Recovery Scenario in QTP

At times when you are trying to login to your Gmail account, assume a pop-up window comes up and you will be asked to confirm your security information. This does not happen every time you login. If your test is to login to Gmail account and as soon as you enter the user ID, password, hit the Sign In button and if your QTP test is expecting to arrive at your inbox your test is going to fail if the security information screen comes up randomly.

To handle cases like this we use the ‘Recovery Scenarios”.

Steps to create Recovery Scenario in QTP:


Step #1) Go to “Resources -> Recovery scenario manager” , click on the “New Scenario” icon.

Recovery scenario

Step #2) Click Next

Recovery scenario

Step #3) The trigger for this to start could be one of the following options. Choose according to your scenario. In our case I will choose, Pop-up window. The other options are self explanatory.

Recovery scenario

Step #4) Using the “Pointed hand” option, choose the window that you would want to add.

Recovery scenario

Step #5) Define the recovery option by clicking on the “Next” icon below:

Recovery scenario

Step #6) Choose one from the list. I am going to choose “Keyword or mouse operation”. The options in this screen are really easy to understand. So choose accordingly.

Recovery scenario

Step #7) I am going to go with the default settings and click Next. The recovery operation gets added to the list. If you need to add more than one recovery operation you can keep the corresponding checkbox checked and click Next. It will take you back to the screen in Step number: 5. Or if you are done, you can simply uncheck the checkbox and click on “Next”. That is what I am going to do.

Recovery scenario

Step #8) Now you will have to define the post recovery operations.  All the options are as their names indicate. I am going to choose “Proceed to next step”. Click Next

Recovery scenario

Step #9) Enter the scenario name, description and click Next

Recovery scenario

Step #10) It provides a gist of your scenario. As you can see, there are 3 parts to a recovery scenario. The Trigger, Recovery operation and post recovery operations. You can choose to add this scenario to the current test or to all tests by choosing the relevant checkboxes. I am going to keep them unchecked at this point because I want to show how a tester can associate them to a test explicitly. Click “Finish”

Recovery scenario

Step #11) The scenario we just created will appear in the list. Save and close.

Recovery scenario

Step #12) Associating the recovery scenario. Open a test, in the “Resources” pane, right click on “Associated Recovery scenarios”, right click and choose “Associate recovery scenario”. Browse for the scenario and click “Add Scenario”. The chosen scenario will appear in the list in the Resources pane.

Recovery scenario

Step #13) Also, you can go to “File->Settings->Recovery” and add the scenarios you would like. Here you can also choose the options as to how often you would like it to run. You can choose to run it, On Error, On Every Step or Never.

Step #14) The extension for a recovery scenario file is “.qrs”

This concludes our discussion on Virtual Objects and Recovery scenarios. I would recommend the tester to use various combinations of Trigger, Recovery and post recovery operations when practicing the recovery scenarios.

%d bloggers like this: