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.

Software Testing Advice for Novice Testers

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 into 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 about 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?

Recommended Reading

93 thoughts on “Software Testing Advice for Novice Testers”

  1. All the things that you mention is true, take both condition valid and invalid.while testing think to break the application so are good to find out the bugs.

    A test engineer should have a high level of thinking, what the application suppose to do or what he is not suppose to do.

    Thanks for your support.

  2. I have a point for the Novice testers …Your mantra should be “Quality ” this should be ur attitude towards u r work .No matter what domain and what extend be Diplomatic and try admit ur self in the user’s place then u will know what are errors can occur …u cant measure everything happens as it is,u should …..1.What is the objective of the project 2.What are u going to test 3..How are u going to test..4.What is the outcome of the testing …5.u should be thinking in positive way as well as Negative way ,if u think like this then u can shine in ur life as a Quality person …

  3. This article is not only good for starters, it’s also well applicable to the experienced testers. I really enjoyed it. My contribution is that , as a tester aiming at finding defects in order to improve the quality of the product, You have to be open minded and positive. Be inquisitive enough and always ask yrself various questions about how best the software can be while not deviating from the requirements…cheers!

  4. Tip 1. Use all existing resources e.g. requirements documentation, design documents, help files, closed and currently open bugs, discussions with other testers/ developers to build your knowledge of the application under test.

    Tip 2. Instead of focussing on finding severe bugs only, focus on the number of bugs. Many efficient test methods could provide you a good number of bugs for the time you put in testing. Out of all the bugs that you find, there will undoubtedly be some gems and your team would be thankful to you for finding those bugs.

    Tip 3. Think about the causes of bugs that you find or others find. If possible, get some of this knowledge from the developers. Once you have an understanding of the common causes of bugs, you would be able to focus more on the problem areas of the application.

  5. Tip 4. If another tester finds a good bug, congratulate that person and if possible, get that person to share the method or the though process he/ she used that resulted in the discovery of the bug. This way, you could build up your own set of test methods.

    Tip 5. Remember, it takes time to develop expertise in any profession. Be patient when faced with problems or when frustrated.

    Wish you good testing experience!

  6. My advice for new testers not to ignore a single bug no matter how big or small, because later if other team member discover it you’ll regret that you didn’t log it.
    even it was an extra space you should give it enough care

  7. Thanks Mr. Vijay for all your extreme knowledge about testing. It gives me way to do much better in testing efforts. I am very new in this field. I am non science graduate. You pls send me all your valuable views at my mail id i.e.
    Once again thanks for your regard views.

  8. Hi , i am new to testing course. Thanks for letting me know of what to be concentrated in testing. Its of great help. Once again appreciating all ur efforts. keep it up.

  9. Good advice from readers too!

    Some excellent tips from Inder P Singh . But Inder I am disagree with you on your point no.2

    “Tip 2. Instead of focussing on finding severe bugs only, focus on the number of bugs.”

    If I am testing an application I will try to find and log all possible bugs in application. May be small or severe bugs.
    The count doesn’t matter for me. What I will focus on is test coverage and a bug free application.

  10. Hello
    Nicely compiled
    My advice is to foucs on positive scenario first and then approach towards negative test cases.
    Chances are there you may miss out some positive scenario in the race of finding bugs following negative approach.


  11. My advice to testers: define a list of test ideas and test des you will be sure you have not missed any requirement aneply for each point of the list. Doing thid case.
    You may have test cases and scenarios defined by your test analyst but there is no guarantee that they completely cover all cases system can work/break.

    And think about automating some of you tests…


  12. I’m sorry… my previous post should look like this:

    ” My advice to testers: define a list of test ideas and test and test deeply for each point of the list. Doing thies you will be sure you have not missed any requirement and case.
    You may have test cases and scenarios defined by your test analyst but there is no guarantee that they completely cover all cases system can work/break.

  13. @Vijay,

    Thanks for the nudge! My Tip 2 definitely needs clarification and additional information. It should not be taken verbatim. The final intent of this tip is to develop quality bugs. Let me explain how.

    1. The tester may choose to log every bug the moment it is discovered. I would not prefer to do so. Instead, I would hold the bugs for some time and analyze them. This analysis might result in finding that a) Multiple problems are not separate bugs but manifestations of a single bug e.g. a single bug found in multiple test environments. b) A problem is not a bug by itself but simply the symptom of a bigger bug. I would prefer to log the bugs only after proper analysis.

    2. While testing and after discovering some bugs, it is possible for the tester to become a little complacent. In my opinion, the tester should stay dissatisfied with the bugs found thus far. This invokes the thought process about the tests not yet conducted, any regression bugs that might be open etc.

    If the tester continues to think and put in effort to discover more and more problems and analyze all the discovered problems properly, the tester should end up with good quality bugs. The tester should not focus on bug count, per se but on discovering more and more problems.

    Inder P Singh

  14. Good discussion between the expert bolgers and Mr. Vijay. Very informative for freshers.

    As I am a software test engineer, the points discussed above are quite close to software testing in real environment.

    What my suggestions for the novice tester:

    1) Always try to be a good listener as tester should devlop the habit of listening from the initial stage to understaned the projects more deeply.

    2) Don’t be in hurry to log the bugs, unless you understand the whole procedure.

    3) Always develop a good relationship with the developers, as we are appointed to point out mistakes from what they have developed, sometimes there may be clashes between a developer and tester regarding the work ( as developer gets frustated on seeing the long list of bugs. To develop the code is easy than fixing the bug which is somewhat difficult for them).

    4) If you are working in a team as a novice tester try to discuss between yourselves as how to improve testing skills , you will get to learn many things from the experienced testers.

    5) Don’t try to hide your mistakes, accept it gracefully it will help you to develop your testing skills in future .

    Be good tester, and have patience.

  15. hi am novice to a fresher and no project experiance till going to start my first project next month.i want some tips to get success in that project.I have to prepare test plan also.The requirement document is of 70 pages,so tell me the areas of requirement doc where i have to concentrate to write a test plan.

  16. @Inder P Singh
    Right, Bug count should not be the final aim and major of tester’s performance.

    Point no. 2 is good.
    “Don’t be in hurry to log the bugs, unless you understand the whole procedure.”

    If you log all the bugs along the way you will end up getting most of them marked as invalid. Troubleshoot and go to root cause to know whether the bug symptom is a bug or just a beginning of another major problem. Don’t forget to note down all steps to reproduce bug symptoms, finally this will help you write good bug report.

    Read the requirement doc carefully and understand the business logic. This will help you to visualize complete picture of final product. You will get clear idea of testing time required for each module, resource allocation, test schedule, risks associated and major modules to be tested. What remain will be just fitting your requirements in standard test plan.

    For sample test plan and test plan guidance see posts on:

  17. Some really good points in this list. I think the point about “100% Test Coverage Is Not Possible” is a very important one. I would extend this to say that it is important to set realistic, clear, and achievable goals for both the team and yourself. 100% coverage isn’t possible but setting your goals (perhaps coverage related) helps to keep the team motivated even if they know they can’t test everything.

    The other point I think is very important is that I believe it is helpful to also look for positives in the software. What I mean by this is that quite often in software testing we are about being critical and pointing out mistakes. It can help lift both the test teams and the development teams moral if the testers point out good things about the software here and there as well as the bad things. Give credit where it is due.

  18. Hi Vijay,

    Recently I had been to an interview and encounted to a new term hard error and soft error.

    They have asked me the difference between Hard and soft error.

    If u have the ans. pls reply for the thread.


  19. Hr Mail ids Use this ids for post resumes. badami@local.equra

  20. hai Mr Rajesh
    I am fresher in software testing field.I have just an idea about software testing and i comleted CSTP at Cochin.I would like to work and I want a experience in both manul automation testing

  21. ACCEPTANCE TESTING. Testing to verify a product meets customer specified requirements. A customer usually does this type of testing on a product that is developed externally.

    BLACK BOX TESTING. Testing without knowledge of the internal workings of the item being tested. Tests are usually functional.

    COMPATIBILITY TESTING. Testing to ensure compatibility of an application or Web site with different browsers, OSs, and hardware platforms. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite.

    CONFORMANCE TESTING. Verifying implementation conformance to industry standards. Producing tests for the behavior of an implementation to be sure it provides the portability, interoperability, and/or compatibility a standard defines.

    FUNCTIONAL TESTING. Validating an application or Web site conforms to its specifications and correctly performs all its required functions. This entails a series of tests which perform a feature by feature validation of behavior, using a wide range of normal and erroneous input data. This can involve testing of the product’s user interface, APIs, database management, security, installation, networking, etcF testing can be performed on an automated or manual basis using black box or white box methodologies.

    INTEGRATION TESTING. Testing in which modules are combined and tested as a group. Modules are typically code modules, individual applications, client and server applications on a network, etc. Integration Testing follows unit testing and precedes system testing.

    LOAD TESTING. Load testing is a generic term covering Performance Testing and Stress Testing.

    PERFORMANCE TESTING. Performance testing can be applied to understand your application or WWW site’s scalability, or to benchmark the performance in an environment of third party products such as servers and middleware for potential purchase. This sort of testing is particularly useful to identify performance bottlenecks in high use applications. Performance testing generally involves an automated test suite as this allows easy simulation of a variety of normal, peak, and exceptional load conditions.

    REGRESSION TESTING. Similar in scope to a functional test, a regression test allows a consistent, repeatable validation of each new release of a product or Web site. Such testing ensures reported product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process. Though regression testing can be performed manually an automated test suite is often used to reduce the time and resources needed to perform the required testing.

    SMOKE TESTING. A quick-and-dirty test that the major functions of a piece of software work without bothering with finer details. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

    STRESS TESTING. Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. A graceful degradation under load leading to non-catastrophic failure is the desired result. Often Stress Testing is performed using the same process as Performance Testing but employing a very high level of simulated load.

    SYSTEM TESTING. Testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.

    UNIT TESTING. Functional and reliability testing in an Engineering environment. Producing tests for the behavior of components of a product to ensure their correct behavior prior to system integration.

    WHITE BOX TESTING. Testing based on an analysis of internal workings and structure of a piece of software. Includes techniques such as Branch Testing and Path Testing. Also known as Structural Testing and Glass Box Testing.
    ?Thanks & Regards,
    R. Rajesh Kumar

  22. Hi All
    I am working on a project in which we are using liferay and alfresco as a database. Applicaton demands that there will be a sign in functionality and that users also saves in mailing list (Lyris using as a mailing list). so whem any user sign in liferay than his name should save in liferay database and at the same time in the mailing list as well in another database so what can be the possible scenarios for Rollback Testing.
    Kindly help as I have to test that both the database gets updated as a person sign in…………………..

    In short what can be the possible scenarios of rollback……….be a most destructive user (think all possible destructive possibilties)

  23. What is dat base testing

    Data bas testing basically include the following.
    1)Data validity testing.
    2)Data Integritity testing
    3)Performance related to data base.
    4)Testing of Procedure,triggers and functions.

    for doing data validity testing you should be good in SQL queries
    For data integrity testing you should know about referintial integrity and different constraint.
    For performance related things you should have idea about the table structure and design.
    for testing Procedure triggers and functions you should be able to understand the same.


  24. Hi All,
    Iam new to this software testing field. Was interesting in it since i completed my graduation .But got a chance to join the testing course this year only.Iam very happy that i found thid article and has given me loy of strength to move on in Testing. I would alwys require your support in this feild.

    Thanks & Regards

  25. hi my dear testing freshers,

    iam suggesting you five steps to become reputed professionals:
    1)Be a certified testing professional from ISTQB or TESTING SCENSE etc.because it brings you respect aznd recognisation too in the organisation
    2)when you are in work environment,be a negative attitude tester.
    3)Be patient and passionate
    4)maintain Good relation with all your team(i mean developers,testers,administrators).
    5)Always treat you as END USER and test the application.

    Thank you

  26. Hi Friends,
    This is Rajesh Kumar
    I am having 2+ yrs of exp in s/w testing…
    I am looking for change. If have any openings for MANUAL TESTING plz inform me

    contact no +91 99 45 40 20 40 (Call before 8’O Clock or after 5’O clock Because in my office not able to pick the phone)

    Thanks N Regards
    R. Rajesh Kumar

  27. hi vijay and friends,
    all the articles in this page are so good. Well am an MCA graduate(2008 passout). i have some testing experience in testing for 5 months in an MNC. Please tell me some testing training institutions which gives sure placement s in this recession times. And i have registered in several job portals for job in testing, but i didnt get any response. Please guide for the further proceedings friends.

  28. hello there.. this is a great thread! i’ve been around the block doing some QA, some dev, and some PMing..

    one thing i think is important to add (although it’s kinda been covered in the thread above), really know the specs of the app that you’re testing, and then pretend you’re a dumb enduser that knows nothing about the internet when testing begins. that’s usually the best way to get started, and when you’re done pretending you’re dumb you’ll find that you understand the app much better and can move onto more advanced tests.

    if you’ve gone through all the PM’s documentation, you can think of that “pretending i’m dumb” phase as a “get to know the app” phase, ’cause really you won’t understand everything from just reading functional specs or statements of work.

    also, for novices and pros, it’s probably a good idea to learn a little bit about usability and just be more aware/critical when you’re surfing around on your own time. what i mean by this is, just say you’re surfing bestbuy’s site.. take note of how their features work, take note of how easy or not easy it is to use their site, take note of how the scoping of the site works too.. like how the left bar is a child of the top nav elements. internet trends are important too for usability.. for example.. 10 years ago left bar and frames were the rage.. nowadays nobody uses the left bar for primary nav as most websites have top navs with left bars as a secondary nav, and.. well, what’s a frame? haha

    you’ll be surprised how developers sometimes just get the job done without thinking about the implementation and how it can be confusing to an end user. there’s nothing wrong with this, since sometimes a developer will be too close to the project and doesn’t have the luxury of stepping back. it’s your job to help them regain their focus all in the name of quality.

  29. A fantastic list.

    I would add: Think outside the box when it comes to the definition of “bug”.

    I remember my first QA project, I was the only tester to read the ‘help page’, which was incorrect, full of typos, and incomplete (string cut off in mid-sentence), not to mention in English regardless of the application language.

    Bugs come in many forms-you’re not just looking for the unlikely crashes, but the embarassingly obvious stuff. ;)

  30. Thanks Mr. Vijay for all your extreme knowledge about testing. It gives me way to do much better in testing efforts. I am very new in this field. You pls send me all your valuable views at my mail id i.e.
    Once again thanks for your regard views.

  31. :)
    (EXP: 3 – 8 Yrs) Testing Track : Senior Software Test Engineer/ Software Test Lead

    (EXP: 1 – 2 Yrs) vSplash Techworks Pvt. Ltd. : Test Engineer – Web based applications.
    (EXP: 4 – 7 YRS) Techmahindra Ltd looking for Senior FPGA Engineer
    (Exp : 7-9 yrs) Test Lead Position @ PCS Technology Ltd.(Mumbai)
    (Exp : 5-7 yrs) Telecom Testing – VOIP Engineer @ Dynpro India P ltd :)

  32. Software Tester must has these qualities—
    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……

  33. A manual tester would typically perform the following steps for manual testing:

    Understand the functionality of program

    Prepare a test environment

    Execute test case(s) manually

    Verify the actual result

    Record the result as Pass or Fail

    Make a summary report of the Pass and Fail test cases

    Publish the report

    Record any new defects uncovered during the test case execution

    There is no complete substitute for manual testing. Manual testing is crucial for testing software applications more thoroughly. Test automation has become a necessity mainly due to shorter deadlines for performing test activities, such as regression testing, performance testing, and load testing.

    ? Rajesh Kumar ?

  34. Hi,i m working in gurgaon from last 3 year.
    really this is very nice site. every article is very interesting and accurate.


Leave a Comment