Tools for Software Quality

In this blog we have seen many different processes that help us ensure that our software is a quality software. But performing all of those processes manually without the help of any tool would end up being an enormous task. Thankfully there are multiple tools that help us perform those processes and we will talk about them today.

Tools for Version Control

For version control there are many different tools, but I will mainly be talking about Git and Github, which is the most popular one and the most used in the industry.

Before starting to talk about Git, let’s dive deeper into what is Version Control. Version control is the management of the code development process. It’s a way to manage the changes to the source code over time. It records each change and allows you to revert back to previous states that were recorded. As you can see this is very useful when developing, since if you made a mistake or prefer the way it was before you can easily just revert the changes. Version control also allows teams to work on a same program at once, since they can be working on the source code and the version control tools allow you to upload the changes and pull the changes if needed, and if there is conflict between what one member of the team did and another, then the version control tools allows you to choose between the two versions or to create a new one.

Git

Git is a software tool that allows easy version control. It uses repositories as folders for the source code which can be divided into branch which can later be merged into a main one, that is the one deployed, while you can make experimental changes on other branches to later unite them with the main one or discard them.

One of the main advantages of Git is that since you can manage repositories locally even within a team, you can still have version control even if you don’t have a network connection at a time, and once you have it all the commits will be made after you have worked normally.

Another advantage is how since it’s so popular it’s really simple to implement and most people already know how to work with it, instead of other tools of version control. Also Git allows people to make pull requests, so you can kind of put changes on a waiting list until they are checked and if they are fine they merge into the main branch.

Tools for Testing

Selenium.- Selenium is one of the most popular tools for testing, which is a free open source automated testing framework. It’s mainly used to test web applications. It can use different languages like Java or C# to create Selenium Test Scripts which are ways to automate testing.

JUnit.- JUnit is another popular tool, it is a Java automation tool for unit tests mainly. It has been important for the evolution of TDD. JUnit allows to run tests continously and tells if they are succesful or not, also allowing to test multiple things at once. It’s a simple but effective tool which provides immediate feedback.

Tools for process administration

Trello. Trello is one of the most widely used in the industry, since it allows you to have a Kan Ban board for the development team, which is the basis for Agile Development, that way everyone is in the same page and can easily see in a visual way which tasks are immediate priority, which tasks are already done, who is working on which thing, etc. It’s a very useful tool that every software team should use.

Notion. Notion is a great tool that allows teams to have their own “wiki”, that way they can have the same notes, divide the information as needed, and have the resources at hand for everyone to use. It’s a way to have the information in a neat way about the software which is easy to access and modify.

Software Testing

Software testing is one of the most important activities in the life cycle of any software, since with it we can detect easily if the software works or if it doesn’t. Software Testing is a process in which you perform evaluations of the software and the system to check if it follows the requirements, works as expected and is bug-free.

Types of Software Testing

To understand the way software testing works you need to know that there are many different types of testing and each one with its own subtypes. In this blog we will mainly talk about the software testing approaches and the software testing levels.

Software Testing Approaches

  • White Box Testing.- This type of testing is done by via looking at the structure of the code, you test the internal part of it, designing test cases for it.
  • Black Box Testing.– This type of testing is done mainly by looking at the inputs and outputs of the system or the program. You design test cases which only look at the input and the output, and see if the expected output matches the real output of the program.
  • Grey Box Testing.- In this type of testing you perform a mixture of Black box and a mixture of White Box testing, you choose tests that align with what you want out of the program.

Software Testing Levels

  • Unit Testing.- This level of testing is done via testing each module of the program as separate units, ensuring that each function and every unit of the application works correctly as expected by its own.
  • Integration Testing.- In this type of testing you check if the connections or transfer of data within the units works as expected.
  • System Testing.- In this type, you check the system as a whole, ensuring that the whole system works as is expected when all the units work together as one.
  • Acceptance Testing.- In this type of testing you mainly check if the system follows the requirements of the client. Checking if it has met the criteria for delivery.

You could also divide software testing into functional and non functional, where in one you test the functional requirements of the program and in the other you test the non functional ones.

Roles of Software Testing

  • QA Manager.- The one who manages the whole team related to testing, ensuring they are all working as a team and following the guidelines of the company and of the client.
  • QA Analyst.- The one whose main job is analyzing the results of the tests, looking for where the bugs are, what is happening, and the one who also designs the tests.
  • Tester.- The person whose in charge of testing the system using the test cases.
  • Other jobs.- Sometimes in software testing you get other roles like the one in charge of the automation of the tests or the one who tests the performance of the system.

Test Case Design

Since Test Cases are the base of testing, you need to ensure that they are good and are well designed. To do that there are different techniques which you can use to design them. These techniques are defined into 3 categories:

  • Designing test cases using the requirements specification and black box testing.- Examples: Use Case Testing, Decision Table Testing.
  • Designing test cases from the structure of the system or its components. Examples: Branch coverage, path coverage.
  • Designing test cases based on the tester’s experience or intuition. Examples: Error guessing, Exploratory Testing.

Testing Environments

One of the main ways to test is using a testing environment, which is an environment designed solely for testing before launching to the live server. It allows to deploy application and ensure it is bug free before pushing to the product.

Software Review

Performing a software review, something vital in the life of any programmer. Something we do often, maybe to help a friend or even to review our own code. Reviewing is vital to ensure that we don’t have unexpected bugs due to typos or stuff we missed. In the industry, they also perform software review but in a more organized way, with certain activities and roles that I will be talking about in the following paragraphs.

What is a Software Review?

The main characteristic of a software review is that it helps us detects errors, bugs and defects in our code, and not just that we also ensure that it follows good practices. We can perform it simply by reading our own code or someone else’s a code, it’s a matter of examining it deeply so we can detect which lines are wrong in the code and quickly fix them. That’s one main advatange that it has over testing, since on testing you can detect that your code is wrong in many different ways, but to know where it is wrong you have to debug it, meanwhile in software review you quickly fix it, so you save a lot of time that would be spent on debugging.

There are many different types and subtypes of Software Review: Mainly Peer Review, Software Management Review and Software Audit Review. But we will be talking just about Peer Review and Code Inspection which are the most used in the industry.

Peer Review

This type of review is the one used in pair programming and is one of the most common types of software review. There are two main roles: The driver and the observer or navigator. The driver is the one who is writing the code, while the observer is the one reviewing it. These two persons are always switching roles continously, so the driver is never the driver for the whole Pair Programming Session. The navigator is continously reviewing each line, and ensuring that it’s following good practices, detecting bugs or problems that may arise and considering how it may function as a whole. This allows the driver to focus completely on the task of writing the code and making sure that it works, without worrying about stuff that the navigator is looking for.

Software Inspection

Software Inspection is one of the most rigorous proccess of software review. It has two roles: The developer and the Reviewers. The process starts by the developer explaining the product created by the code, the requirements its trying to solve, and any questions that the reviewers may have. The developer then exits the room and the reviewers start to carefully examine it to detect any defect the product may have, after that they put all the data they collected in the inspection on a document and tell the defects detected to the developer along with ways to fix it. The one that tells this information to the developer is called the reporter which is chosen by a moderator which is the one that mediates everything between the reviewers and the developers. One main advantage of this process is that it can be performed even if the code isn’t over, because since the ones performing the review are humans coders they have the experience needed to detect common bugs or mistakes in the code without having specific tests.

There are three main metrics that must be carefully examined while performing a software inspection:

  • Defects; Detecting the amount of defects, and why they arised is important to ensure that they don’t happen in the future.
  • Effort: It’s important that the inspections are time effective, so they don’t end up bigger than the time spent on developing. To achieve this is important that the developers comment their code and use good practices like naming the variables relevant names and not using magic numbers.
  • Deliverable size: Inspections must be done every certain time, but in that time the deliverable that will be examined must not be too large or else we will fail on the effort metric since it will take a long time to carefully examine it.

Final Thoughts

Software review is always important, and it doesn’t even have to be hard. Just by performing good practices, doing good comments in your work and making sure that you understand how your code work will make it easier for the ones reviewing it and performing inspections on it, which on a larger scale will make your whole code team much more productive!

The Two V’s (Verification and Validation)

What does Verification and Validation mean?

Both concepts are crucial to mantain good software quality that complies with the standards we talked about before. But we have to understand what each concept means, and what are their differences before we dive deep into them. Let’s see their formal definitions according to the IEEE-STD-610:

Verification : “A test of a system to prove that it meets all its specified requirements at a particular stage of its development”.

Validation: “An activity that ensures that an end product stakeholder’s true needs and expectations are met.

With the above definitions, we can see that Verification is more about making sure we are building the software correctly with good practices, standards, and following a good methodology that allows it to meet the goals set at the start of the development cycle. Meanwhile Validation is more about making sure that the product being built is one that benefits the client, a product that ensures that the client’s needs are being met, because we may have a good product that works, but it may not solve the problems of our client.

When do we implement it into our SDLC?

The verification and validation process is one that should be present in each stage of the SDLC, we can’t allow errors, bugs, miscommunication to keep piling on until the end, because we may even find we have too many which may make the software completely useless since it would become much more expensive to fix. That’s why Verification and Validation must be done at each stage, to find errors on the planning phase, on the design phase, on the coding phase, on each process that the team does, to ensure that the errors never become too costly or difficult to fix, and also ensuring that the software being built is adequate for our client, that it is what our client needs.

The more late an error is detected, the more expensive it is to be fixed

Standards for V&V

The main standard used in the industry is the IEEE 1012-2016 which incorporates both verification and validation as a rigorous process carried since the beginning until the end.

The standard defines and talks about all the tests that should be done to comply with the standard, talking about tests like: System Integration, Acceptance Testing, Software Integration Testing, Component Testing and more.

The standard also talks about continuous review, how every test, every test result and every process done on V&V must be reviewed by the whole team working on the software to ensure of its quality and make recommendations for the next phase so the errors, or improvements that could be made are done. It should have a constant appeareance on each stage of the SDLC.

If you want to dive deeper into what the standard talk about you can visit the following website: https://katie.mtech.edu/classes/esof411/Schedule/IEEE_Standard_System_Software_HardwareV&V_160pages.pdf

How do I actually implement it into my SDLC?

Just as for the SDLC, you have to start with planning, make a good planning of the Verification and Validation process, one that covers fully the objectives, needs of the client and requirements of the software.

Document

The IEEE-1012 standard suggests making a document stating the objectives that should be met by the Verification and Validation, what products are being covered, who is involved and on which role, the activites, processes, tasks and tests that will be done to verificate and validate and how will the report of results will be done. The main part of the document should be about the planning of tests and their design and the analysis that will be performed based on those tests.

Test Design

As we see, the most important part are the tests for the V&V, they need to be built according to the goals of the software, but according to the IEEE standard, they should have the following types of test almost by default:

  • Design Evaluation
  • Interface Analysis
  • Traceability Analysis
  • Criticality Analysis
  • Software Component Tests
  • Software Integration Tests
  • Software Qualification Tests
  • Software Acceptance Tests
  • Hazard Analysis
  • Risk Analysis
  • Security Analysis

All the above tests are required to test and analyze almost everything about the software, and with those we can be almost completely sure that we will achieve our goals. Each test is in the same level of importance, and some are even preventive to detect certain risks or menaces that although not present on the software on that moment, they may arise later.

TEST!!!

Report Results

After the design, testing and analysis is finished, a good report must be made, which will be reviewed by the whole software development team. The report should present documentation about how the tests were performed, the results observed from the tests and conclusions and recommendations that can be made from their results. This process is very important, tests aren’t useful if you don’t learn anything from them! The reviewing should reveal and offer good insights for the whole team to implement them and improve the software on the next stages of it. They should cause change towards a better direction.

Remember Plan -> Design -> Test -> Review -> Success!

Sources:

Let’s talk about software standards and models

As I talked on my previous post, there are software standards and models, a large amount of them in fact. They are useful to serve as a sort of guiding light for our software that helps us bring quality to it. The best part is that you don’t even have to adhere and “marry” with one of the norms, standards and models, you can make your own standards and models by combining them and adapting them to what you need or want to achieve.

But how will you ever make that combination if you don’t know at least the main models and standards used on the industry. That’s why in this post I will be making a short view of the following ones:

  1. CMMI
  2. TSP/PSP
  3. ISO-15504
  4. MOPROSOFT
  5. IDEAL method

CMMI

