Advice for the New Tester

When I started testing back in the days, my experience was not very far from what new testers get these days. I had little idea what testing was, was told to 

• look for any and all discrepancies in a test application and 
• report my findings clearly
• limit my work to 1 hour in the classroom where 7 others were doing the same 

I passed whatever criteria they had for my results (in comparison of what they could expect) and my reports, and benefited for the first time in my inability to say no to opportunities. I became a tester, and they paid me for doing more of what I had done for that one unpaid hour.

Over the years, I got more experiences of interviewing for tester positions. I remember one with homework since the recruiting manager spoke later on university testing course I was teaching about statistics he had collected from those exercises, claiming no one knew how to use equivalence class and boundary value analysis technique, and in days I knew less than today, I had deeply studies the simpler forms of those techniques.  Yes, I thought I knew the techniques when I taught at university and when I got the job from that homework and interview, but learned later there's layers I did not understand, thanks to Cem Kaner. 

If you are a new tester these days, your entry to the industry will be both similar and different. You will be chosen, eventually, because people believe in your potential. Your personality and attitude, and skills in learning will matter more than anything else. But unlike my start where a keen eye for seeing problems was sufficient, now the companies are almost certainly going to quiz you on your ability to learning code. It will be unlikely you will sit a "testing exam" in a classroom with other candidates and likely to be sent a test design homework and test automation homework, or the two combined. You might also be sent a programming homework, perhaps an online one with automatic grading. 

My advice to you, dear new tester, split into two parts. 

1. Foot in the door. You got that first position. Now what? This is just the beginning and what you do after matters. 
2. Looking for doors. You don't have that position, knocking needs to start or extend. How to go about that? 

Foot in the Door

Bling. The all familiar Slack message sound and the little red bubble saying someone wants to talk to me. The message explains that they were hired as a tester through a recruiting program, are the first and only tester in the organization. The ask of what they should do is unclear, and they've just been told not to interrupt others doing important work. 

A few messages later, we meet to pair. We look at their application to test over a screen share and discuss what they should do with examples of doing things and finding issues with their application. An hour later they continue their independent path.

A week later they message me again: they received praise about the results they were able to provide in testing. 

Getting that first position isn't the end goal. It is the first step. Now the work starts. Your career, from the first step, is too important to be left for your manager. It's your responsibility and if you are lucky, your manager can help you with whatever you need on those early days. Different managers can help with different things, and some aren't skilled in guiding a new tester but are excellent at recognizing when you find that right thing they want to see you amplify with praise. 

Here's my advice on what you would want to figure out: 

