This week I decided to play a bit with the selenium IDE. So what is selenium IDE? Selenium IDE was developed to allow testers and developers to record their actions as they follow the workflow that they need to test.

The Selenium IDE is basically an add-on to the Firefox browser. You could download it from http://seleniumhq.org/download/. Once it is installed, you can use Alt+Ctrl+s to start selenium.

Once the selenium IDE is open, you could enter the URL of the website you want to test and could click on record. The IDE will now record every action you make on the website. Once you are done, you could stop the recording and click on the play entire test suite button on the IDE  and Selenium would now replay everything you did.

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

The purpose of a unit test is to verify an assumption about the behavior of a software system. And unit tests must be automated so that any assumptions can be verified quickly.

A unit test should also exhibit the following characteristics:

1. It should have fast test execution.
2. A test should not depend on database access or any long running tasks. A test should isolate external dependencies.

A Mock Object is an object that substitutes for a real object. Mock objects are simulated objects that mimic the behavior of real objects. Mock objects allow you to set up test scenarios without using large resources like databases. Instead of calling a database for testing, you can simulate your database using a mock object in your unit tests. This makes tests run faster.

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

This week I was reading a book called Test Driven Development by Viktor Farcic. The first chapter is about why we need TDD.

The book list a few problems that all software developers face. I have listed a few from the book:

• Most, if not all, of your tests are manual, or you don’t have tests at all.
• Automated tests are written and executed when it’s too late for them to provide any real value for the project.
• The maintenance cost is too high.
• Documentation is never up to date.
• Team is spending too much time trying to figure out what some method or class does.

TDD does not magically solve any of these problems, but it sets us in the path toward the solution. TDD speeds up the time-to-market, enables easier refactoring, helps to create better design, and fosters looser-coupling.

The book goes on to explain something called the Red-Green-Refactor process. The procedure is simple:

1. Write a test
2. Run all tests
3. Write the implementation code
4. Run all tests
5. Refactor
6. Run all tests

Speed in key in this process; never spend more than a minute on writing tests or implementation. It’s like a game of ping pong, the game is very fast. Write a short test and run all tests (ping), write the implementation and run all tests (pong). Repeat until it’s time to refactor and confirm all tests are passing (score). It is important to understand that TDD is not about testing, it is a process to develop high quality software fast.

The two really interesting side effects of TDD are Executable documentation and No debugging. In TDD the tests serve as the documentation. If wan’t to find out what a particular method does, read the tests associated with it. This solves the problem of out of date documentation.

The second side effect is that we almost never need to debug applications we’re working on. We almost never debug because there is rarely a reason to debug. When the tests are written before the code we can have high confidence that the code is working as expected. And since we build the software in very small steps, any errors that might occur is very easily resolved.

I went on to read and follow chapter 3 and it really helped me improve my understanding of TDD.

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

This week I read the first chapter of a book called Introducing Maven(by Balaji Varanasi). Maven makes software development much easier; there are 2 main benefits that Maven provides.

1. Standardized directory structure
2. Declarative dependency management

For me the most useful feature of Maven is its standardized directory structure for projects. It is much easier for me to navigate through different projects if they all share the same structure.

Dependency management is feature that automate dependency management. Instead of manually downloading dependencies and keeping track of their versions, we could use Maven to do it for us. Information regarding the project dependencies is stored in the pom.xml file. The pom.xml file stores the what not the how. Maven then automatically downloads the dependencies and allows us to use it in the project.

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

This week I came across an article called Why Test Engineers Should Learn Groovy (http://testerstories.com/2013/08/why-test-engineers-should-learn-groovy/).

Groovy is a lightweight, object-oriented language that runs on the JVM and it follows Java semantics. It is particularly useful for writing test scripts. The one thing that I really liked was how little typing I needed to get something done in Groovy compared to Java.

Take the following Java code for example:

public class Greetings {

public static void main(String[] args) {

for(int i = 0; i < 10; i++) {

System.out.println(i + “,”);

}

System.out.println(“Testing Groovy”);

}

If the code above is saved in a file with extension .groovy, you could run it by saying groovy fileName.groovy  (you do have to install groovy first). You could compress the Java code above into:

for(int i = 0; i < 10; i++) {

System.out.println(i + “,”)

}

System.out.println(“Testing Groovy”);

This code does the exact same thing as the first code, but with a lot less lines. Groovy does not require you to have all logic within a class. And notice, Groovy does not require semicolons after statements. This code can be compressed even further:

for(i in 0..9)  { print(i + “,”) }

println(“Testing Groovy”)

Groovy makes life a lot easier, everything does not need to be enclosed within a class or enclosed within a main method within a class.

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

This week I read an article called When to Stop Testing (Exit Criteria in Software Testing). The article talks about when to stop testing a software product.

No matter how much we test we can never be absolutely sure that the product is bug free. There is no methods that we can use to prove that a software product is absolutely bug free. The only thing that we can do is iteratively test for all possible defects. However, testing costs money. So when do we stop? Do we stop when we run out of money? Run out of time? Have reach a certain number of bug count? Have fixed a certain number of bugs?

The following are the factors to consider when deciding to stop testing.

Testing can be stopped when:

Requirements:

• 100% Requirements coverage is achieved.

Defects:

• Defined / Desired Defect count is reached.
• All Show Stopper defects or Blockers are fixed and No known Critical / Severity 1 defect is in Open Status.
• All High Priority defects are identified and fixed.
• Defect Rate falls below defined acceptable rate.
• Very few Medium Priority defects are open and have a workaround in place.
• Very few low priority open defects that do not impact software usage.
• All High Priority defects are re-tested and closed and corresponding Regression scenarios are successfully executed.

 Test Coverage:

• Test Coverage should be 95% achieved.
• Test case Pass Rate should be 95%. This can be calculated by formula
  • ( Total No of TCs Passed / Total number of TCs ) * 100.
• All critical Test cases are passed.
• 5% Test cases can be failed but the Failed Test cases are of low priority.
• Complete Functional Coverage is achieved.
• All major functional / business flows are executed successfully with various inputs and are working fine.

Deadlines:

• Project Deadline or Test Finish deadline is reached.

Test Documents:

• All Test Documents / deliverables (Example – Test Summary Report) are prepared, reviewed and published across.

Budget:

• Complete Testing Budget is exhausted.

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.