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

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.

5ae056503d53a.jpg

  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.

  1. 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.

  1. 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.

  1. 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.

  1. 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 have unlocked a pattern from my experience of hiring around hundred testers over a period of time and interviewing some thousand others. 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. ![5ae056503d53a.jpg](serve/attachment&path=5ae056503d53a.jpg) 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. 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. 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.
edited Apr 25 at 3:58 pm
 
0
reply
28
views
0
replies
1
followers
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft