I feel life in every breath

I feel life in every breath

Death so far, yet it is set

Not a coward but live in a fear

Eyes so wet, always hold a tear

Peace is all what I seek

Naive wish, make me weak

What’s the truth, who is to care

Deceive is the game all play fair

Though on every step I just fail

Appear so weak and so pale

Build a character is my struggle

Whatever the challenge & trouble

Worthy is every moment we spend

Have to honor the life till the end

Manual vs. Automated Testing

While reading about Manual vs Automated Testing, I came across a good article by "James Whittaker". The title of post is "manual v. automated testing again". The source and article is mentioned below:

Source:
http://blogs.msdn.com/b/james_whittaker/archive/2008/10/29/manual-v-automated-testing-again.aspx


In my Future series I was accused of supporting both sides of the manual v. automated debate and flip-flopping like an American politician who can’t decide whether to kiss the babies or their moms. Clearly this is not an either-or proposition. But I wanted to supply some clarity in how I think about this.

This is a debate about when to choose one over the other and which scenarios one can expect manual testing to outperform automated testing and vice versa. I think the simplistic view that automation is better at regression and API testing and manual is better for acceptance and GUI testing diverts us from the real issues.

I think the reality of the problem has nothing to do with APIs or GUIs, regression or functional. We have to start thinking about our code in terms of business logic code or infrastructure code. Because that is the same divide that separates manual and automated testing.

Business logic code is the code that produces the results that stakeholders/users buy the product for. It’s the code that gets the job done. Infrastructure code is the code that makes the business logic work in its intended environment. Infrastructure code makes the business logic multiuser, secure, localized and so forth. It’s the platform goo that makes the business logic into a real application.

Obviously, both types of code need to be tested. Intuitively, manual testing should be better at testing business logic because the business logic rules are easier for a human to learn than they are to teach to a piece of automation. I think intuition is bang-on correct in this situation.

Manual testers excel at becoming domain experts and they can store very complex business logic in the most powerful testing tool around, their brains. Because manual testing is slow, testers have the time to watch for and analyze subtle business logic errors. Low speed but also low drag.

Automation, on the other hand, excels at low-level details. Automation can detect crashes, hangs, incorrect return values, error codes, tripped exceptions, memory usage and so forth. High speed but also high drag. Tuning automation to test business logic is very difficult and risky. In my humble hindsight I think that Vista got bit by this exact issue, depending so much on automation whereas a few more good manual testers would have been worth their weight in gold.

So whether you have an API or a GUI, regress or test fresh, the type of testing you choose depends on what type of bug you want to find. There may be special cases, but the majority of the time manual testing beats automated testing in finding business logic bugs and automated testing beats manual testing in finding infrastructure bugs.

There I go again, fishing in both sides of the pond.

Exploratory Testing

According to Wikipedia, "Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution". It is further stated that, "Cem Kaner, who coined the term in 1983, now defines exploratory testing as a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project".

Exploratory testing has got an important role in the industry which has grown much mature in the field of software testing. Although all testing to an extent is exploratory but there are various reasons under which exploratory testing becomes a requirement.

In my view, time constraint or short deadlines are important factors giving rise to the need of performing exploratory testing. It is due to short deadline that testers are asked by the management to perform the exploratory testing, as there is not much time to learn the application.

Hiring a testing resource at a critical time may also end up with the resource performing exploratory testing. If hire a new testing resource at a critical time in project, he is usually asked to start with testing the application as soon as he can. So, the tester starts with exploratory testing while also learning the application (by using the application or by reading the learning material).

Exploratory testing is also performed when there is an incomplete or no documentation available. Documentation may include the requirement specifications, user guides or any other learning material.

These are few common reasons and all these make exploratory testing a challenge for the software testers. The challenge for the software testing companies is to select the right person for this job.

Different testers have different skill set and are strong in different domains, platforms and tools. In order to select the right person for exploratory testing, any company should focus on various factors.

These factors may include the previous experience of a software tester. For example, it may not turn out to be a success story with one hires a fresh resource and asks him to perform exploratory testing of a large financial application, as the fresh resource may have difficulty in learning the application along with testing of it at same time. In comparison, if a company hires a resource with previous experience of testing financial applications then this resource can perform much better. Similarly, platforms and tools required to test should also be considered. Selecting the tester who has best match to the required domain, platform and tools, does improve the quality of exploratory testing.

This article does not cover all aspects of exploratory testing.

Reference:

http://en.wikipedia.org/wiki/Exploratory_testing