Do or Do
Tools to Test Ecommerce Website
Both sides of life!
Great people often can change a defect into an asset by turning a problem around. Hamming explains at Bell Labs he wasn’t given the required human staff to write programs for the computers. Other companies would readily give him staff, but he felt the “exciting people were at Bell Labs.” From this limitation came his insight that the machines might be able to write programs themselves, which forced him into the field of automatic programming very early. If he had the ideal working conditions he initially desired, he might never have had this insight.
When you couldn’t do a problem, started to study why not. And from this came the interesting discovery. “Ideal working conditions are very strange. The ones you want aren’t always the best ones for you.”
Good flow of setting up Selenium Web driver.
Current process: The typical questions were “What tech do you know?” “Do you know these tools?” and not much more than that. If someone got along with the interviewer and his answers had been adequate or better, the company would extend an offer.
My observation: I looked at the good testers around me and tried to identify the “whys” of their success. All of them were driven to learn and capable of adapting to change. If they didn’t know a tool or a tech, they learned it. Because under the hood, testing is learning and relearning software everyday. The following are seven changes I made to my interviewing process.
Change One: Stop Asking Tech and Tool Questions First
It’s much more important to find the right mentality. My first interview is now mostly personality based. Followed by, how would you test this, where this’is a generic thing— like a vending machine, a trash bin, or a telephone. I leave it generic enough to encourage the person to start out with questions. The best testers ask lots of questions instead of diving into examples of how they would test, questions like “How much time do I have?” “What resources do I have?” “What is the goal of this testing?” and on and on and on. Good testers are capable of assuming what kind of this it is and break the problem down into good examples of high-level test design and low-level test specifics.
Change Two: Never Rely on Just Yourself to Interview People
You can be biased and ignore glaring errors that others spot. You might have an off day. Maybe you and this person just mesh and you don’t finish your due diligence, consciously or unconsciously.
Change Three: Write a Job Description, Not a Person Description
Testers are a very diverse bunch; what you want someone to accomplish in a job position can be accomplished many different ways. You don’t know ahead of time what specific skills that will require, but you do know what goals you want accomplished by this person in three-to-six-to-twelve months (don’t you?). I’ve found some of my best testers from all walks of life: ex-Microsofters, HVAC repairmen, high-school drop-outs, and mechanical engineers. Figure out what the job description should be and don’t assume what skills you need to get the job accomplished.
Change Four: Put Them In a Stressful Situation
Testing is stressful; your job is to prove to people how ugly their baby is. Give them to a test a small website and find their “most important” bug.
Change Five: Retrospect, Reflect, and Improve!
Finally, keep a record of the people you interview and when. Did they get a second interview? Why? Did they make it past the second interview? Why? Did you make them an offer? Did they accept? How did they do after they’ve been there three-to-four months? Can you make changes to the way you interview to weed out the people who didn’t work out in three-to-four months? Or to isolate the people that are doing awesome after three-to-four months? Interviewing is not a static exercise; don’t treat it as such.