The Capability Maturity Model Integration (CMMI) is a process level improvement training and appraisal program. Its main focus is to help organizations become more productive and have efficient behaviors to decrease risk in software, product and service development. It was developed by the Software Engineering Institute at Carnegie University. It works by making organizations strive towards maturity levels being level 5 the highest. The levels are the following:

  • Initial : This is the first level, the one where everything is unpredictable and the software being developed is overbudget, costly, inefficient and bug ridden. It has a high amount of risk due to the nature of the environment.
  • Managed: The second level, the one where you start to have plans, goals, measures of achievement and efficiency, but there’s still huge areas of improvement.
  • Defined: In this level, organizations start to follow standards in all of their workspaces. Everyone understands the vision and the goals of the business, while working towards continous improvement.
  • Quantitatively managed: You start to make a predictable organization that works in the basis of data to determine the best decisions and the workflow of the business. The business is ahead of future risks.
  • Optimizing: The level where an organization is stable and flexible, in a constant state of improvement, responsive to change. Since the organization is predictable and under control, that allows everyone to innovate and optimize everything.

TSP/PSP

Team software process (TSP) and Personal Software Process (PSP), are both models used to improve and guide in developing software products. Let’s talk first about PSP since TSP uses the core philosophy of PSP. PSP is a structure that helps engineers find a way to improve and measure their work. It works with levels in a similar way to CMMI:

  • PSP 0: The first level, where you start using basic coding standards and basic size measures.
  • PSP 1: Level where you start planning your time and having a good schedule for working on the code.
  • PSP 2: Level where you use personal quality management, and perform design and code reviews.
  • PSP 3: The last level, where you keep improving and making the whole process of keeping good measures, reviews, and schedules better.

TSP is focused for teams to organize their projects and produce software from small to very large ones. TSP is intended to improve the quality of code, and the productivity of the team, in order to meet their goals. TSP needs first that each one on the team is familiar with PSP. TSP works in way similar to a flow. You start with the launch where you define goals, team roles, start planning, make tasks, requirements, etc. Followed by the execution where the developers track the planned versus the actual, and report the status weekly with the managers. Then it ends on a Post Mortem to assess performance, revise planning parameters and capture lessons learned.

ISO-15504

The ISO-15504 defines a model that can be used on any software development team that is very similar to CMMI working with maturity levels. To evaluate whether an organization is in one level or another they use two dimensions:

  • Process dimension: This dimension defines all the indicators needed to evaluate the processes and workflows of the organization.
  • Capability dimension: This dimension defines the indicators needed to evaluate the capability of the organization

In base of the indicators set, the organization can be in one of the above maturity levels, depending on how well they measure on the indicators.

MOPROSOFT

The model of processes of software or MOPROSOFT, is a set of good practices and software engineering techniques to contribute so that organizations can become better at managing their way of working and developing software, so they can increase their efficacy and efficiency, which allows them to compete at a higher level. In the same way as the CMMI and the ISO 15504, it defines levels of maturity based on how well the organization implements MOPROSOFT:

Levels of maturity on spanish

MOPROSOFT structures itself on 3 categories: High Direction, Gerency and Operations. MOPROSOFT is supposed to work in a way in which the individuals on High Direction establish the goals, and standards that the gerency role must follow while taking into account their feedback, while the Gerency role is the one that defines the elements of the operations level taking into account the goals and standards of the High Direction, while keeping a constant communication between high direction and operations. Operations is the one focused on performing the activities of developing and testing based on what the Gerency role sets and they deliver their products to them.

IDEAL method

The IDEAL method means: Initiating, Diagnosing, Establishing, Acting and Learning. which are its 5 phases implemented on organizations wanting to improve themselves. The IDEAL method is best explained with the following image:

IDEAL Cycle — Initiating, Diagnosing, Establishing, Acting & Learning

The image above encapsulates what each phase is supposed to be, where in the Initiating phase, you start planning the infrastructure of the organization and setting goals and a vision, then on Diagnosing you start seeing areas of improvement and recommendations or errors, after that follows Establishing, where you plan future actions to drive improvement or to fix the priority errors/bugs. Then in Acting you create the solutions or the changed needed while improving them as you make them, followed by Learning where you analyze the whole process, and start again.

A final note

As we can see, there are multiple models to choose from to improve organizations and teams of developers, so they can have higher levels of productivity and achieve the software quality that we talked about before. It’s important to note too, that to achieve the models above, you need to follow certain standards of software quality that will guide you towards making the best decisions and setting the goals adequate to your project.

