• Author
  • #2973

    Getting into the testing field was a natural progressing for some, but for others it is a complete career change. I’m sure there are some common pitfalls that most testers will encounter during their early testing career that they wish they had avoided.

    My question to you is, what advice would you give to a first time tester? It could be something simple like “drink lots of coffee” to something practical like “Make sure you document every bug you find” .

    I’m curious to see what advice you can share..


    1- Learn the V-Model. Whilst not everyone thinks about it, it is the basis for just about all modern SDLC’s. And most interviewers will look for this in engineers
    2- Think analytically. A good tester doesn’t just check that what they are testing is does something, the think about how it does it and how it might be used. A lot of systems get used for something other than what they were conceived to do. e.g. a SharePoint portal being used to run the logistics for a large scale organisation, allocating tasks and a lot more.
    3- Have fun with your work. If your having fun your doing a good job.
    4- Be diplomatic when you find a bug. Every one makes mistakes. Your not there to stomp on a dream, your there to help a dream comes true.
    5- Get to know your developeUrs and your customers. You need good friendly relations with both.
    6- Pick up a little phycology. A good tester will get in the heads of the end user when testing and the heads of developers when reporting defects
    7- Be prepared to be shut down when you are having the most fun. No project can afford to go on and on and if your having to much fun your often going of the reservation. One performance review I had told me that it was good that I was tenacious, and as a negative; I was tenacious. i.e. I wouldn’t get fobbed of, but then again I wouldn’t let it go when it had reached it’s end.
    8- Get online and talk. Get out and talk. Social media and meet ups are great for learning and finding out that the problem you have is not unique and in fact, no matter how green you think you are, you have something to add to the wider testing world.
    9- Find a friendly (nerdy) tester in your organisation and befriend them, the more they talk to you about testing the more you will learn, and get in with the good jobs.
    10- Focus. On the product, the tech specs, the market needs, your scope. It’s easy to get distracted by something shiny in the corner of your eye. That obscure feature/bug. The edge condition. Make sure you know what you are testing and how far you should go. Don’t waste your time and energy on something that nobody is going to be interested in. By all means investigate, but find out the importance and risk before getting to invested in it.

    I’m sure many other people will; have a lot of advice. This is just 10 things of the top of my head. I’ve recruited and spent a lot of time and effort on people who have never touched testing before because they were interested and enthusiastic and learnt the job. I’ve also rejected ‘seasoned’ testers who were obviously not enthusiastic or willing to learn. You have to want to test and want to adapt to be successful.

    Good luck.


    1. Learn to code.
    It doesn’t matter what language you choose initially, as long as you can get your hands on resources to help you learn, and ideally assistance from a friendly developer for when you get stuck.
    If you can give yourself the ability to knock up a quick tool to solve the repetitive tests or troublesome scenarios you need to cover, you’ll have done yourself a big favour.
    2. Find people who have made a career out of testing, and follow them on Twitter.
    Start with Cem Kaner, Brian Marick, James Bach and Michael Bolton, and spread out from there. Read what these folks say, and contribute or discuss things with them.
    And remember – no-one has the absolutely correct answer, and their answers may be right for them and wrong for you. Keep an open mind, and don’t be afraid to disagree if your experience tells you to do so.
    3. Understand context-driven testing.
    The approach you will take to testing might be completely different from job to job. Testing evolves, and often has to fit the industry/company/team you work in, rather than the other way around.
    A successful tester must be able to adapt.
    4. Understand what test automation is for, and what it doesn’t give you.
    A (current) rule of thumb I use is “if you can predict how your application will behave after an action, you can automate it; otherwise, automation isn’t going to help”. (Don’t assume you can’t make some of the unpredictable behaviour predictable, though).
    5. Understand your role.
    You are not there to guarantee a product will work flawlessly. As a tester, you are focusing your efforts in areas of risk to gather information about the presence of issues or problems. You can’t guarantee their absence.


    Get Emphatic
    – with the product u are testing it
    – with the users that are using your product
    – etc.



    1. Don’t take things personally. Coders and those that build within the application that is being tested will get frustrated and may take it out on the tester. It’s nothing personal.
    2. Leave a solid audit trail with regards to defect documentation.
    3. Like Stephen said – have fun.


    first time someone ask me for a some good advice for young at testing (or whatever), I was stuck in the middle of fear and embarassment.
    fear of giving a wrong answer, or worse, a superficial answer. it is a big responsability. embarassment: I’m quite old enough to be the one to ask for.
    since that time, every time I try to give an answer that I would have appreciated when young I need some good advice.

    1. patience, perseverance, diplomacy, savoir faire are the weapons that, as a tester, you have to sharpen day by day
    2. a good knowledge of: theory (that evolves quickly); a lot of methods; some good tool.
    3. make the most of every hands-on experience (even the worst teach something)
    4. never be afraid to experiment and learn (continuos learning is the only way)
    5. have fun (not only with testing)


    Hi Stephen, Andrew, Adina-Valentina, Ron & Marzio,

    You guys made some great points but I couldn’t help but notice that nobody said to get certified. Would certification not be important for first time testers to gain a competitive advantage?


    I guess it depends on the company you want to work for. My experience of the larger companies suggests that certification for a new tester is not important.
    But some companies do advertise a need for certification.

    My own experience: I did sit the ITSQB Foundation, hoping that it would give me that advantage. But for the first few jobs and interviews nobody seemed to notice. It’s only as I progressed further into testing that the roles I could apply for started asking for certification. Even them very few understood the certificate they asked for or asked questions related. The first company that asked questions to confirm your understanding of ISTQB certificate was when I started interviewing. Then we only ask if the person claims they have it. 50% of the time they failed or struggled with basics, like explain/draw the V-Model.

    As a manager who has recruited a lot of testers, certification is unnecessary. After all as a tester I should be able to test the candidates knowledge, experience, aptitude and ability to help support the projects I need them for.


    Hi Andrew

    You mentioned learning to code was a good tip for a new tester. If you had to suggest a language to start with, which one do you think would be the most beneficial?


    Choosing a language depends a lot on what platform the tester is working on and what languages are being used there. My personal opinion is – one can start with any object oriented programming language and learn the basic programming concepts. It will be great if one can master a particular language, then it becomes easy to switch to any language as per need. I have started with C++, but later on learnt JavaScript, some frameworks like Jquery and AngularJS and PHP Laravel framework for server side code. I am on my way to learn NodeJS.

    Now, if someone is working on web apps, then having knowledge on HTML, CSS, client side code (JavaScript) and server side code (NodeJS/ Python/ PHP/ Java) will be helpful. Now, that sounds a lot, but actually they are not if you take baby steps. Grab the basic idea by doing some online interactive tutorials and then move on based on your need. Among the online tutorials my preference is https://www.codeschool.com/, which is a paid one but good one. You can grab a hall pass and keep it for a month if you share it. CodeAcademy is free, but too basic. You can start with it if you are a complete beginner, but don’t think this is enough material to learn. There are plenty of books and many other tutorials out there. There are some problem solving sites as well like Project Euler, Spoj etc. Remember, coding is something that you have to practice, so solve practice problems everyday. Keep an hour at least for coding everyday. After few months you will feel content about learning something new. Now, find out the testing frameworks you need. There are Mocha, Chai, Jasmine for testing JavaScript; BeHat and CodeCeption for PHP. Search and find out what you need. Pick one and learn the use of it.

    In the process of learning coding, you will also learn about data structure and algorithms. It will be great to learn about design pattern as well.

    Summary – pick only one language and start learning and be focused. Do not start leaning many things together. I am listing the points based on my experience, but discuss with your mentor or someone you can follow before deciding the language you will invest your time on. Happy learning!


    You can’t deny the need of manual testing, which require human intuition. We can work on reducing repetitive work and can work on improving efficiency, but can’t just throw it out. It actually is a good thing that saves the product.

    Your first goal should be understanding the project and gaining domain knowledge in any way, reach out to any person to ask question or get clarification if docs are not enough. You must know what is expected before you start testing. It is also very important to make sure all the developers also understand the requirement. Trust me if you can help achieve this, a lot of bugs will be stopped from coming.

    Many people might give you the feeling of being the enemy of developers. My suggestion will be to do the opposite thing. Make friends with them and discuss issues, sit with them to finalize what can be done within the time and what not and do what is best for the product as a team. It might be difficult, but work this goal. In any job, you will have to earn the respect to get heard, testing is no exception.

    Make the best use of issue tracker you are using, I have mostly used Jira. Make filters, save and share them and be always aware of where the project stands now.


    Hi Afreen,

    I haven’t really looked at paid websites for training purposes when there are so many free websites out there. In your experience, do the paid websites have better resources?



    You have started as a tester, congratulations! It’s an adventurerous road ahead and really exciting!

    If I would be again on that situation, here’s some tips and hints what I would do:

    1. Take responsibility and ownership of your learning process. There’s going to be a lot of learning. Everyone learns best in his/her own ways and pace. Be your own best mentor, take your time and stay motivated. Find people you can discuss with of what you have learned, like to learn and listen to what others have learned. Like what you have learned, be inspired even, but do not overestimate your endurance. Take a break and then start learning again!

    2. Learn the product. You cannot test well, if you do not have learned the product, solutions, system under test, group of features, user stories well enough. Learn it from different angles, understand the big picture, the business, the use cases, the details, the implementation, integrations, etc… Start what matters most for the team right now. There’s lot be learned in here, it may take different forms in different contexts, with different roles, people and documentation. You’ll find your way!

    3. Start testing right away. If the application or system is not ready for test yet, think how to test it. Find some resources, learn a bit from book, sites, other colleagues how a similar or any application has been tested. Compare that with your own system or feature under test. Discuss in your mind, with your team, a buddy, a peer, a manager, a coach, how to test what you should test. It will sort out, but start right away in small steps, even the tiny steps a re steps forward.

    4. Find bugs. You know how the product should work and how you could test it, you’re ready to find bugs. Sometimes bugs are easy to find and sometimes extremely difficult. I think finding a bug is something about narrowing your mind with something when you understand the bigger picture. Like looking some detail in the mirror, when you’ve seen yourself appearing in it. You have a predefined picture in your mind, how that detail should look and now you have the chance actually seeing it does it look like as it should or you would like it to look., knowing you as you are. Warning, this might be a very narrow example indeed! A very helpful hint has been to look for a bug taxonomy, or defect classifications, what the real defects could be. Note, it will take time to be very good at finding different sort of bugs, be ready for this. Ask for support, advide, be ready for being educated and give back by providing your hints and tips how to find defects!

    5. Understand your context. What is the company,strategy, product, customer, project, team, process, way of working, culture? What are you aiming at? Why, with what ways, with whom? When things should happen? For whom are you working with? What tools, methods, practices you use with?

    6. Value your work. Every bit of feedback is valuable for the team. Present it as a valuable piece of information. Every question is valuable, sometimes extremely important for the whole team! Ensure your questions are heard, understood and answered. Try mostly to work normal hours, this is to secure the quality of your efforts.

    Good luck, I hope you enjoy your work as much as I do every time I do testing πŸ™‚ !


    If you ever need to test in the field, these tips might help:

    1. Make sure you are comfy. Comfortable clothes and shoes can make any situation more endurable.
    2. Make sure you know something about what awits you. If your field test should happen to include a coupple of nights camping or something like that, make sure you pack and prepare for it.
    3. Pack protein bars. You might not get the opportunity to eat when you are used to. Protein bars and similar, a bottle of water and maybe some candy might help you a long way.
    4. Time manage, time manage, time manage. Field testing might include obstacles like small windows of time where you get to make your tests. Testing “out there” rarely gives the same possibilities to reset and/or restore as you get in a lab.
    5. Easily managed documentation. You might not have access to your test management software, or might not want to lug around a computer. Remember to plan for your needs. The battery of a tablet usually lasts longer than that of a laptop, and a tablet is smaller and more managable (and can be used with a small and simple bluetooth keyboard). Personally I prefer printed lists with my tests and colored highlighters for marking tests as pass/fail.


    Simon `PeterΒ΄ Schrijver, has put in a page on his blog on reply to this topic:


    Ask yourself question: Why I’m doing what I’m doing the way I’m doing πŸ˜€


    -have fun, know your developers and be diplomatic with them (but never trust a developer


    I’ve just written a blog post for new tester. Check out and see if it’s helpful.

    New tester: Stop worrying these things…and you’ll be fine

    The idea of the post is to suggest new testers stop worrying things that do not really matter and how to overcome it.


    Here are wonderful and useful advices for novices and some refreshing infos for regulars as well.
    But are there any websites, books, blogs which your would especially recommend for the person who has just heard about software testing – that such a career exists?



    Over the years I’ve very much found that Testing is more about mindset than skillset…

    I believe a QAer needs to have a:
    * tenacious attitude
    * a level of OCD certainly helps (a simplistic way of saying that, spotting when something looks slightly out of place)
    * a detective mentality – chase down the facts behind the hunch to back it up
    * self confidence combined with a level of humility – self confidence to believe in what you have found and chasing it down to root cause
    * strong inter-personal skills to communicate well with stakeholders/developers etc.

    From an advice perspective
    * CONTINUALLY LEARN!!! – keep abreast of technology movements, domain movements, industry trends (both in QA and business domain).
    * Very effective testers should ideally have both the domain and QA knowledge – Learn in both areas.
    * Try and keep an eye on the big picture… sometimes quick and dirty is what is called for if acceptance of a higher level of risk is appropriate and mandated by the org/project. Sometimes every i needs to be dotted and every t needs to be crossed.
    * Continually tailor & train your “soft skills”, presentation, communication, etc. How to communicate with different organisational roles effectively… the detail & message a CTO/Project Sponsor will expect will be very different to the detail a Developer/DBA will require.

    I have been asked many times “What should I learn/What should I learn next” – This will ALWAYS be context dependent! For the QAers on my team I’m conscious to ensure continuous learning is at the forefronts of their minds and the education is in areas the organisation is moving into or learning to compliment/enhance their current QA domain knowledge.

    I’ll leave it there for now… I could go on. Hope it helps.


    Fortunately there are so many resources, webinars, meetups on software testing what we have always the possibility to learn πŸ™‚ and that’s amazing!
    I, for example, am going to attend the webinar “Testing Transformation in the Era of IoT: Are you prepared?”, on TEST Huddle πŸ™‚


    Advice for first time testers:
    If you don’t feel any passion for testing from the very beginning, stop. And start doing something else. Do what you love.


    Hey @andrei-domuta! That’s totally right that everyone should do what she/he loves! I would only say that it’s good to give yourself a week, two weeks to get immersed into being a tester, to explore few ways, specializations etc.no to give up too early and to have the full perspective πŸ™‚ I do not mean like a year ofc, but just to give more than 3 days to yourself..

    I have some more advices for newbies in testing in form of few links πŸ™‚
    https://dojo.ministryoftesting.com/lessons/the-story-of-a-strange-seed-helena-jeret-mae (becoming the tester coming from totally non-tech perspective) I strongly recommend The Dojo by Ministry of Testing! and theirs Slack team-profile – extra-rapid learning guaranteed πŸ™‚
    https://hbr.org/2014/04/creating-a-culture-of-quality – the broader scope of quality in IT
    http://www.qualitydigest.com/inside/quality-insider-article/creating-culture-quality.html the mission of QAs
    http://testdetective.com/how-to-hire-a-tester/ interesting perspective!
    http://testdetective.com/what-is-agile-testing/ can be also helpful for
    http://www.softwaretestinghelp.com/ in that website is a lot of really helpful, good-quality stuff and advices
    “Test you testing taste!” πŸ˜‰


    Relax. Nobody is born a testing ace. It takes time and work to become good at the testing craft and as long as you are prepared to work hard, you will probably be fine. Noone who knows about testing should expect you to know everything from the start. If you feel insecure about whats expected of you, you should ask your manager.


    2i’s Trainee Tester; Kash, shared what he learned whilst training to be tester. He wrote a piece called ”Things to remember when training to be a Software Tester” which might be helpful to some first time testers! http://2itesting.com/media/blog/5-things-to-remember-when-training-to-be-a-software-tester/

Viewing 25 posts - 1 through 25 (of 25 total)

You must be logged in to reply to this topic.