Test ALL the things!

Testing your code base is important for ensuring that it does what it's supposed to do. It can also help you identify any bugs before they hit production and save you from spending time on trying to figure out why something isn't working correctly. In this post, we will look at the different types of testing that exist and how each one works so that you can choose which one best suits your needs!

The Types of Testing

There are so many ways to test a code base or a running application created from the running code base. In security terms we have SAST and DAST to represent the difference between the instantiated codebase vs the static code un-run on the screen before us and now even IAST!

Acceptance Testing 

In short, Acceptance Tests allow a team to ensure that the software meets the specifications of the customer. Acceptance testing involves an independent tester performing a scenario-driven evaluation of the software. It is performed by the customer or a representative acting on behalf of the customer.

Acceptance test cases can be used to verify that the software meets all requirements defined in user stories and requirements specifications.

Smoke Testing 

Smoke Tests are used to determine whether a build is stable and therefore ready for further testing.

Smoke testing is a quick way to test whether a build is stable; it's also a good way to find and fix problems in your code base early on, when they're easy to fix. In most cases we turn it on and the off again to see if it behaves correctly (like Power On Self Test/POST when you turn your computer on and hear that beep... or used to when I was a kid!), did it power on, or did it go Boom!? 

Integration Testing

 

Integration Testing is a testing phase in which individual software units are combined and tested as groups in multiple ways. It follows unit testing and precedes system testing.

Integration testing is a testing phase in which individual software units are combined and tested as groups in multiple ways. It follows unit testing and precedes system testing.

The purpose of integration testing is to verify that components work together properly, not that the system works as a whole. Integration tests are designed to test architectural and behavioural aspects of the application or system being tested.

Regression Testing

Regression testing is a technique used to identify any changes to computer programs that might cause previously working features or functions to stop working properly after new code has been introduced. It is a type of nonfunctional testing and can be performed manually, or automatically by computer systems. Regression tests are often used to detect software bugs and ensure that fixes do not introduce new problems in the software under test. They may also be performed with the intention of ensuring that new product versions operate correctly as intended (in some cases, regressions may occur due to changes in product requirements).

Soak Testing

Soak Testing, also known as endurance test, is a type of nonfunctional testing used to determine how a system behaves over an extended period of time when running under peak load conditions. It checks whether the system performs well even after prolonged use under normal workloads by evaluating the response times and error rate during the normal operation stage of stress testing.

Soak Testing is a technique used to identify any changes to computer programs that might cause previously working features or functions to stop working properly after new code has been introduced.

Unit Testing

Unit Testing, is the type of tests where we take individual components and test them individually to monitor their behaviour and ensure they meet the required standard.

Unit Testing can help developers to debug low level issues quicker by testing the response given back to the overall system by the smaller modular components that build up to create it.

Subject Driven Development

In the industry, on top of the above mentioned tests, there are also a number of testing philosophies that will drive there tests through different mechanisms the below is a run down of the different categories seen and which goal each one seeks to achieve.

As someone who has seen all sides of the DD debate, here are a few things I've learned over time

BDD: Behaviour Driven Development

BDD is an approach that aims to avoid defects in code by first writing code for tests, which are then removed when no longer required.

BDD will aim to avoid defects in code by first writing code for tests, generally in a humanistic language, which are then removed when no longer required. It's a test-first approach that uses an agreed upon set of steps (often written as steps or scenarios) and the tools to execute them. The goal is to make sure developers are writing code that conforms with what the customer wants or needs.

TDD: Test-driven development

TDD involves developers writing tests before they write any new functionality. Developers write tests to define the desired results/outputs, before writing the code that will deliver those results/outputs.

Test-driven development (TDD) involves developers writing tests before they write any new functionality. Developers write tests to define the desired results/outputs, before writing the code that will deliver those results/outputs.

As with any new software process, TDD has its fair share of critics and proponents. Some argue that it slows down the team's ability to get features out; others point out that it forces you to think through problems better so you're forced not only to think about what your goal is but how you'll reach it — which ultimately helps identify logical flaws in your logic and avoid dead ends when possible.

DDD: Data driven development

DDD involves gathering data from your top customers. This data can be used to build better products and make your development process more efficient.

Data driven development (DDD) is a software development process that uses data to drive the development process. DDD uses the data gathered from the wider data sources of your company, which can be used to build better products and make your development process more efficient.

Typically the process starts with gathering customer data from your top customers using a variety of methods including surveys, interviews and other research tools including some nifty coding tools embedded into the website. You then use this information to build products that satisfy their needs and wants most effectively.

The goal of DDD is for you to create high quality software with minimal rework at every phase of its creation. In addition, because it utilises customer input throughout each phase, you'll have much more accurate expectations than those based on conjecture alone.

Security Testing!

Because of the size of the subject of testing on the whole, this post hasn't gone into Security Testing at all, there are so many ways we can bullet proof our code in the Security World, it would further turn this post into an essay. Stay tuned for an upcoming post purely on this subject!

Container Testing!

Another huge subject worth of a post of it's own to scratch the surface of the micro architecture realm! I think a few more blog posts would need to be written on different subjects before we could open this can of worms to look at Service Encapsulation and create controls around what are the required tests to achieve the maximum amount of coverage.

Pipeline ALL the things!

With the rise of automation powering what we do, these chores do not have to be so time consuming on an organisation and can therefore be streamlined into a CI/CD workflow. For example we can create a Jenkins Pipeline that would call the individual jobs expressing each type of test, including security tests along the way. We can have those results vetted and flagged only if there is an issue. If a build has not changed much from it's original (A line in the README.md file) is it then required to involve EVERY busy and highly paid professional to make sure that markdown file doesn't now contain something nasty?

Setting up sensible controls across all of your IT infrastructure is the only way that an enterprise can grow without hindrance.

That was a lot to take in!

...it was! But only scratching the surface, with this post we should now be able to discuss various types of testing available from a high level perspective as we dive down deeper in to more in depth technical documents to come.