What is Software Testing - Information Technology

What is Software Testing

if your programmer you probably know what it's like to you know go through the whole process of writing a program and then testing it you usually test your program in what I would consider a pretty intuitive a pretty unguided manner you just basically walk through the program and see if it works but have you ever wondered how testing is done on larger scale projects you know for example an operating system like windows we wouldn't expect them to actually walk through the program bit by bit to try and look for errors so how is it done we're going to do is we're going to take a look at some of the principles that go into formal testing and we're going to take a look at how larger projects actually make use of these principles we're going to look at some ways of rigorous testing we're gonna see how exactly it works and what schools it exists at you know when we are writing our own little programs it's called exploratory testing as its name implies we're just exploring but just you know sort of moving our way through the program and try to see if we can find any bugs obviously there are some pros and cons to this method get' father just being that well it's simple and easy to do you can do it as long as you know you're the one who's written the program you'll know where to go what to look out for this also helps in a sense that the obvious bucks those things that are immediately visible from the point of view of a user can be found very quickly because you are essentially putting yourself in issues of a user some disadvantages of this method could be difficulty in reproduction that is you may have done a whole bunch of things that lead up to a bug that maybe later on you wouldn't be able to reproduce exactly and as a result debug actually disappears all the conditions around it change so there is always a lot of uncertainty regarding bugs found in this manner and secondly there isn't a lot of coverage in formal terms coverage is defined as how many lines of code you are actually able to test when we are doing exploratory testing we might miss out areas of code you know we might miss out entire operations and as a result areas of code just don't get tested we lose out on coverage so yeah knowing why exploratory testing isn't great let's take a look at some fundamentals on actual rigorous testing methods and actually the first thing we want to quantify is what we are actually doing in the first place you know what's the objective of testing as it turns out really the intention of testing is to make sure that the program actually conforms the requirements and expectations that's it and that is what you've been subconsciously doing as you are doing exploratory testing so with an understanding of this you know key principle we can move on to

see how large-scale projects actually do testing as it turns out they actually do testing using an automated method so how do you test your expectations using an automated method turns out it's very simple you take a chunk of code be a function being a class basically you expect it to take some inputs and produce some output so all you have to do is to construct some input in which you know what kind of output it will produce through this input at the code and look at what output it produces compare it against the output you've expected and if they match everything is working fine if they don't your expectations are being violated and that indicates a bug somewhere the key to writing good automated test simply in changing that input to you know taking account as many cases as possible for every piece of code will want to try several different inputs on it we want to make sure that good input is accepted run to ensure that you know bad input is rejected we want to ensure that inputs at a boundary of good and bad are being handled appropriately and finally we want to make sure that completely invalid inputs don't crash a system your system is able to you know show some kind of error but doesn't actually accept the value software packages exist out there to make your life easier when you're doing automated testing basically it mix setting up and tearing down much easier it can also provide some kind of interface to show you how many tests have been run how many have passed how many are filled and where the issues up what you're seeing on screen right now is the test package called g-unit running within the Eclipse IDE and yeah as you can see it takes one click to start the unit tests everything is run it tells you how many tests have passed and how many have filled this makes it very easy for you to do your testing you can do testing very often and you can catch issues early which is always nice now testing exists on several scopes we can do what is known as unit testing and that works in a system that can be modularized what that means is we can actually break our system down into little components and what we want to do is run a test just each one of these components on their own that's what a term unit meets in a worse unit testing generally when we're performing unit testing we want to make sure that we are only looking at that unit itself we don't want to actually take into account any possible issues from other sources so what we do is for all the other modules that this particular unit and the test is communicating with we want to replace them with stubbs instead of running that full logic we just replace them with something simple that way we eliminate all sources of error except for within that unit and their test itself this of course makes finding issues much easier because we can just you know home in on the unit up so that was unit testing and while that is great eventually we will want to make sure that all these individual units can play nice with each other this is when we move on to what is known as integration testing where we actually test several of these modules together of course it's probably not advisable to do this before we've done thorough unit testing but once we sure that all the individual units are working fine we can test the whole lot together and if we find any issues we can be reasonably confident that it lies in the communication between those modules as opposed to the modules themselves now while automated testing is great you know it makes things much faster it's very easy to use we have to be aware of one basic pitfall and that is the fact that automated testing doesn't help us find new bugs all it can do is to make sure that thing's actually conform to our expectations nothing more nothing less if we test often during the development phase all they're doing is guiding ourselves against what is don't s regressions regressions refer to you know when something is right originally and then you know

you do something later on that breaks it this is when our original expectations which were once fulfilled now become violated we want to make sure that that doesn't happen which is why we keep testing to make sure that you know everything is working as we expect but that's it that is the limitation of you know automated testing and if we want to actually find bugs that come up from use will actually have to use the program will have to perform exploratory testing of some kind now we're almost done yet but i do want to bring up some related terms that may interest you the first of which is security testing security testing is an interesting way of doing automated testing on a program but SS name implies what we are trying to do is we're trying to make sure that our program is secure one interesting way in which this is done is actually by what's known as fussing fussing is when you actually just throw a lot of random input at some kind of input area you know like a fault and we want make sure that the program is able to gracefully handle this so what you're seeing here is the login form of one of the projects I've worked on in the past it's being bombarded by just randomize inputs you know it's just a little autohotkey script I've written to do that and yeah as long as the program holds up you know everything is working fine the whole reason why we are using randomized strings instead of something that we've set its because well whatever we said is something we've expected so this is actually testing against things that we cannot imagine is thinks that is completely randomized and not expected and the program still needs to work under these conditions here's another testing related tub test driven development also known SPD d now TVD actually gives us a very different perspective on you know the workflow of writing a program it basically says that we can only write code in response to failing unit tests what is visas at a very beginning to even start you need to write a test first then watch it fail and then write code to address it until it passes and write no more code than that the next thing you want to do involves creating another unit test so this is very interesting because it actually puts testing first you want to make sure that everything you write has a corresponding unit test to back it up it's a very interesting approach to writing programs I've got to confess I've never really done serious PDD before but it looks like a very good practice and looks like something that you know you should do if you want to be very sure that your program will work right...