Verification and validation in the software testing process – table of contents:

1. What is verification in software testing?
2. What is validation in software testing?
3. Features of the validation process
4. Features of the verification process
5. Key differences between verification and validation

What is verification in software testing?

Verification in software testing is the process of checking documents, design, code and program to control whether the software has been built according to requirements. The primary role of the verification system is to guarantee the quality of the application, architecture, design, etc. As part of the software verification process, activities such as reviews here are undertaken.

What is validation in software testing?

Validation in software testing is an effective mechanism for testing and verifying that software adequately meets customer needs. Thanks to this mechanism, it is possible to assess whether the software fulfills its purpose in a suitable environment. During the validation process, activities such as unit testing, integration testing, system testing and user acceptance testing can be performed.

Features of the validation process

The main features of the validation process are as follows:

• it is a dynamic mechanism for testing and validating the actual product
• it always involves code execution
• it uses methods such as black-box testing, white-box testing, and non-functional testing
• it can detect bugs, failures and other inaccuracies that the verification process cannot catch
• the target is the actual product
• it is performed with the help of a qualified team of testers
• checks if the software meets the customer’s requirements and expectations
• follows verification

Features of the verification process

The main features of the verification process include:

• inspecting documents, design, code and program
• it does not require code execution
• checks if software conforms to specifications
• finds errors early in the development cycle
• the target area here is the application and software architecture, complete design, specification, high-level design, and databases
• it is carried out by the QA team, which makes sure that the software complies with the requirements in the SRS document
• it uses methods such as instruction, reviews, inspections, and document checking
• verification happens before validation

Key differences between verification and validation

During the verification process, documents, code, design and program are checked, while validation is already based on testing and validation of the real product.Verification does not involve code execution, while validation does.

Verification uses methods such as reviews, guides, inspections while validation uses methods such as black-box testing, white-box testing and non-functional testing. It checks that the software conforms to the specification, while validation checks that the software meets user requirements and expectations.

Verification focuses on finding errors early in the development cycle, while validation concentrates on identifying errors that verification cannot catch.

Comparing the validation and verification in software testing, it can be said that the verification process is about the software architecture, design and database while the validation process is about the actual software product.

Verification is carried out by the QA team, while validation is done by the testing team with the QA team. The verification process occurs before the validation process.To sum up, validation and verification are processes that differ significantly from each other.

The former includes all forms of testing, which determine whether the system meets the customer’s expectations, while verification determines whether the system works properly, according to functional and non-functional requirements. The verification process always precedes the validation process.

You’ve just read about verification and validation. Check out our other series about Python and Javascript!

If you like our content, join our busy bees community on

Testing vs debugging- table of contents:

1. What is software testing?
2. What is software debugging?
3. Testing vs. debugging
4. Differences between testing and debugging
5. Summary

What is software testing?

Testing is the process of verifying and validating software. It ensures that it works as intended. In other words, it verifies that the software has achieved the intended result. Testing is carried out by a team of testers. They identify bugs in the software, and when they find them, they record them and inform the development team.

Then, the testers create a comprehensive report containing all the details of the error. They include information such as the identifier, description, occurrence, what happened because of the error, etc. The development team uses this report to fix the bugs. The following distinction can be made:

Functional testing verifies that the software has reached the expected level.

• Unit tests are used to verify that each module works as it is expected. It is the testing of individual modules. Unlike other types of testing, unit tests are performed by developers, not testers.
• An integration test is a test of two modules that checks the flow of data between them.
• System testing is the testing of all software.

These are some common types of functional testing. Non-functional testing checks non-functional aspects of the system, such as performance, scalability, usability, etc.

What is software debugging?

Debugging is performed by the test team after receiving the test report from the testers. The programmer analyzes the reports and tries to find the cause of the errors. The person goes through the fragment of code where the error occurred and checks each line of the program.

After finding the error, they modify the code fragment in question and check again to see if the fault has been corrected. Once the bug is fixed, the programmer sends the software to the test team.Nowadays, most development environments have a special tool called a debugger to assist in the debugging process.

Testing vs debugging

