In our previous article, we examined the impact of processes on product quality. But ultimately it’s all about people’s attitude to the company, team, and product. So let’s see what people can do to assure consistent product quality:
Even the best process is worthless if people are not working to keep it alive.… Read more
Tools, methods and principles such as those presented in our previous article are a sound basis for creating a solid product, and they need to be embedded into a good process. So let’s dive into today’s topic:
Designing a good process is hard. Fortunately, standard process frameworks are readily available: CMMI and Scrum are two famous standards, the first one being very detailed and having a very broad scope, the other agile with a focus on software development in single teams.… Read more
Our last post centered on the variety of tools available to assist engineers in controlling and improving product quality. Let’s now see how methods can help us to assure quality
Development starts with a requirements analysis, or with writing good user stories if you prefer the agile style.… Read more
As announced in our previous post, let’s have a closer look at the tools required for quality assurance
There are plenty of tools to assist engineers in controlling and improving product quality. They are helpful, and should be used.
Modern workstations and a good working environment are factors that are often neglected, but they play a part in making software development more efficient, and the same applies to quality assurance.… Read more
In our previous post (Sequel: Software Quality Assurance for the PTV xServer) we touched on the subject of what quality can mean for us. So let us now look into specific ways of assuring quality.
First: testing. Just as functionality is not the only aspect of quality, testing is not the only aspect of quality assurance.… Read more
What exactly do we mean by quality?
There are many answers to this question, unfortunately all very different. The naïve answer is “the product has practically no faults“. This answer is wrong, or at best incomplete. An empty program is probably as faultless as any program can be, but of very little use.… Read more