“Hey, What do you think of my skills as a tester?” That seems a question that we never ask our peers who are our team mates. Similarly, we never ask our peers for their opinion of our debugging or troubleshooting skills; most often, the practice is to wait till the end of the year and mostly tend to disagree with your manager during the reviews. I think that at least at the end of every assignment or project, it is very important for a tester to reach out to his peers and ask them for their feedback on his testing skills; someone might give him feedback on how he prioritizes bugs, or how there is no connection between the bug title and bug description, or about their inability to reproduce the bug with the steps that he’s provided, or even about test coverage and so on. But still, it is only when you reach out to your peers that you will get accurate feedback on your skills, and you will need to validate that feedback before deciding if you should fix them or ignore them; that activity should be a frequent pit stop as you plan to scale the testing mountain.

These days, there are so many of testing institutions that is after you; the only USP offered by most of them is the so-called security of job placement at the end of training. And most of them have a tie up with top companies; at the end of the course, the training institute arranges for interviews with top service based companies for the candidates (even if there are no openings available). What most candidates don’t realize is that even if there are no openings available, top companies interview them and say that they did not find anyone available. This boosts up the hiring quality of top companies since they claim to their vendors that only 1 in 300 applicants would get a job offer there; not knowing about the number of openings available, the candidate thinks that he has a valid opportunity to land a job and takes up the interview and the tests. And the institution washes off their hands saying that they arranged for interviews, which the candidate could not clear. This scam seems to be super-prevalent these days.

Here is my set of pre-requisites on what you need to do before you go and take up a testing course, and what questions you would need to ask them while enrolling for the course; You need to identify who you are, where you are at and what you want.

Who you are

It is possible that you are very passionate about testing; it is possible that you just want an entry to software due to personal commitments. You might want to get into testing to join the dream company. You might want to join software since you want money for your personal hobby. Write a one-pager document on who you are and what you want to do in your life. Read the document that you created so that you know who you are.

Where you are at

1) Take any software application that comes to mind; (android app for email, Facebook website, Google search, etc.). Use your own common sense to write the test cases and test scenarios on a piece of paper; once you think you have completed it, asks your friend to review it for you and give his comments. Incorporate those review comments and update your set of test cases or scenarios.

2) After you are done with the 1st exercise, do the same exercise with a 2nd, 3rd and 4th set of applications with a 2nd, 3rd and 4th set of people. Ask for feedback, comments from your peers and experienced people on the set of test scenarios. Incorporate their feedback comments and create an updated set of test scenarios. Re-visit the earlier set of test scenarios, look at patterns from missing test scenarios and add the missing patterns to the 1st set of test scenarios.

3) Take any open piece of software and test it; write a simple document on your understanding of the technology behind it, your understanding of open bugs, your understanding of what you perceive to be defects but they are not defects, and your understanding of feature enhancements that you would have to suggest. Do this along a peer group and ask for their feedback on your reports. Also reach out for any tester online on this set of reports; understand their feedback; that will help your ability to focus your testing in the right direction.

4) Pick up any non-software object; like a clock, pen, your car speedometer or whatever. Think about how you would test that item and document your test scenarios. Constant documentation improves your test case writing skills, defect reporting skills and it will help you improve your ability to write effective bug reports and test cases with the minutest of detail available.

Automation anyone?

Yes; many testing institutions tell you that they will be able to help your automation abilities. For most of them, automation is either Selenium or QTP; Challenge it. You have so much of online courses that you will be able to learn QTP within a few weeks; look online and get a mentor for yourself and try to write a simple QTP script that will help you login and logout of Facebook. As always, get it peer reviewed and incorporate those suggestions in your test scripts.

Doing this exercise will help you understand where you are at with respect to testing and writing test reports; it will also give you the ability to achieve “constant learning”. It will help you understand your speed of learning and aid you to become self-sufficient; remember that in life, you will be able to succeed only if you are self-sufficient. And you will understand your learning speed.

And non-functional testing?

Yes; Google for “non-functional testing” and a zillion links pop-up. If you spend 3 days on it, you will know what they are talking about and create your own repository around non-functional testing;

Why Peer Feedback?

What I want to point above over here is that peer feedback is a very important tool for learning; it is not used to maximize advantage. Think about it, if you are dependent on the opinion of your peer on if your shoe looks good on you, if the latest James Bond flick is worth a watch, if Barrack Obama is worth being voted to power and so on, why do we ignore asking them for their feedback on our skills? Peer feedback is mostly ignored the world over; asking for this feedback also creates a wonderful and open atmosphere for us to provide feedback to them, and for us to listen to their feedback and evaluate it objectively and become better at the craft.

At the end of all of the above exercises, create a simple dossier that includes your test cases and test scenarios, your bug reports, your effective understanding of the technology, your set of automation testing scripts, your understanding of non-functional reports; Give this to the institution where you are going to be learning testing from and tell them, that’s WHERE YOU ARE AT.

What do you want?

Ask them to evaluate your writings; and ask them to give you a report on what they will be able to teach you and how your reports will be different if you attend their testing courses. Read the report that you get (if they give one), and evaluate it; having spent some time in learning software testing, you would be in a position to know WHAT YOU REALLY WANT from the testing course.

Now, you will know if you need to join this course in this specific institution or not. If you are reading this line, then I would really expect that you do this exercise before you join any testing course. If I were a testing institution, then I would ask my students to do these exercises before I evaluate them and let them know if they should join my testing course.

And before I sign off, God is meeting me for dinner next month. And I am looking forward to it. What did I talk to God? About what did God talk to me? All of that in the next chapter. Time for me to say “Oh My Goddddddd”.

 

Fake Software TesterA Fake Tester's DiaryFake Tester,Fake Tester's Diary'Hey, What do you think of my skills as a tester?' That seems a question that we never ask our peers who are our team mates. Similarly, we never ask our peers for their opinion of our debugging or troubleshooting skills; most often, the practice is to wait till...