The main difference between testing and debugging is that testing is the process of finding and identifying software defects, while debugging is the process of correcting identified defects.

Software development is a complex process involving several stages, such as requirements analysis, design, development, testing and maintenance. Testing and debugging are two activities involved in software development.

Testing is the process of finding defects in software. Debugging is the process that helps fix identified defects. Both testing and debugging help deliver working and high-quality software to users.

Differences between testing and debugging

Definition

Testing aims at verifying that the actual results correspond to the expected results when it comes to software operation and making sure that the software is free of defects. Debugging is the process of finding and fixing defects or problems in a computer program that prevent the software or system from working properly.

Main task

The main difference between testing and debugging is that testing is the process of finding and identifying software defects, while debugging is the process of correcting identified defects.

Execution

Testing is carried out by the testing team, and debugging is done by the development team.

Purpose

Another difference between testing and debugging is the goal. The purpose of performing a test is to find as many defects as possible. The purpose of debugging, however, is to fix the bugs found.

Way of implementation

While testing can be done manually or automatically, debugging is done manually.

Testing vs debugging – summary

To conclude, both testing and debugging are important activities in the software development process. The difference between testing and debugging is that testing is the process of finding and identifying software defects, while debugging is the process of correcting identified defects.

You’ve just read about testing vs debugging. Check out our other series about Python and Javascript!

If you like our content, join our busy bees community on

6 phases of STLC – table of contents:

1. Phase 1: Requirement analysis
2. Phase 2: Test planning
3. Phase 3: Test case development
4. Phase 4: Environmental setup
5. Phase 5: Test execution
6. Phase 6: Test closure
7. 6 phases of STLC – summary

Phase 1: Requirement analysis

This is the first step in the cycle. The test team carefully reviews the product requirements. If there are any conflicts, omissions, inaccuracies or misunderstandings, the test team discusses them with various project stakeholders, such as the business analyst or software architect.

Entry criteria:

• Business Requirement Specification (BRS)
• a software architecture document

Tasks to do:

• determine the tests to be performed
• set priorities for test execution
• check which tests must be manual, and which must be automated

Exit criteria:

• a list of requirements for testing
• any tests to be automated

Phase 2: Test planning

At this stage, the validation team plans all testing activities by writing a test plan. This document specifies:

• the objectives to be achieved
• the processes and methods to be implemented
• the environment and tools to be used
• the elements to be tested or not tested
• the organization of the team and the division of tasks,
• intermediate goals for various activities
• risks that may arise

Apart from developing the test plan, a cost estimate is also drawn up in this phase.

Phase 3: Test case development

In this phase — also known as Test Design — there are four steps to follow:

1. Prepare test scenarios

The test manager or test leader prepares a test scenario which will be used to create test cases.

2. Create test cases

For each scenario, testers will write test cases so that they can verify that the software functionality meets its requirements. In the case of test automation, it is at this stage that test scripts will be written.

3. Prepare test data

The test team needs to prepare a set of data to be used when executing test cases. This can be positive or negative data to test the function’s performance in the case of correct, or incorrect data.

4. Prepare RTM

The test team prepares a key Requirement Traceability Matrix (RTM). This document is used to keep track of what tests are needed to verify whether requirements will be met or not. Before testing begins, stakeholders will conduct checks and validations of what was developed during the above activities.

Phase 4: Environmental setup

This is a phase in which the test team is not involved. A separate team will handle the preparation and configuration of the environment. Testers will be informed how the environment has been set up and which software version is up to date.

The only activity required of the test team is to prepare smoke tests to verify that the installed build is suitable for testing. If the smoke tests fail, the build will be rejected and testing will be suspended until the indicated problems are fixed.

• test plan
• test date
• smoke test

• test environment preparation
• test environment setup
• setting up test data
• executing smoke tests on compilation

• usable test environment
• usable test data
• positive smoke test results

Phase 5: Test execution

This is simply the execution of tests. During this phase, testers can identify possible anomalies and test the improvements developed by the programmers. The tasks of the testing team will be:

• run the previously developed test cases and compare the expected result with the obtained one
• maintain the test script
• identify, detect, log and report any detected defects
• retest the defect fixes

