Skip to main content

So, Different types of testing!

It is clear that software development cannot exist without testing. However not all those who need testing understand exactly what kind of testing will be appropriate. Let’s try to understand.
Below are some types of testing:
1) Let’s start with Goal-driven testing. In this type of testing all tests that should be done proceed from the goals. There are actually 4 goals:
  • Requirements-driven testing. In this type of testing, all conducted tests are designed in such way to show that all of the requirements have been tested at least one time.
  • Structure-driven testing. Conducted tests in frames of this type of testing are aimed to detect as much bugs of software’s logical structure as possible. Structure-driven testing should not replace requirements-driven one, it should supplement it.
  • Statistics-driven testing. Here, tests are conducted in order to convince the user that sufficient testing was applied. After this kind of testing, customers should understand if the software is ready for use or not.
  • Risk-driven testing. In this case, a sufficient number of tests is conducted to make sure that the software will be able to go through all failure scenarios.
2) There is also Phase-driven testing. There are three kinds of phase testing examined below:
  • Unit testing is testing of the smallest components which form software together.
  • Integration testing aimed to insure that the components play together as a whole.
  • System testing deals with the integrated software working in the total system.

But who should perform all these kinds of testing?

The software developer is usually responsible for unit-level testing, developers and independent testers usually conduct integration testing together, in turn system testing is conducted sometimes by system engineers and by independent testers. It is worth noting that if the statistics-driven and requirements-driven testing do not require a deep knowledge of the software internal workings, then for conduction of risk-driven testing and structure-driven one involved specialists need to have such knowledge. Therefore, while such types of testing are conducted developers are often involved.

Comments

Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:


As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …

Leeds Testing Atelier - April 2018