Sources:

https://www.cio.com/article/2437864/process-improvement-capability-maturity-model-integration-cmmi-definition-and-solutions.html

https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=72816

https://www.geeksforgeeks.org/personal-software-process-psp/

What makes a good Software

We all have heard about Software Quality, how important it is, and its relevance on the industry, but do we really know what is Software Quality? If we don’t understand its basic elements we can’t implement it on our Software.

What is Software Quality?

I’m sure we have all developed a software which works fine, it solves the problem needed, and everything seems fine, but does it have good quality? Just because something seems to work, it doesn’t mean that it is a good software. It may be too slow compared to an optimized one, it may have security or privacy concerns, maybe it needs too many resources or breaks when too many users are using it at once. All of the above are issues that a quality software shouldn’t have.

We often have to look for those hidden bugs

The ISO 8402-1986 defines quality as: “the totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs”. What this means is that a quality software shouldn’t just be a thing that works, it must be a complete thing, something that satisfies the customer, that is able to achieve in every way the goals of our client. Another good definition is the following: “Quality software refers to a software which is reasonably bug or defect free, is delivered in time and within the specified budget, meets the requirements and/or expectations, and is maintainable” -TRYQA. There are multiple definitions of software quality, but the core of it, is making a good product, avoiding the errors of the software crisis, achieving what the client needs, having an error-free system and ensuring that it’s efficient and secure.

But… How do we achieve quality?

Seeing the definitions above, surely you may think: “Oh, but that seems impossible how can my software ever achieve those standards”. The answer is that your software will never be 100% perfect, that is impossible, but we can make our software be close enough to perfection. For achieving that, the industry has developed many models, processes, which are kind of like a recipe that adapts to every software, because no software is the same, they all have different characteristics, issues and needs.

One thing important to note is that it’s usually rare when a software is completely finished, normally they are always in development, and just like that, the processes and models for ensuring that it achieves software quality never truly end.

Let’s see an example:

Software quality assurance is one of the most known processes for ensuring software quality. It uses the Software Requirement Specification document as a basis for its activities, and it also has its own document with the methodologies to be used along other important things. These are its steps:

A process that just like a circle, has no end

01


Create the plan

In this step, you create the plan, the document, about which methodologies, standards or techniques you will be using to ensure software quality

02


Set goals

It’s very important to set certain checkpoints and goals to ensure that the team is achieving what is expected.

03


Use Software Engineering

Software engineering provides us with very useful tools like use cases, user stories, interviews, documentation, etc.

04


Execute technical reviews

It’s useful to discuss the design quality of the software with the team to detect early errors before they become too big.

05


Multiple testing

Tests are very important to ensure that our software is good, but we should also make different types of test to ensure that we are testing everything about it.

06


Monitoring and evaluation

Checking if the software is adhering to the checkpoints you set earlier and to ensure the steps and methodology set are being followed

07


Control change

Use tools that allow you to easily revert changes that break the system and that allow you to see how a certain change affects other stuff.

08


Measure change impact

After each change, bug fix, etc. It’s important to keep evaluating the software, to see if it breaks anything or prevents a certain feature of the project to work.

09


Perform an audit

Make a reunion to compare the software quality assurance process that was documented in the beginning matches with the one being followed as the software is being developed and to observe which actions should change.

10


Document

Documentation is crucial to make sure the information needed is updated and easily available all the time. And to ensure that all the developers can be on the same tune.

11


Mantain good relationships

The most important part of the process is to make sure that everyone respects each other and is working in an harmonious way.

As you can see, it’s a long process to ensure a quality software and one main point that helps us carry out the above tasks and makes them effective is trying to adhere to standards.

Standards and its role on Software Quality and SQ processes

As we follow a process to ensure software quality, we should also follow the standards of software quality that we set for the project. There are multiple of norms with their own set of standards, and usually people use a combination of them. Some of the most known are:

  • CMMI
  • ISO 9000, ISO 15504
  • TMMI

They are very important, because they talk about the important factors and metrics that the software should achieve or should strive for. In my following post I will talk in depth about some of them.

A final note

Thank you to everyone for seeing my posts, expect more soon!

Sources:

https://www.softwaretestinghelp.com/software-quality-assurance/