• functioning test environment
• correct test data
• test plan
• test cases to be executed

• perform tests according to the test plan
• document test results
• manage the defect life cycle

• executing all tests involving the MTR
• updated test cases with results
• defect reports

Phase 6: Test closure

The software will be implemented. The validation team meets to analyze the results and identify areas for improvement in future projects.The test manager prepares a test closure report, which will be done on a daily (DSR – daily status report) or weekly (WSR – weekly status report) basis, as agreed by the stakeholders.

In the end, the test team meets to analyze the test cases, defects found, time spent, compliance with deadlines, etc. In this way, it is possible to determine what needs to be improved in the next test cycle.

• test execution reports
• defect reports

• analyze what has been tested
• create a test closure report

• closing the process without open defects
• test closure report

6 phases of STLC – summary

Software development could not exist without a testing phase. Proper preparation for this process brings a number of benefits, including, most importantly, saving time and money for possible future revisions. We hope this article helped you learn more about software testing life cycle (STLC).

You’ve just read about 6 phases of STLC. Check out our other series about Python and Javascript!

If you like our content, join our busy bees community on

ISTQB testing principles – table of contents:

1. Testing reveals defects but cannot prove their absence
2. Thorough testing is impossible
3. Early testing saves time and money
4. Malfunction snowball effect
5. Pesticide paradox
6. It depends on the context
7. Advertising flawless software is a no-go
8. Summary

Testing reveals defects but cannot prove their absence

Testing increases the probability of finding mistakes, which in turn facilitates chances to fix them. However, it cannot fully guarantee that software is free of all defects even if the vast majority get spotted and fixed. Due to the inability to create flawless software, many consider the process as negative by design, as you’ll never get a positive result and always find some “dirt” in the programs.

Thorough testing is impossible

The above rule of thumb states that detecting all malfunctions of software is futile. However, that doesn’t apply to simple short programs. This, in turn, indicates that there is a chance to see all combinations of inputs and preconditions to test some programs completely. When evaluating sophisticated software, even the best AI can’t execute all necessary measurements, let alone manual testers. Automated assessors will run through apps more efficiently and accurately, but they still cannot guarantee flawless performance. To do so, you have to embark on additional tasks like prioritizing, risk analysis, as well as finding and running other testing techniques.

Early testing saves time and money

Many professionals also call this principle “shifting left.” The sooner you spot defects, the easier you can fix them, hence static and dynamic testing should begin as soon as possible. In a nutshell:

• Static testing – assesing tne product without running the code.
• Dynamic testing – evaluation of the code of a module or system during its performance

Detecting defects in the first phases of implementation facilitates further diagnosis. But when two areas of software interact, amending defects becomes troublesome due to the inability to pinpoint the one that has the error. In such cases, it takes extra time, effort and manpower to tackle. All in all, it’s the rapid response to surfacing obstacles that can prevent cracks from multiplying

Malfunction snowball effect

Most glitches tend to cluster in most critical modules, so their in-depth examination reveals and sufficiently eliminates most. These groups become the major focus of running risk analysis to map out and establish the future conduct of actions. The majority of flaws surface after following the paths the users take but in these cases, knowledge alone doesn’t render the modules are impeccable.

The Pareto principle, says that 80% of results originate from only 20% of causes. In other words, 80% of bugs exist in 20% of modules. If you encounter numerous malfunctions in a module, keep digging as they’ll be there.

Pesticide paradox

Running the same tests repeatedly may fail because they may have been designed incorrectly in the first place and will never prove effective. You have to amend and upgrade testing to increase the chance of finding new faults in the software.

Creating a completely new system of diagnosis won’t do the trick either. Following the previous combinations may stop the assessment process at the same level. This principle is coined ‘pesticide paradox’ because pesticides that control pests also lose effectiveness after a given amount of use.

It depends on the context

The way of executing testing depends on the subjects examined. Thus, testing an accounting program, a video game, or a social networking application vary substantially. It also depends on the situation, for instance, an analysis focusing on the practicality of an app like checking its attractiveness to users, ease of use, visual layer, etc. also differs from those evaluations aimed at functional attributes of the program, e.g. performing correct calculations.

