Quality assurance (QA) involves maintaining a desired level of quality in a product or service through attention to every stage of production or delivery. Automated testing is important for QA because it allows for more tests to be run than would be possible through manual testing alone. Automating tests reduces the costs associated with testing by allowing many more tests to be run each day compared to manual testing.
3. The maintenance of a desired level of quality in a service or
product, especially by means of attention to every stage of the
process of delivery or production.
http://www.oxforddictionaries.com/us/definition/american_english/quality-assurance#quality-assurance__3
24. CRISPIN, Lisa; GREGORY, Janet. Agile Testing: A Practical Guide for Testers and Agile Teams. Estados
Unidos da América : Pearson Education, 2008.
Unit
Integration
Functional
Tests are pretty much related with QA, so first we have to understand clearly what is QA?
You don’t want to delivery softwares like this. Do you?
I’m pretty sure you don’t want to have any kind of surprises when developing new features or refactoring old codes to fix a bug or improve performance.
So to make sure you have your QA guaranteed you’ll have to execute tests in each piece of your code so you don’t face an explosion. ;)
Ok, lets consider this. A person is able to execute 5 tests scenarios per hour.
And this person costs for the company US$ 20,00/h
Considering that a product has 300 tests scenarios.
So, if the person is able to execute 5 tests/h and cost US$ 20,00/h, means that 300 testes scenarios will cost US$ 1200,00 to be executed once.
Ok, let’s say you don’t want to run all the 300 scenarios several times per day, you’ll probably run it just on the end of the day work day within a week of 5 days.
That will cost US$6000,00 to be executed. Expensive, don’t you agree?
Now, consider you’re running it for all the weeks within a month. Now you can see the cost of running tests.
But if we could automate it. Let’s now consider that one developer/tester could write 3 automated tests per hour (which I don’t believe is the case, we can write more than that).
It will cost US$2000,00 to write all the same 300 tests scenarios
And if we want to execute all the test once or thousands of times per day it will still cost the same that was paid already to develop them
Comparing how much it will cost to run 300 tests scenarios 5 times per week. Wow, how enlightening!
So, drawing it so we can understand that if we want to guarantee the QA of our product, it will be way more cheaper to automate as maximum as possible the tests.
Wow, but now that you draw the costs I figure out that it’s too complex to write tests for our application, and manual tests are too expensive, so I just run our test scenarios once a few times.
Ok, that means you are risking to have to redo a lot of work. But ok, that’s your call to make. ;)
I just want to warning you that you could make your team crazy with all the details that they’ve to remember when dealing daily basis with the code, because the minor change in the code could means a lot of dangerous refactors and uncatch side-effects that will appears just on customer’s face.
Well, if by now you’ve understood the importance of testing your application and do it in an automate way, let’s understand the ways to test your application.
According to Agile Testing book, there are mainly 3 levels of tests that could be automated or not.
But, let’s focus on unit level.
What is a unit?
This is your software looking from outside, I mean, from User perspective.
This is your application, looking a little more deeplier. Your application is a bunch of components (soap operations, restful services, EJB, etc)
When you get closier to the components, you can see that their behavior are build over a lot of classes, methods, etc.
Those little piece of your application are the easiest to test, since they could be isolated of the other interactions and dependencies, like DB, VMs, Cloud services, email, etc.
Did you noticed that JS is almost in every device today? No. So take a few minutes researching in Google about it. From TV to freezers you’ll see JS everywhere.
So the importance of test JS is getting more visibility. Don’t you agree?
Even considering you’ve a web application composed by Java, PHP, Ruby, Python, whatever in backend, you’ll probably have a lot of presentation logic which is been done in JS, and you’ll also probably wanna make your webapplication interactive, which you can be done by doing ajax requests, again JS logic. That means, JS have is important piece of your application, because is JS which will make the UX better and smother.
That being said, who to test JS?
There is a lot of frameworks around this subject, but we stick with Jasmine which is a BDD framework and is also the most famous testing framework in JS world.
Jasmine allows you to write test cases and nesting it within a human readable description.
The same for the tests.
All tests are composed by 3 parts, doesn’t matter if it is BDD or not.
Scenario preparation, is where you setup everything that will be required for execute the stimulus of your test or even for the assertion.
Stimulus, is the action you wanna tests. You just call it, passing to it all the dependencies you might have configured on the scenario preparation phase.
Assertion, when you verify the result of the tests.