Software Testing Advice for Novice Testers

Novice testers have many questions about software testing and the actual work that they are going to perform.  As novice testers, you should be aware of certain facts in the software testing profession.

The tips below will certainly help to advance you in your software-testing career.  These ‘testing truths’ are applicable to and helpful for experienced testing professionals as well.  Apply each and every testing truth mentioned below in your career and you will never regret what you do.

Know Your Application
Don’t start testing without understanding the requirements.  If you test without knowledge of the requirements, you will not be able to determine if a program is functioning as designed and you will not be able to tell if required functionality is missing.  Clear knowledge of requirements, before starting testing, is a must for any tester.

Know Your Domain
As I have said many times, you should acquire a thorough knowledge of the domain on which you are working.  Knowing the domain will help you suggest good bug solutions.  Your test manager will appreciate your suggestions if you have valid points to make.  Don’t stop by only logging the bug.  Provide solutions as well.  Good domain knowledge will also help you to design better test cases with maximum test coverage.  For more guidance on acquiring domain knowledge, read this post.

No Assumptions In Testing
Don’t start testing with the assumption that there will be no errors.  As a tester, you should always be looking for errors.

Learn New Technologies
No doubt, old testing techniques still play a vital role in day-to-day testing, but try to introduce new testing procedures that work for you.  Don’t rely on book knowledge.  Be practical. Your new testing ideas may work amazingly for you.

You Can’t Guarantee a Bug-Free Application
No matter how much testing you perform, you can’t guarantee a 100% bug-free application.  There are some constraints that may force your team to advance a product to the next level, knowing some common or low priority issues remain. Try to explore as many bugs as you can, but prioritize your efforts on basic and crucial functions.  Put your best efforts doing good work.

Think Like An End User
This is my top piece of advice.  Don’t think only of a technical guy.  Think like customers or end users.  Also, always think beyond your end users.  Test your application as an end user.  Think how an end user will be using your application.  Technical plus end user thinking will assure that your application is user-friendly and will pass acceptance tests easily.  This was the first advice to me from my test manager when I was a novice tester.

100% Test Coverage Is Not Possible
Don’t obsess about 100% test coverage.  There are millions of inputs and test combinations that are simply impossible to cover.  Use techniques like boundary value analysis and equivalence partitioning testing to limit your test cases to manageable sizes.

Build Good Relations With Developers
As a tester, you communicate with many other team members, especially developers. There are many situations where tester and developer may not agree on certain points.  It will take your skill to handle such situations without harming a good relationship with the developer.  If you are wrong, admit it.  If you are right, be diplomatic.  Don’t take it personally.  After all, it is a profession, and you both want a good product.

Learn From Mistakes
As a novice, you will make mistakes.  If you don’t make mistakes, you are not testing hard enough!  You will learn things as you get experience.  Use these mistakes as your learning experience.  Try not to repeat the same mistakes.  It hurts when the client files any bug in an application tested by you.  It is definitely an embracing situation for you and cannot be avoided.  However, don’t beat yourself up.  Find the root cause of the failure. Try to find out why you didn’t find that bug, and avoid the same mistake in the future.  If required, change some testing procedures you are following.

Don’t Underestimate Yourself if Some of Your bugs Are Not Fixed
Some testers have assumptions that all bugs logged by them should get fixed.  It is a good point to a certain level but you must be flexible according to the situation.  All bugs may or may not be fixed.  Management can defer bugs to fix later as some bugs have low priority, low severity or no time to fix.  Over time you will also learn which bugs can be deferred until the next release.  Read an article on ‘How to get all your bugs resolved‘.

Over To You:
If you are an experienced tester, what advice do you like to give to novice testers?