Advertising flawless software is a no-go

Applying various types of diagnostic tools cannot guarantee spot-on apps. Many who claim and advertise their apps as such are wrong, yet probably it is only for the marketing efforts they make the claim. You can execute multiple manual and automated tests to increase the probability of uncovering and fixing as many errors as possible, but still, there is no guarantee of perfect performance. In some cases, the obstacles concern operating software, e.g. the program may not meet all user expectations.

ISTQB testing principles – summary

This is how ISTQB, at a basic level, presents seven ISTQB testing principles that a software tester should follow. First, they indicate the infeasibility of full software diagnosis, hence it is crucial, among other things, to modify tests, as well as to conduct a thorough search in the key modules. These actions enhance the search and clearance of the majority of defects decreasing the likelihood of failures in the future.

What is software testing? Now you know the answer! Check out our other series about Python and Javascript!

If you like our content, join our busy bees community on

What is software testing? – table of content:

1. What is software testing?
2. Software testing objectives
3. What does the job of a software tester look like?
4. How to become a tester?

What is software testing?

Software developed by programmers is subjected to tests that consist of checking its correct operation and compliance with the specification. This is called software verification.

Specification is a document that has all the necessary information about the software, e.g., an application, and first it contains a description of the functions it should perform. Checking if the software works according to the users’ expectations is called validation.

Testing improves software quality, limits the occurrence of failures resulting from errors, reduces financial losses, shortens the time of software development and strengthens the company’s image. Testing activities are best performed in the earliest stages of software implementation. The sooner a bug is detected, the lower the cost of fixing it. If tests are not carried out in the earliest stages of software development, complications may arise due to e.g., advanced work on the project, which may make it difficult to locate the source of the error and fix it.

Software testing objectives

According to ISTQB (International Software Testing Qualifications Board), testing objectives can be achieved by:

• Prevent defects resulting from errors by evaluating work products such as code,
• Reduce the risk of software quality deterioration by detecting failures caused by defects,
• Verification that the software meets all the requirements that were included in its documentation, validation, that is, verifying that the software aligns with user expectations,
• Building confidence in testing at every level,
• Providing information that influences stakeholders to make informed decisions,
• Compliance with laws, standards, norms and contractual requirements.

What does the job of a software tester look like?

A tester’s job is to report bugs found as a result of software exploitation. In case of finding them, he reports them to a programmer responsible for a given area or the whole software. Dedicated programs are designed for this type of reporting. The tester describes the path in which he presents step by step the way the error was detected. This allows the programmer to quickly find the bug and fix it, and then report the completed task to the tester for retesting. The tester, in turn, retraces the path by repeating the same sequence of steps. If the bug is fixed, he accepts the task, and if it is repeated, he reports it again to the programmer.

Testers are divided into manual and automated testers. As a manual tester’s job is to single-handedly test the software by assessing each test scenario containing all cases, is time-consuming. An automated tester, in turn, uses tools to write scripts and programs that speed up the the process and additionally detect errors that may go unnoticed by a manual tester. Automatic testing is, therefore, more precise, but creating tools requires knowledge of programming languages, e.g., Java, SQL or Python.

How to become a tester?

Anyone who plans to become a software tester should learn the theory of testing. The knowledge gained can then be verified by taking the ISTQB exam. This is a non-profit organization that has been operating since 2002. The exam has the form of a test, and after obtaining a positive result, the examinee receives a certificate confirming his or her competence and knowledge as a tester. The advantage of the exam is that there is no expiration date for the certification and it is recognized worldwide.

The ISTQB exam can be taken at three levels: Core, Agile, and Specialized. Core addresses the multi-faceted topic of software testing. Agile refers to agile software testing practices, and the specialist module, for example, provides information related to specific testing activities such as test automation. There are also three levels of exam difficulty: basic, advanced, and expert. Below is a diagram of the mentioned modules and their levels.

A tester plays a vital role in the proper functioning of the software, so he or she should possess qualities that will make the job easier. Accurate, patient, consistent and communicative individuals will do best in software testing. A tester should also exhibit analytical thinking skills due to the implementation of test scenarios.

