Software Testing Basics – A Beginners Guide

The goal of software testing is to find bugs. Doing this supports the delivery of high-quality products that will satisfy the user’s needs. Understanding some of the software testing basics is the first step to take. Software testing benefits the product because testing helps find bugs before customers can discover them in production. In addition, it benefits the company because the sooner issues are found and fixed, the less they cost. If you are new to software testing, you may wonder how to get started with software testing basics. Two of the most important are the Seven Principles of Testing and the Software Testing Life Cycle.

Seven Principles of Testing

Offering a framework for understanding the software testing basics, the International Software Testing Qualifications Board (ISTQB) has defined seven principles of testing, which are:

1. Testing shows the presence of defects, not their absence – The purpose of testing is to find bugs. However, if testing uncovers no bugs, does that mean the program is bug-free? Of course not.
2. Exhaustive testing is impossible – It is not possible, nor a reasonable expectation, to test everything. Testing is an ongoing process, and there will always be another configuration, parameter, or combination to assess. Therefore, test planning is essential.
3. Early testing saves time and money – The potential impact the bug may have lessens the sooner a tester finds a bug. This is especially true if the bug is discovered in the dev or staging environment before the product goes into production.
4. Defects cluster together – The old saying ‘if you see a roach in your house, there are ten more you don’t see’ is equally true with software bugs. They are often found together in a section of trouble-making code.
5. Beware of the pesticide paradox – Test cases need to evolve with the code. Just as pesticides become ineffective to insects over time, running the same tests becomes less effective in finding bugs in developing software.
6. Testing is context-dependent – A government healthcare site will have different requirements than an e-commerce site. The tests needed will be dependent upon the context of the program.
7. Absence-of-errors is a fallacy – If principles 1 and 2 above were untrue, and testers confirmed all defects were resolved and had tested every possible situation, there would still be errors. The program might be too challenging to use, causing the user to become frustrated. Likewise, it could be too easy to use, and the user loses interest. The user might prefer a competitor’s program because of familiarity. Therefore, testing and resolving every possible flaw in a system will still not guarantee a successful product.

Software Testing Life Cycle

Now we know more about what software testing can and cannot do, let’s discuss the Software Testing Life Cycle, another of the software testing basics, to understand the testing process better.

1. Requirement analysis – The QA team will identify what to test and select the testing methods to use during this phase. This phase aims to have acceptance criteria defined, identify types of tests to be executed, and understand the priorities according to stakeholders.
2. Test planning – The Test Planning phase is when the QA begins to document the test plan by considering tools, resources, environments, roles, and responsibilities. Generally, a QA Lead or Manager creates the test plan, decides the approach, and calculates testing timelines.
3. Test case development – Test cases are written based on the requirements and acceptance criteria provided during the development phase. Each test case should include specific details, including steps with expected results. Create automation scripts during this phase, if needed.
4. Test environment setup – The working environment where testing happens is set up and configured according to the test plan. Some products may need a full-time test environment. If so, the tester would consider any browsers/operating systems/hardware configurations required. It might be necessary to create other test environments, and often the DevOps team or developers will provide the work setting. In either situation, QA should perform smoke tests to ensure the environment is ready and create any test data needed.
5. Test execution – Performing tests using manual and automated test cases as required happens in this phase. Record defects and retest once fixed if necessary.
6. Test closure – Finally, once all the steps are complete, test closure occurs by documenting, analyzing, and reporting test data. Test environment cleanup can occur if necessary.

Testing Types

Now that we have discussed some of the software testing basics, let’s imagine you are hired as a tester and assigned a ticket. The first thing you want to do is be sure you understand the requirements and acceptance criteria. If any of the information is vague, communicate with your team until

you are comfortable that you understand fully. The next thing to do is remember Principle 6 above: Testing is context-dependent. There are multiple testing types and techniques, and sometimes you may need more than one to complete a test. Here are a few examples:

Functional testing

Perhaps the most common type of testing, functional testing, will verify if a specific function works or not.

• Smoke – Testing basic functions and features and is often used to verify a build.
• Regression – Testing to confirm that an introduced new code hasn’t broken existing features.
• Usability – Verifying the program is usable, easy to understand, and easy to navigate.

Non-functional testing

The focus of non-functional tests is a system’s operation. Examples include:

• Installation –Testing the installation process works.
• Compatibility – Testing across multiple browsers, operating systems, devices, or networks.
• Accessibility – Testing to determine how functional a system is for users with specific disabilities.

How to Get Started

Imagine you are to test a login feature. You will want to begin with the happy path. A happy path is a basic function test showing that the element under test works as expected in its most basic form. For example, testing a happy path for a login could be done by entering a valid username and password then confirming the user has logged in successfully. More development work is needed if the feature does not pass the happy path, and requirements may need rewriting to be more specific.

What next?

Next, you will want to go a little deeper. Think of ways you can navigate away from the happy path. Using our login feature as an example, what happens when you enter a valid username but an invalid password? What if you don’t enter a password at all? What if you enter a password but ignore case sensitivity? Learning that the function fails as expected can be equally as important as making sure it passes as expected.

Continue testing as needed but remember Principle 2 above: Exhaustive testing is impossible. You could spend more time testing, but is it required? Also, remember phase 2 of the STLC: Test Planning. Most likely, the QA Lead or Manager has designated the amount of time a feature takes to test. You do not want to waste time on unnecessary testing when you could be spending that time testing a new feature instead. These kinds of judgment calls come from having experience in software testing and experience with the program under test, and they distinguish excellent QAs from merely good ones.

Conclusion

Software testing is a challenging and rewarding career. Understanding basic principles and concepts will give the tester an advantage. It’s essential to work from well-defined requirements and acceptance criteria. Communication with stakeholders and developers is vital for a successful software tester. Testing is a process, and it takes time and experience to become an expert.