93 thoughts on “Software Testing Advice for Novice Testers”

  1. Stubs – stubs r the dummy modules tht simulates the low level modules.

    Drivers- drivers r the dummy modules tht simulate the high level modules.

  2. Hi,
    I work for a company doing some basic testing with Mercury Loadrunner of web applications. I want to be a QA tester. Is there any particular language I should learn or book to get certified. I live in the U.S.A.

  3. what are the Qualities needed by a software tester?

    A software tester must have intent of showing the product is not working as specified.
    Software tester have the basic attitude of showing the presence of errors. He must have perspective of customers i.e he has to use the system as he is the client of the system. He has to strive for the quality.
    1)He/she must observe the problem from both the side say user and programmer.
    2)Must has good under standing with other team members .
    3)Able to understand programmers view.
    4)Once start testing, do not put it remain.
    5)First test requirements of the user.
    6)Before start testing first analysis the project like ;
    technology using in project, all the flow etc……

  4. Really it is very useful for the beginners.
    I want to ask u a question
    that i have an experience of 11 months but some times m not able to under stand the functionality & some technical points

  5. What is software ‘quality’?
    Quality software is reasonably bug-free, delivered on time and within budget, meets requirements and/or expectations, and is maintainable. However, quality is obviously a subjective term. It will depend on who the ‘customer’ is and their overall influence in the scheme of things. A wide-angle view of the ‘customers’ of a software development project might include end-users, customer acceptance testers, customer contract officers, customer management, the development organization’s management/accountants/testers/salespeople, future software maintenance engineers, stockholders, magazine columnists, etc. Each type of ‘customer’ will have their own slant on ‘quality’ – the accounting department might define quality in terms of profits while an end-user might define quality as user-friendly and bug-free.

  6. We need Test Scripts because of the following points:

    Acceptance testing is a complex and painstaking process that requires great attention to detail in order to ensure that the software is adequately exercised and that it meets the original requirements.
    The objective of testing is to answer a binary decision: does the system pass the test or not. To make that decision there must be a defined result that must be achieved for each specified test ; and for the overall system there is usually an acceptance level defined in the contract which defines what number of individual failures may be acceptable.
    To decide whether a test has been passed, there must be clear criteria that it must meet. This may be a value or set of values to be displayed on a screen, some results printed out, some specific changes in a database etc. In some cases it will be easy to check that the necessary result has been achieved (e.g. a picture on a screen) in other cases an extra action might be required (e.g. printing out the before and after state of a database record).

    In order for overall testing to be accurately carried out, there will usually be a need to set up base data – perhaps by conversion of some existing computer data. Where this data can be set up and manipulated by the system it would be usual to use the system to do so – in fact to define the set up process as part of the overall test sequence.

    To ensure that the correct steps are carried out, and in the correct sequence, it is important to put the process in writing. Where the sequence of the tests is important, for example where one sets up data for another, it is particularly important to have a defined “running order”.

    The function of the test script is to define what input should be made to the system, and what output should be received. Usually the output will simply be text or perhaps a graphic on a workstation screen, sometimes there may be a printed report of some nature. A formal script defines (or identifies) several things:

    Any data which should pre-exist and on which this test will rely, which may have been input by an earlier step in the script or crated by an entirely separate process – this data may be data held in the computer memory, a simple data file or a set of records in a database;
    The steps that must be taken to run the test – for example keyboard input. This may of course be quite complex like filling in a long form defining a ship and its cargo capacity/facilities.
    Any data that is created by the test, with steps to take to check that it has been properly created. In some instances this will be the next step in the test sequence, in others it will require the use of a separate piece of software to (say) examine a database.
    The “pass” criteria which will be applied to the test.

    A most important criterion for a test script is that it must be repeatable. Provided the environment is set up correctly, the test should produce the same result each time it is executed. But please note the dependence on the environment – usually data but potentially other factors as well such as computer or network configuration.

    There is a risk of “false negatives”, i.e. tests said to have been deemed to have failed but where the failure is due to extraneous errors. For example, there was an error in the script and the “pass” criteria was not obtainable, there was a mistake in typing in data (say a wrong selection of “yes” or “no” – simple but devastating) or required pre-set data did not exist (the tests had been run out of sequence). It is of course also possible to make a mistake in the “pass” criteria – hence the script is faulty not the system.
    All “failed” tests should be investigated to establish a reason for failure. Because of the complexity of testing, in many cases it is a “false negative”, and the root cause needs to be identified so that the test can be re-run properly. Occasionally investigations will indicate a “false positive” from another test, which had apparently passed but the system had failed to carry out some action or other during that test on which this test depended. Whilst the result might be still one test that failed (albeit a different one) it may affect the classification of the failure (and hence overall acceptability). On the other hand it may again simply be that the test script for that test failed to ensure that the action was carried out – i.e. a script error not a system error. There are then a string of tests to be repeated, or if time is not available, discounted.

  7. When to stop Testing
    One of the most difficult questions out of the field of software testing is: “When is a good point to bring the test to an end, and are you ever through?” There are several reasons why it is difficult to find a good answer. Once more psychology plays an important role, especially if the ending condition is defined before the tests are started. Furthermore it can be assumed that — if the program is not very tiny — there is always one more bug. In other words, it is basically impossible to write a bigger, faultless program. A rule of thumb that can be used is that you should not stop testing as long as you keep finding bugs fairly regularly. On the other hand, if you never start selling your product, you will sooner or later run out of business. So despite the danger of an image loss due to annoying faults of your program which you did not find, you have to start marketing your product.
    These considerations lead to the most likely common and nevertheless absolutely senseless ending condition: testing ends after a certain period of time has elapsed. In other words, the tests end on a fixed date. The uselessness of this condition is buried in the human’s purposeful behavior. A tester will normally not do his best if he gets a goal like “test n days” or “test until you cannot find any bugs anymore”. Those conditions share a similar weakness. For instance, given the last one, the tester will unintentionally run tests which are less likely to detect a bug, instead of doing good, intelligent, and destructive tests.

    A better goal would be “find n faults”, but even though it is far away from perfect, it contains the following risk: How do you find a good approximation for n? If it is too low, several mistakes will not be found; and if it is too high, psychological problems have to be faced again. If the tester gets the feeling that he is unable to fulfill the given goal, he will get frustrated, and the quality of his tests will drop significantly.

    Most likely, the best way out of this dilemma is to commit an external institution with the tests’ implementation. This step has several advantages like a healthy and productive rivalry, increased motivation on both sides, a reduced influence of the developers on the testers, normally a higher qualification of the testers, and the constraint to write a better documentation about everything done.

  8. hai Mr Rajesh
    I am fresher in software testing field. I have been learning “How to test software requirements specification?”,but i don’t have mature idea.how to use your method to application?

  9. BULLSHIT!!!! you don’t know anything anout testing. I don’t envy to your employer and pray no to use product tested by YOU with your advices.

  10. Testing is the part of sdlc. you can use every cases in project.i per my advise you can think user.
    software is not 100% bugs free.

  11. hi ,
    i am doing job in International BPO but i want to build my career in S/w testing as my qualification background is B.E(CSE).so can any one suggest me the right way …..

    thanx

  12. hi Vijay,
    We the Novice testers pay u a sincere gratitude 4 all ur Testing Stuff that u provide us with full of heart.It’s really an appreciating help that u did 4 all of us.Me being a Novice in Testing has become a good Testing professional with these stuff.
    I sincerely say that u deserve the name VIJAY, go head with this Man.

    Thanks

  13. i should appreciate Mr Rajesh for his simple & elaborative definations….very gud sir..
    i am fresh engg …currently studing software testing from SEED INFOTECH,thane..
    i would like to know the list of websites or any link from where i can search recent testing jobs for freshers….
    i do have 6 months exp ,,but that is wid POWER sector..
    i worked their in R&D dept ..but after some days i realise dat i was jus focusng on job an not on Career ..
    so i left the job & decided to opt for SOFTWARE TESTING..
    plz sugst me abt this sector & how efficiently i can search for job..
    u mail also mail me on saurabh.thawali10@gmail.com
    or msg me on 09960403850..i’ll call u guys………

    regards,
    SAURABH (zed)

  14. hi sunny,

    if u have done B.E (CSE) then why are u wasting ur time wid BPO…come out of shell man……
    join some certificatn course for s/f testing ,,if u are intrested…
    career on this platform is promising…
    evn i hve done B.E & joined the same recently…
    bbye..

    saurabh thawali.

    (zed)

  15. Hi Vijay,
    I m a fresher in testing field working with a MNC i am getting docs on testing related topics but want to elaborate my knowledge more so can u plz suggest me sum f the sites related to testing and sum tips which can help me in my work
    if possible contact me on shashwatsingh87@gmail.com

  16. I am a fresher in testing and I have some queries -Is it necessary to have some coding knowledge to be a good tester? if yes which is most common scripting language tester preffer.

  17. Hi
    I am fresher in testing and working in small organization as manual tester. there is no any senior to me. So I cant measure my work and cant find way how to improve to be a good tester. If u pls see how I work (here I am mentioning in brief), I think u can suggest me something helpful. I write test cases only for failed testcases. I first run the testcases thinking in my mind and when it find failed then write it with prority,status, in nsame report (My report contains fields as srno., object, steps, actual result, expected result, pass/fail, prority, Developer’s status(done /not done/rejected/postponed/enhancement), Developer’s comment, Tester’s status(new/open/reopen/close)) .I cant understand what is the use of writing testcases which are passed. Pls give me ur advoice how can improve my skill, which scripting language should i learn?

  18. hi vijay,
    I want an advice, I have a break of 4yrs as i was outside the country and gradually taking care of my kid. Now i again want to pursue in testing, earlier i had 1year of experience in good mnc company. What should i do as my resume only doesnot get shortlisted , last year i did my isqtb certification also , please help me

  19. Hi, to all
    This is very interesting & informational article for all novice testers, especially for me. Am doing my B.Tech (III) and want to be a tester because having training in manual testing from CETPA Infotech Pvt.Ltd. Send some information for projects to be tested.

    Thanks & regards
    Akanksha

  20. I am very new to software testing, I have worked in a company for nearly 7 months. I have confusion towards knowledge that I should acquire. Till now I have done only manual testing:- Functional, Usability, Compatibility. My question is shall I go for learning some automated testing tool right now or shall I keep my self pushing into this areas more and more so that I make my base strong. I will really appreciate, If any one can guide me how should I design my career in testing, i.e what to do , when to do and things that I should not do.

  21. Hi ,

    To every readers of the site…

    * If u need to prove urself to be a good tester,u should have a “Test to break attitude”.if u mention tis in ur resume it ll attract the selector of the interviwer.

    @ preeti

    hi dude,

    First u should have a thorough knowledge on manual testing.. which is hard when compared to automation,
    so 1ce u think tat u r strong in manual , next u can move on to the automation & u ll feel easier to learn it.

    thank u for the post vijay.

  22. Great article, very clear and interesting – thank you

    does anyone have experience of testing MS sharepoint 2010? I am interested in how you went about it and an idea of your findings – I see that you wil need to simplify a lot

  23. how The administrator identifies a trainee. The system displays the title and date of any training session for which the trainee is reserved, along with the name and training management qualifications of the training manager who made the reservationto write an acceptance tasks for such use case::

  24. hi
    it is an excellent guide lines given to all the novice and experianced testers.
    its very important even the Sr.software engineers dont know much about as u thought above
    its great. Thanku

  25. im new to testing …i have been working as a tester for 3 months. and i didnt have any experience before this also. but learned something in 3 months,, ur points was very useful to me ,,, thank you very much..

  26. I am working with a software testing company, but my job is not directly related to testing. What I am willing to know that I am 29 years of age now, and I want to switch towards software testing. Will it be beneficial for me to switch now?

  27. This is really great,I have learned a great deal here
    Thanks sir for your Awesome work
    more grace to you sir Vijay.

  28. Hi Vijay,

    I am working as software tester for past 2 years, Naturally am very passionate in testing after seeing your blog I started to love my profession. Really thanks for that :)

    I have one question most of your post you asked to learn new testing techniques, I dunno what is it meant by will you please explain me breifly on that and what are the testing technique are there to follow if possible ??

    Thanks
    Brinda

Leave a Comment