Summary

Software testing is a way of detecting irregularities in software and improving its quality by meeting testing objectives. The entire process is handled by software testers who have the specific knowledge to facilitate their work and they can confirm it by e.g., obtaining the ISTQB certificate.

What is software testing? Now you know the answer! Check out our other series about Python and Javascript!

If you like our content, join our busy bees community on

Software errors – table of content:

1. Reasons for software errors
2. Life cycle of an error
3. Significance levels of errors in software
4. Summary

Reasons for software errors

The errors in software come are caused by so called bugs or failures and those are main reasons for bad functioning of the software. The occurrence of errors is possible at any stage of creation of the software. Most often errors are to be found in the code itself and are caused by human actions. The defect found in one part of the software may have an impact on the other parts of the same software, especially if both are connected. An error is a result of a defect, both may lead to serious failures, which can manifest themselves during running of the software.

Accordingly to International Software Testing Qualification Board, there are many different reasons for software errors and those are:

• human imperfection
• pressure of time
• lack of qualification, skill or experience
• bad communication in the team
• invalidly written specification
• complexity of: code, project or technology
• misunderstandings related to the interface inside the system and between systems – especially in case of a high number of those systems
• implementation of new technologies

As it was mentioned before, errors lead to defects and defects lead to failures, here it is wort to note that failures not always are caused by a human error. The occurrence of failures may be caused by other phenomena such as: radiation, electromagnetic field, or contamination. Such factors influence the operation of the software by changing the external conditions that affect the hardware.

Life cycle of an error

Life cycle of an error is a process, which begins at the moment of error’s discovery and reporting to the moment of the fixing and task closure. The length of the cycle depends from the severity of the error Complexity of the error may significantly extend or shorten the time needed for fixing. There are many programs that are used to monitor software errors, and the choice of the program may affect the life cycle of an error.

The exemplary life cycle is simple. At the first stage the error is reported in the notification and gets an open status. In the notification there is a path that allowed the tester to find the error. Additionally, the programmer, who deals with the task is assigned in the notification and as soon as he starts to fix the error its status changes into in progress. This information is particularly important for the tester, who can start testing the software as soon as the notification changes into ready for test.

The second component is the feedback. When all the surveys are being filled up by the respondents one nice and tidy report has to be created. The whole information has to be reviewed attentively so the all important insight can be gathered. This is particularly important because it is easy to misinterpret the findings. Survey used for the given case has to well adjusted and sound.

The tester starting his operation changes the status into test in progress and after finishing chooses one of two options: resolved (in case of successful repair) or reopened (if software error still needs reparation). In such way programmer get notification about the necessity to restart work on the error.

Significance levels of errors in software

The software errors may be divided accordingly to significance levels, which is being granted by testers. The significance level pass the information about the impact of the error on program functioning. The higher significance level of an error the faster it should be fixed.

The highest of level of significance is called blocker since its occurrence means the complete lack of further ability to use the program and necessity to stop testing it. The example of the blocker is a software error, which turns off the application. Such error requires quick fixing to enable further testing.

The lower level of significance is called critical because the software error of that level makes using all the functions of the program difficult. Such software error doesn’t block completely testing, but it has great impact on testing process, and the software cannot be released without fixing this problem.

The major level of significance is quite important but it doesn’t hold the testing process.

The error of medium level of significance is an error of moderate gravity, that does require fast reaction since it does not obstruct tests making.

5. Empowerment of individuals – when 360 degree feedback is used all employees have a chance to voice their concerns. Individuals may feel that they have a voice and that the company respects their view and opinion, hence any type of action in result employees are heard has a positive impact on staff morale.

The lowest level of significance of error, namely trivial, means that the software error is of small importance.

Summary

The errors in the software have many causes but they occur mainly due to the unconscious human action. It is necessary to check the accuracy of any software by continuous testing. Each software error has a cycle of living, which ranges from its discovery to fixing. Errors have different levels of significance, each has the same importance, but some block the possibility of using the software to the extent that it cannot even be tested, while other don’t influence those processes as much and are easy to fix.

Read also: 4 types of employees every company needs

If you like our content, join our busy bees community on