Quality AssuranceQuality Assurance is the process of reviewing a piece of work to ensure that the quality and standards are met.... in software is just like any other industry, its a process teams must follow to ensure that whatever is produced is produced at a high level of quality. What high quality means for your system, platform or app could be very different from another system. However, all of these are software solutions and this means that there are many patterns that apply to ensure quality code is written. The policies also outline how to get your team following procedures to review the source codeAny application or website that is written is developed using code of a specific language. That code is called the... to ensure the standard is kept.
If you follow the items on this list you are ensuring that your team is keeping to a standard process to ensure consistent high-quality output. Your team should do the following to ensure procedures, policies and standards are kept:
- Code Structure
- Code Style
- Static Code Analysis
- Code ReviewA code review is a process of one developer or engineer reviewing the code of another developer. This process occurs...
- Manual Testing
- Automated Testing & Regression Testing
- Client Acceptance
Code Structure
If code is written poorly it becomes difficult to find specific things, without doing a global search for code, hard to maintain and test. The structure of the code is like the concrete slab for a house, if it’s done right from the start it sets a solid foundation that allows for the rest of the development to grow from.
We’ve seen projects that have “Spaghetti Code” (it might look good in the picture above, but it’s terrible in code) or ridiculous amounts of “Copy & Paste” code, these poor code structures make it incredibly difficult to debugDebugging is the process of a developer working through code in order to try and find any error or bug.... and fix things. If there is a bugA is old computer term for something that happens in software or an application that is not as expected. Bugs... how many times will you have to fix the same issue in the codebase? How much time will you spend digging through code to find things?
Developers need to have a clearly defined structure that they follow in order to ensure that any developers working on a project know where to find specific files or where to create new files. This allows for quick onboarding of new developers, the ability to easily search through code and follow a well-defined structure. Without this, your team will be wasting countless hours looking for things in code not knowing where they will be. The problem only grows when you have a different structure per project and get people to work on multiple projects at once.
Code Style
Without knowing what Code Style you might think why does it matter if the code looks good and it works? Well, it is very important and helps define how things are used and written in code. What convention is used for defining variables, methods, constants, static methods, classes? If you do the same thing for all of them, then looking at the code you won’t be able to easily discern what each thing is. If all variables are using Camel Case ( starting with a lowercase letter) and the methods are using Pascal Case (starting with a capital) you can tell at a glance what is a method and what is a variable.
If each person on your team is a great coder but follows their own code style then you will have great confusion amongst your team and a much slower output. The code needs to look like it was written by one developer, even if a team of 10 was working on it. This consistency in style helps anyone jump onto the project and work on it or search for bugs or fix bugs. The other processes defined below provide some ways to enforce this style is kept consistent via Static Code Analysis and Code Reviews.
Static Code Analysis
This might sound like gibberish to you however it is a tool that when used during development helps developers adhere to industry coding standards. Each language has it’s own structure and conventions it is just like a spoken language each is different. If you code in one language and use the structure and convention from another then it will increase the complexity of the code and make it extremely difficult for any other developers who know that language to be able to assist.
Static Code Analysis is a tool that can analyse the written code without it being compiled, saving time, and can provide errors or warning to developers in a timely manner. This tools can be leveraged within the IDE’s themselves (the tools used to write code) as well as in automatic build tools which can do this on their own as developers commit code and get notified of what is found.
Code Review
Getting your procedures and policies in place early is a great way to start, but it can be difficult to get your team on board sometimes. Most developers don’t like the code reviewA code review is a process of one developer or engineer reviewing the code of another developer. This process occurs... process as they don’t want to be second-guessed or someone going over their code line-by-line. However, we take it as an opportunity to learn from each other as we can provide feedback, alternate ways of doing this, educating the coder on features they weren’t aware of or even learn something new from the code that we didn’t know about in the first place.
Using Code ReviewA code review is a process of one developer or engineer reviewing the code of another developer. This process occurs... tools also provide some extra benefit by providing analysis in code and other insights such as tagging comments and determining trends from those. Wouldn’t it be great to identify a team member who always makes the same type of error and educate them on how to avoid it?
The Code ReviewA code review is a process of one developer or engineer reviewing the code of another developer. This process occurs... process is also critical in not only reviewing the code style and structure but its a great way to catch potential logic issues as another developer needs to understand the code and point things out before they’re caught in testing or production.
Manual Testing
Manual code testing is the first testing concepts a developer learns, it allows them to test the code they’ve written by using it physically wherever it is deployed. This is a great way to start but in no way should be a teams sole testing method. It’s is very slow, resource and time heavy and doesn’t provide consistency. There is no idea of coverage, how much code is covered by doing these tests?
Some components of an application are very difficult to create automated tests for and you might rely on manual testing for small components following a specific test cycle to ensure some consistency in the tests that are run. They are a great tool as a developer is developing or prototyping features but if there is to be any consistency in the testing, any insights in the amount of code that is being tested then the tests need to be automated.
Automated Testing & Regression Tests
Automated Testing is the next step up from Manual Testing and provides the biggest gains in the testing area. It can be created as Automated Code Testing or Automated UI Testing that either runs small bits of code in isolation or runs integration tests across components or entire systems.
This method of testing involved writing code to test the code, that concept may sound strange to you but it’s the only way to systemize and ensure consistency. The way the tests are written is to test and verify that each branch within the code is being called correctly and that the correct output is returned, or the correct methods are called within it.
Now for example with the following code.
function string OutputMessage(int quantity) {
if (x < 0) {
return "you do not have sufficient quantity";
} else {
return String.Format("you will be ordering {0}, products, ", quantity);
}
}
You would write the following testing to ensure this method was executing as expected
Case: If quantity = 1, Result: you will be ordering 1, products
Case: If quantity = -1, Result: you do not have sufficient quantity
By writing test cases using the above rules you can then automate this test and run them at any time. If anything changes within the method the test will fail and you will be notified that an issue is present and you have failing test cases.
There are times when developers make changes to a specific bit of code, a function, and don’t realise what is using that code. The automated tests can easily pick this up as they expect a result that is not returned. That is how we prevent bugs from being created by other code, in other words, Regression testing.
Using Automated tests is the best way to ensure regressions are not made in the code and new bugs are introduced when new features are added and existing items are modified. If you don’t update the tests they will fail and the feature will no longer work.
This kind of testing is also useful for visual bugs etc can be testing the same way using automated UI testing frameworks. They are normally coded but some tools have been developed to capture your flow through the system and then convert that to code for you, saving time. Regression bugs are sometimes not caught as you might not have enough coverage for a method or the tests are not covering all possible branches.
If we modify the above method to have the following code, the test cases would pass but a bugA is old computer term for something that happens in software or an application that is not as expected. Bugs... is introduced for a specific case.
function string OutputMessage(int quantity) {
if (x < 0) {
return "you do not have sufficient quantity";
} else {
double discount = 2 / quantity;
return String.Format(
"you will be ordering {0}, products with {1} discount",
quantity,
discount);
}
}
without the following test case
Case: If quantity = 0, Result: an exception is thrown, cannot divide by zero.
then you would not know there is a bugA is old computer term for something that happens in software or an application that is not as expected. Bugs... with the code as your tests do not pick it up. The code coverage component of Automated testing will help identify this and prevent your code from regressing and having a but introduce to existing already deployed code.
Client Acceptance
Client Acceptance is the final critical step in release a shiny new feature of your products. In most cases, if you develop for a client, they have the final say on when software can be released. This is important as a release can impact the clients business through their staff or their customers and any impact could be severe. It’s best to have identified the acceptance criteria prior to development, this helps get the development team and client on the same page, they both know what to expect at the end of the feature development. Once deployed to a Staging or UATUAT is short for User Acceptance Testing. User Acceptance Testing is the testing, that as the client, you perform to... Server/App then the client can test the app and be the final gatekeeper to the release.
This also provides the client with the confidence that the feature is delivered as expected, they are involved in the process and are then able to communicate to their users the information required around the new release. This provides them with a point in time to have the feature ready for release but not being released until they are ready to communicate and create potentially marketing material to update and educate their users.
Consistency is key and allows your team to maintain its procedures and policies to ultimately keep proper standards. Without this, you will develop something inferior that will cost time and effort where it shouldn’t e.g. BugA is old computer term for something that happens in software or an application that is not as expected. Bugs... fixing – having to copy and paste the solution in multiple places, or time wasted just finding things in a mess of code.
Following these steps allows for a more reliable codebase to shipped which in turn increase reliability and user satisfaction. There’s nothing worse than putting out a brand new shiny release for people to use and then getting inundated by support calls for issues and not being able to find them or solve them easily. Remember to define your structures, use them across your projects, keep your team accountable through these above processes and you will ship good code that can be maintained and managed easily.