• Center the product, features and quality. Spend time with the application. Sprinkle pieces of documentation but don't try to read up on everything before starting to test. Read while you test. Focus on how the feature can work and see it work. The foundation of your work will be empirical touch. Use it. Spend time on it. "It" can be a user interface or an API, but understand what is supposed to do and confirm you see it do that. Ask yourself why the feature matters, and when you don't know, ask. You will become a product expert when testing, you are not executing someone else's queries only.  
• Make notes. Mindmapping what you have seen, naming and grouping  is a great practice. Collect questions and create a way for you to track what questions you have answers for. Ask questions in conversations you have, and initiate those conversations. Prioritize your questions and seek answers to them in documentation in addition to people, but don't rely only on documentation. Share your learning work (notes) with whoever is tutoring or managing you to invite their ideas. 
• Active inquiry. Using the software will answer some of your questions. Using the version currently in production to compare with the new version will answer other questions - newly introduced issues will be considered more important. Combine sources and pay attention to discrepancies to evolve your critical observational skills. 
• Understand scope. What the user has (application, feature) is one thing. What we are changing now is another. Learn to follow code changes in version control. Also follow agreed change work in an issue tracker your work uses but ground yourself on code. Don't care about the details of code (the devs put all their energy there) but read the name and description developers add to the change they make and understand what they are trying to change. Again, anything that just broke or was just introduced defaults to more valuable information for the developers and product owner as information consumers. 
• Priorities of bugs. Understand what information is considered important by giving information and paying attention to how it is received. Most valuable information of problems results in action - a fix. The likelihood of people wanting to fix come in three flavors: recency (we talked about this), impact on user, and level of issuelessness your project is on. If you can tell the thing you are seeing is bad for someone who matters, we all care, always. And some projects just care about almost everything, but those are rare. When reporting, have conversations on the new things and leave a paper trail (report in your local agreed written practice). Even if they don't fix anything, you will want to show what you're producing when your work is assessed by your manager. This area will change and grow a lot after you have the first hang of it.  
• Vocab, vocab, vocab. Always move around with pen and paper or equivalent. You hear a word you don't know, write it down and if it feels appropriate for the flow of conversation, ask about it. Google it afterwards. Ask about it afterwards. You are acquiring language, you are responsible for your learning and everyone will help. Use whatever tactic for memorizing work for you on central vocabulary. 
• Make space for code. Learning about the application one feature at a time lends itself well for you documenting some of your learnings in test automation. If you read a lot of logs, create something that searches and counts things in the logs. If you have a basic flow you'll tend to check, create test automation for it. Find someone to pair to save a lot of time, or take newbie tutorials and apply what you are learning. Code comes with coding. Resist the temptation of not starting on this. It will matter, if for nothing else your increased understanding of software.
• Invest in learning.  Code isn't your only thing to learn. Create a learning habit. Read and apply ideas. Follow blogs, testers in industry, newsletters, join any slack community. Don't spend too much time there. Sample and apply. 
• Variables all the way. You started with seeing the functionalities work and getting lucky in seeing them not work. Now, turn up the intention: you are successful in testing when your software fails in meaningful ways you can describe. Make it fail. Start thinking in variables - everything you can do differently and turn that up. You did? More. 

You will want to have track record of results in your first 6 months: what did you learn? what did you find? what tasks did you complete? what did you change in how others think? what documentation (incl. automation) you have to show for it? Your first 6 months is to show you can grow.

The years after that are growing in everything. Choosing timeframes of specialization, volunteering for a mix of tasks you can do and ones that stretch you. This never stops. 

Looking for Doors

I started my post with explaining what you do when a door opens and you get your foot in. What if you are still seeking for that door? 

You can start doing everything I explained you do at your first work without the first work. Create a portfolio of the work you are doing. Portfolio of highlights of your notes. Your test designs. Your test automation. Organize it and make it presentable. 

Whenever you have code, have tests. Whenever you don't have automated tests, have notes of tests. When you create code, learn to create a method instead of a comment, for every if remember the else, and think about incorrect inputs as well. 

If you are getting chances at homework exercises, keep your solutions in your portfolio but don't publish them. 

You can also try working to get either paid a little or for learning from others. The first you might do by finding crowdsourcing projects. The latter you might do by volunteering in open source projects. 

The network you are building can be invaluable in finding the right door. Keep knocking. Balance your time and commitments. 

There's an old post going around saying our industry needs smart people. I agree. That blog post suggest smart means reaching out to gurus writing those blog posts, but I would suggest that may be a sign of growing up in a competitive culture or a degree of privilege leading you to trust that trying is better than not trying. Reach out by all means. But first do some homework. They might have already written a blog full of applicable advice. 

Beep. Twitter message arriving points out a specific tweet of mine as an opening to ask about specific concern, briefly explaining their own thinking. They have been searching for a job and they all seem to want programming. 

Instead of conversation in messages, we agree to talk on a call. We talk a bit, and end up in one of my exercises to add an example to what we talk about on level of programming in starting with testing. One exercise turns into a second in a week, and a few more in series. Exercises, conversations, ideas on how to show their strengths.  Knowing them just a little I offer to recommend them and use me as their reference. 

I sit through a reference interview and explain how they have been learning in exercises. They get two offers at same time and choose their position. We meet a few times on supportive tips on succeeding at their work and move to pull scheduling. I've made a friend, and while teaching, I learned a lot myself. 

We need intelligent people in this industry. People shine when they get the support early on, and then run with it. Talent is equally divided, opportunity is not.