Software testing and quality assurance
01 — Problem:
Quality assurance is the backbone of software development. Nowadays commercial software is not going to be successful if there are faults in its quality. These can be anything from the usability of the UI to speed and safety of the software. There are many parts in software testing and all of them have to be taken care of so that the software can work the way it is supposed to.
If one wants to keep the users of the software happy, or let alone get users, quality assurance simply can’t be forgotten. Bad user experience pushes the users away and presents an unprofessional impression of the company behind the software. No one wants that kind of image for his/her company.
A common pitfall in software development is to underestimate the resources of quality assurance and this can easily lead to not meeting the deadlines or just simply into poor quality of the software. It’s not enough to have the best developers, you also need to have the best quality professionals.
Testing is often thought as an investment that does not really produce anything of value. That is most often false – the earlier possible defects are found and fixed, the better the quality is that eventually goes live.
Although fixing issues may take time and resources, it is most often worthwhile; There is no software in the universe in which there were no defects during development. Quality assurance never helps to be in the black at the exact time, its value can only be seen in the future. And even then, only by judging the small number of defects in the final product, which is itself a pretty good starting point for every software project.
Too often too little testing, or testing too late, produce perfect hindsight and only then is early testing seen as the best approach. The late fixes and/or changes usually take much more resources, mostly time and money, than they would have taken had they been done earlier. If testing is an integral part of the development process from the start, and all stakeholders take it seriously, can one expect the books not to be in the red.
02 — Solution:
VALA is a forerunner in software testing and quality assurance in Finland. That’s why it’s natural that we have knowledge and experience in all relevant areas of quality assurance. Our professionals have more than ten years of relevant experience in average, so you can rest assured that your software is in good hands.
Our experts bring that kind of knowledge and expertise to our clients that the clients do not yet have and which is rather challenging to acquire. Modern software testing is not just mouse clicking, but rather something that requires comprehensive intelligence and experience. Through various customer projects, we’ve gained an extensive overview of different working methods and -cultures, gathered best practices and learnt to avoid the worst pitfalls. We train our people continuously without forgetting everyone’s personal attributes; we don’t try to fit everyone into the same mould but rather celebrate individual characteristics and strengths.
03 — In practise:
VALA’s software testers bring with them a hefty dose of quality culture and mindset. VALA’s Quality path supports our testers in all parts of their work and this leads to simply better testing.
Software testing can divided roughly into three main areas and six different testing levels. VALA testers handle all these areas and levels. Read more about these below.
Levels of software testing
As its name says, unit testing tests small parts of code, units. These are by principle the smallest parts of a software that can be tested. The goal is to make sure that these small parts are written correctly. Unit tests are usually automated and created at the same time as the actual development progresses.
System testing on the other hand is about the whole system and its different use cases.
The goal of Integration testing is mainly to test how the different parts of the software communicate with each other, in other words, how does the integration between them work.
Main areas of software testing
The purpose of functional testing is to ensure that the software works as it’s supposed to and fulfills the set functionality goals. It is usually done from the viewpoint of the end user and executed by using the actual user interface.
Regression testing includes the before mentioned levels of testing but is different by its nature. While functional (and non-functional) testing tries to find as many new defects and error situations as possible, regression testing on the other hand makes sure that new changes to the software haven’t broken any working functionalities.
Acceptance testing is usually done by the customer or their representative who checks whether the ready or almost ready product matches the requirements of the pre-determined use cases. Acceptance testing requires good knowledge of the business at hand, the requirements of the customers and the possible regulations and legislation in question.
As the name implies, non-functional testing is about testing the aspects that are not visible functionalities. These can be for example performance, security, tolerance to defects or use of resources.
Usability testing examines how well the software works in general – is it easy to use, is it intuitive and logical, are the colors, contrasts and transitions working well, are the loading times decent and so on. Depending on the device and the user group, the requirements for usability can vary a lot but, in all cases, there is a solid theory and good practices behind a good usability.
Exploratory testing is less systematic and relies on the expertise and experience of the tester. Usually the focus areas are predetermined, and a log is updated of what have been done and what were the findings. Exploratory testing can be a very efficient way to go through even complex things without having to deal with vast amount of preparations and documentation. Many times, the results can be surprising – during the sessions the testers can evaluate things from multiple perspectives and even unorthodox point of views are present, unlike in more systematical testing.
Our software testing and quality assurance references
For more information
