Abhishek Verma invited you to Dropbox

	Abhishek Verma wants you to try Dropbox! Dropbox lets you bring all your photos, docs and videos with you anywhere and share them easily. Get started here. - The Dropbox Team
	To stop receiving invites from Dropbox, click here. © 2011 Dropbox

Google Adsense Major Mistakes

Keep In Mind Ten Major Mistakes Before Creating Google Adsense Account:

Before create an adsense account realize and keep in your mind these below major mistakes.

1. Don’t click on your own ads on your computer system. Because 70% of the websites has been banned because of clicking their own ads. In Google’s terms it’s called ‘Invalid Clicks’.

1. You should find information regarding the black listing before creating new adsense account. It will make you further complicated to carry on in Google, certainly it will banned your account 100%.
2. One account is sufficient for several websites suppose, you have one hundred websites. Google has given the permission to place your ads on any website or blog.
3. Don’t use the convincing words that compel the visitors to click on them.

For example:

• Click Here
• Useful links
• Click and Win

Suitable words are:

• Advertisement.
• Sponsored By.

5.    Your website should be use Google recommended language. (Google Does Not Support Urdu language.)

6.    You should provide your adsense JavaScript code to anyone through, E-mail Because Google have a profound observation on Emails?

7.    You should not display adsense on a Popup window because Google rigorously disallow such activities.

8.    Place your ads on such webpage which has content, data or information.

9.    You should not locate your ads on such a page where you are asking and filling information from visitor such as:

• Application Form
• Registration Form
• Login Page etc.

10.   Stay away from using such kind of tools that clicks automatically on your ads. Google has deep observation on these tools.

For instance:

• Auto Clicker
• Click Sensor

James Bach on Software Testing

The Seven Basic Principles of the Context-Driven School

1.    The value of any practice depends on its context.

2.    There are good practices in context, but there are no best practices.

3.    People, working together, are the most important part of any project's context.

4.    Projects unfold over time in ways that are often not predictable.

5.    The product is a solution. If the problem isn't solved, the product doesn't work.

6.    Good software testing is a challenging intellectual process.

7.    Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.

Illustrations of the Principles in Action:

·         Testing groups exist to provide testing-related services. They do not run the development project; they serve the project.

·         Testing is done on behalf of stakeholders in the service of developing, qualifying, debugging, investigating, or selling a product. Entirely different testing strategies could be appropriate for these different objectives.

·         It is entirely proper for different test groups to have different missions. A core practice in the service of one mission might be irrelevant or counter-productive in the service of another.

·         Metrics that are not valid are dangerous.

·         The essential value of any test case lies in its ability to provide information (i.e. to reduce uncertainty).

·         All oracles are fallible. Even if the product appears to pass your test, it might well have failed it in ways that you (or the automated test program) were not monitoring.

·         Automated testing is not automatic manual testing: it's nonsensical to talk about automated tests as if they were automated human testing.

·         Different types of defects will be revealed by different types of tests--tests should become more challenging or should focus on different risks as the program becomes more stable.

·         Test artifacts are worthwhile to the degree that they satisfy their stakeholders' relevant requirements.

An Example:

Consider two projects:

1.    One is developing the control software for an airplane. What "correct behavior" means is a highly technical and mathematical subject. FAA regulations must be followed. Anything you do -- or don't do -- would be evidence in a lawsuit 20 years from now. The development staff share an engineering culture that values caution, precision, repeatability, and double-checking everyone's work.
 

2.    Another project is developing a word processor that is to be used over the web. "Correct behavior" is whatever woos a vast and inarticulate audience of Microsoft Word users over to your software. There are no regulatory requirements that matter (other than those governing public stock offerings). Time to market matters -- 20 months from now, it will all be over, for good or ill. The development staff decidedly do not come from an engineering culture, and attempts to talk in a way normal for the first culture will cause them to refer to you as "damage to be routed around".
 

·         Testing practices appropriate to the first project will fail in the second.

·         Practices appropriate to the second project would be criminally negligent in the first.

 

Commentary

In the years since we first published the description, above, some people have found our definition too complex and have tried to simplify it, attempting to equate the approach with Agile development or Agile testing, or with the exploratory style of software testing. Here’s another crack at a definition:

Context-driven testers choose their testing objectives, techniques, and deliverables (including test documentation) by looking first to the details of the specific situation, including the desires of the stakeholders who commissioned the testing. The essence of context-driven testing is project-appropriate application of skill and judgment. The Context-Driven School of testing places this approach to testing within a humanistic social and ethical framework.

Ultimately, context-driven testing is about doing the best we can with what we get. Rather than trying to apply “best practices,” we accept that very different practices (even different definitions of common testing terms) will work best under different circumstances.

Contrasting context-driven with context-aware testing.

Many testers think of their approach as context-driven because they take contextual factors into account as they do their work. Here are a few examples that might illustrate the differences between context-driven and context-aware:

• Context-driven testers reject the notion of best practices, because they present certain practices as appropriate independent of context. Of course it is widely accepted that any “best practice” might be inapplicable under some circumstances. However, when someone looks to best practices first and to project-specific factors second, that may be context-aware, but not context-driven.
• Similarly, some people create standards, like IEEE Standard 829 for test documentation, because they think that it is useful to have a standard to lay out what is generally the right thing to do. This is not unusual, nor disreputable, but it is not context-driven. Standard 829 starts with a vision of good documentation and encourages the tester to modify what is created based on the needs of the stakeholders. Context-driven testing starts with the requirements of the stakeholders and the practical constraints and opportunities of the project. To the context-driven tester, the standard provides implementation-level suggestions rather than prescriptions.

Contrasting context-driven with context-oblivious, context-specific, and context-imperial testing.

To say “context-driven” is to distinguish our approach to testing from context-oblivious, context-specific, or context-imperial approaches:

• Context-oblivious testing is done without a thought for the match between testing practices and testing problems. This is common among testers who are just learning the craft, or are merely copying what they’ve seen other testers do.
• Context-specific testing applies an approach that is optimized for a specific setting or problem, without room for adjustment in the event that the context changes. This is common in organizations with longstanding projects and teams, wherein the testers may not have worked in more than one organization. For example, one test group might develop expertise with military software, another group with games. In the specific situation, a context-specific tester and a context-driven tester might test their software in exactly the same way. However, the context-specific tester knows only how to work within her or his one development context (MilSpec) (or games), and s/he is not aware of the degree to which skilled testing will be different across contexts.
• Context-imperial testing insists on changing the project or the business in order to fit the testers’ own standardized concept of “best” or “professional” practice, instead of designing or adapting practices to fit the project. The context-imperial approach is common among consultants who know testing primarily from reading books, or whose practical experience was context-specific, or who are trying to appeal to a market that believes its approach to development is the one true way.

Contrasting context-driven with agile testing.

Agile development models advocate for a customer-responsive, waste-minimizing, humanistic approach to software development and so does context-driven testing. However, context-driven testing is not inherently part of the Agile development movement.

• For example, Agile development generally advocates for extensive use of unit tests. Context-driven testers will modify how they test if they know that unit testing was done well. Many (probably most) context-driven testers will recommend unit testing as a way to make later system testing much more efficient. However, if the development team doesn’t create reusable test suites, the context-driven tester will suggest testing approaches that don’t expect or rely on successful unit tests.
• Similarly, Agile developers often recommend an evolutionary or spiral life cycle model with minimal documentation that is developed as needed. Many (perhaps most) context-driven testers would be particularly comfortable working within this life cycle, but it is no less context-driven to create extensively-documented tests within a waterfall project that creates big documentation up front.

Ultimately, context-driven testing is about doing the best we can with what we get. There might not be such a thing as Agile Testing (in the sense used by the agile development community) in the absence of effective unit testing, but there can certainly be context-driven testing.

Contrasting context-driven with standards-driven testing.

Some testers advocate favored life-cycle models, favored organizational models, or favored artifacts. Consider for example, the V-model, the mutually suspicious separation between programming and testing groups, and the demand that all code delivered to testers come with detailed specifications.

Context-driven testing has no room for this advocacy. Testers get what they get, and skilled context-driven testers must know how to cope with what comes their way. Of course, we can and should explain tradeoffs to people, make it clear what makes us more efficient and more effective, but ultimately, we see testing as a service to stakeholders who make the broader project management decisions.

• Yes, of course, some demands are unreasonable and we should refuse them, such as demands that the tester falsify records, make false claims about the product or the testing, or work unreasonable hours. But this doesn’t mean that every stakeholder request is unreasonable, even some that we don’t like.
• And yes, of course, some demands are absurd because they call for the impossible, such as assessing conformance of a product with contractually-specified characteristics without access to the contract or its specifications. But this doesn’t mean that every stakeholder request that we don’t like is absurd, or impossible.
• And yes, of course, if our task is to assess conformance of the product with its specification, we need a specification. But that doesn’t mean we always need specifications or that it is always appropriate (or even usually appropriate) for us to insist on receiving them.

There are always constraints. Some of them are practical, others ethical. But within those constraints, we start from the project’s needs, not from our process preferences.

Context-driven techniques?

Context-driven testing is an approach, not a technique. Our task is to do the best testing we can under the circumstances–the more techniques we know, the more options we have available when considering how to cope with a new situation.

The set of techniques–or better put, the body of knowledge–that we need is not just a testing set. In this, we follow in Jerry Weinberg’s footsteps:  Start to finish, we see a software development project as a creative, complex human activity. To know how to serve the project well, we have to understand the project, its stakeholders, and their interests. Many of our core skills come from psychology, economics, ethnography, and the other socials sciences.

Closing notes

Reasonable people can advocate for standards-driven testing. Or for the idea that testing activities should be routinized to the extent that they can be delegated to less expensive and less skilled people who apply the routine directions. Or for the idea that the biggest return on investment today lies in improving those testing practices intimately tied to writing the code. These are all widely espoused views. However, even if their proponents emphasize the need to tailor these views to the specific situation, these views reflect fundamentally different starting points from context-driven testing.

Cem Kaner, J.D., Ph.D.
James Bach

How to spot a tester in a...

Whenever you're testing, make sure you know why you're testing!

Agile Testing by Elisabeth Hendrickson

Elisabeth Hendrickson on Agile Testing from Google 

Excellent talk. Elisabeth is one of the best speakers.

[GoogleTechTalks]

-------------------------------

Becoming an eXpert in Testing without wOrking hard and in 8 Simple Steps

The experts with whom you may interact in forums and on blogs, paint a picture of an expert that makes you believe you need hundreds of years of experience to actually become one. Trust me; they are trying to fool you to help them retain their own status as experts.

You see people like James Bach talking about skills like cognition, lateral thinking, confusion as a good thing, and other blah blah blah, making you think that a tester is a superman who needs to test software at the Andromeda Galaxy within microseconds before the galaxy is sucked by a black hole. Next on target is the other guy, what’s his name? Ah, Michael Bolton, who travels around the world teaching Rapid Testing pretending as though it needs some mental martial arts practice to become a Rapid Tester.

I have been their student and I can safely tell you that what they teach doesn’t make you an expert tester. In many worst cases I have witnessed, it has made their audience, student of testing craft forever. The world could have had many experts today but experts like those mentioned above have ensured that only they retain the status.

Who wants to be a student of the testing craft when there is an option to become an expert? I went to those guys wanting to be an expert and they converted me to a student of the craft. Guess they were afraid of my ability to overrule them as an established expert in this field. Luckily, the most important thing about their training was to use brains, question and test. Use lateral thinking skills and read books like Blink and study general systems thinking. I used the skills I gained from it and escaped from being a student. I am glad to announce to the world through this blog post that I am an established expert. It’s been years since I talked to them and I feel happy about it.

So, what’s my expertise?

I am an expert who introduced the Black Viper Testing Technique & Selphar Box of techniques for testers to this world. Needless to say that without the BVTT & Selphar Box of Techniques (short form: SelBox Testing) testers all across the globe would have not found many bugs.

My current area of research is Rhino Hunt Testing. When I shared the area of research on twitter, some experts got jealous of me and tried misguiding me asking if I was researching on One Horn Rhino or Two? Then another expert chipped in to misguide me further by asking if the One Horned Rhino was male or female?

For the context of this article, my new expertise is to help people become experts without having to work hard. Unlike James or Michael, you are in safe hands.

Pre-requisite

1. You must have worked as a tester for a couple of years with some big companies like Microsoft, Google, IBM, Infosys, Wipro, CTS (whatever)
2. You must have a blog
3. You must be on an interview panel for your organization or you interview testers
4. You could also be a testing coach or trainer.

Step 1:

Once you have that…

Think about an animal or a bird type which is not yet used in testing, be it White Mamba, Giraffe, Elephant, Blackbuck, Spoon bill, Parakeet, Dolphin…

If you want to be more imaginative, you may want to think of insects or reptile families like Spider, Tarantula, Gnat, House Fly, Mosquito – Dengue type, Mosquito – Chikun Gunya type…

Note: Monkey, Guerilla, Snake and Rhino are already in use and introduced by other experts. Don’t copy or if you want to, please owe them necessary credits.

Step 2

Once you fix upon an animal, bird or an insect in mind start to think about the connection between them and testing and form a new technique.

Suggestion / Tip based on experience: It is at this moment, you must start making notes. 

For example:

If you are going to think about spider, you can think of a technique where testers behave like a spider, first weaving the web (tests) and then waiting for the bugs to be caught on it, while staying at the centre. Once in a while when there are enough bugs to report, the tester moves from the centre and captures those bugs. If the web is destroyed, move on to make another web.

Note: Don’t use the above published example. Someone may google and find out that you are a fake expert.

Step 3

Write a lengthy explanation of your technique and use words and terms that confuses the reader.  For example use words like: Neil Bhors effect, indemnification against ramification, trapezium syndrome, Wurtz Fittigs reaction… that are not often used and even if Googled, people can’t understand what it means.

Experience based tip: If you are married, ask your spouse to read it, and if you hear, “Honey, this is awesome”, you are publishing ready.

Step 4

Publish it on your blog

Most important note: You shouldn’t do the marketing for your blog post.

Step 5

Ask all those testers whom you interview if they know the technique you published in your blog post and reject them if they didn’t. Do this over a period of six months to at least about 100 testers.

Now what those 100 testers will do is to first go Google your technique and try understanding your blog post. As you have obfuscated it, no one would get it, so they would ask experienced testers and experts in forums and groups that claim to discuss testing. The ego of experienced testers and so called experts wouldn’t let them say, “I don’t know this” but instead, they would offer their own explanations to it.

Step 6

Apply to testing jobs and attend interviews. If the interviewer is asking you to explain your own animal / insect / bird technique to you, tell to yourself, “Congratulations!”

Step 7

Quit your job and start writing to conference program chairs telling them you would be willing to do a half day or a full day tutorial on this famous technique. Say it was the “Snake in the Eagle’s shadow technique” you introduced, you could do a one day tutorial and charge as much as what ISTQB training costs.

Some conferences will give you a chance to keynote and from there you are a hero.

Step 8

Consider publishing a book with your technique. Hang out with other bloggers at conferences, buying them beer and tweet saying, “I am meeting @this_tester and he is so cool” or “This guy is one hell of a tester”. They would be so pleased that they would go back and write blog posts on your keynote and technique.

That’s all. No rocket science. By the way, this actually works. Have you been interviewed and been asked about the Monkey, Guerilla, Rhino, Snake, Yellow, Blue, White, Black?

Oops, I left my one horned male mutated rhinocerous testing technique research midway. I am speaking at CAST 2011 and hope to catch you all there. Apparently, James was the Conference chair and he didn’t give me the keynote.

About the author

Pradeep is an awarded thought leader, renowned author, invited writer and speaker around the world. Pradeep is the co-founding Director at Moolya Software Testing Private Limited which aims to be the most preferred testing vendor of the world. Pradeep’s consulting stories, test reports and experience reports have fascinated many people across the world. He has consulted for product startups, small to medium size software organizations, and multi billion dollar, euro and pound organizations, too. Pradeep's Tester Tested! blog is one of the widely influential and read blogs in the industry and his blog posts in Moolya’s blog is catching up to speed.

Agile Testing

Agile testing does not emphasize testing procedures and focuses on ongoing testing against newly developed code until quality software from an end customer's perspective results. It is built upon the philosophy that testers need to adapt to rapid deployment cycles and changes in testing patterns.

A Brief JUnit tutorial

This is a brief video on how to use the JUnit open source unit testing framework for Java. By using JUnit, you can assert that methods in your Java code work as designed, without the need to set up the complete application.

Web Service Testing with soapUI

For a few years now I have used the open source application soapUI to simplify Web Service testing. Both to test services that I have written and to test external services that I have had to consume. In this post I'll cover the basic types of testing you can do with soapUI and provide some practical tips on how to use soapUI when working with Web Services. If you don't want to go through the detailed examples I suggest jumping straight to the Practical Tips section at the end.

Getting Started

After downloading and installing soapUI the easiest way to get started is to create a new project from an initial WSDL or WADL. For demonstration purposes I'll use the free Weather Web Service at http://www.webservicex.net/globalweather.asmx. We will create a test for each operation in this SOAP Web Service. We will also create a Test Suite, that allows us to run all our tests at the click of a button. Furthermore, we will create a Load Test for our Test Suite and a Mock Service to simulate the functionality of the Web Service.

To do this go to File and select New soapUI Project. Populate the New soapUI Project screen in the following manner and click OK:

Basically, paste the URL to the web service WSDL file into the Initial WSDL/WADL field and additionally check the field to generate a MockService. SoapUI will now load the Web Service definition and ask you questions about how to create the MockService:

For this demonstration change the path to "/WeatherMock" and check the Starts the MockService immediately checkbox, but otherwise accept the defaults. After clicking OK, specify the name of the Mock Service as "Weather MockService" (or a name of your choice) and click OK again.

This will complete generating artifacts for the SOAP 1.2 version of the GlobalWeather Web Service.

Next you will be asked the exact same questions, for the SOAP 1.1 version. Since we don't plan to use SOAP 1.1 you can just hit Cancel. (I haven't found a way to configure soapUI to only generate artifacts for SOAP 1.2. If you know how to, please let me know! :)

Running Tests

To execute a given test, drill down to the requests that soapUI auto-generated and insert values that make sense for the given Web Service operation. In our case, in the Navigator on the left, click on GlobalWeatherSoap12, then GetCitiesByCountry and then double-click on Request 1.

We'll set the Country name as Iceland and then hit the green arrow button to execute the test.

Voila, you should get results back from the Web Service, a list of Icelandic cities. To check if the Web Service response is valid (conforms to the WSDL), right-click in the results window and click Validate.

Lets give this test the name "City Test". (Right-click Request 1 and select rename)

Then do a similar test for the GetWeather operation. Click on GetWeather and then double-click on Request 1. Put in "Reykjavik" for CityName and "Iceland" for CountryName and run the test. Also rename the test to "Weather Test". After running the test, the results should look something like this:

Build a TestSuite

Now that we have created two tests, lets add them to a TestSuite so we can easily re-run them at any time. In the Navigator on the left, right-click GlobalWeatherSoap12 and select Generate TestSuite. Select Use existing Requests in interface, and check Generates a default LoadTest for each created TestCase and Single TestCase with one Request for each Operation:

After clicking OK give the TestSuite the name "Weather TestSuite". Double-click on GlobalWeatherSoap12 TestSuite under Weather TestSuite to show the TestCase editor.

Then click the green arrow button to run the TestSuite. If all goes well you should be presented with a results-screen like this, indicating a successful test run:

If the TestSuite run fails you'll see FAILED at the top instead of FINISHED and you should get a message explaining why a given test failed.

Add Assertions

To make the tests more meaningful lets add some assertions to validate the responses from the Web Service we are calling. You do this by opening up the test Request Editor (double-click on a given test step under TestSuite in the Navigator) and then click the plus-sign next to the green arrow button (second from the left).

For both tests lets add the assertion called SOAP Response, to ensure the Web Service is returning a valid SOAP response. Then add the assertion called Response SLA and specify the response time as 2000 ms. That basically means that we are going to consider the test a failure if we don't get a response within two seconds. Lastly, lets add some content validation by selecting a Contains validation. For the GetCitiesByCountry operation add the string "Iceland" as the content to expect in the response, and for the GetWeather operation add the string "Success".

Then run the TestSuite again to make sure you get success-results.

Run a Load Test

When we created the TestSuite in last step, we told soapUI to generate a Load Test as well. You'll find it under the TestSuite in the Navigator on the left, under the heading Load Test. The default name is LoadTest 1. Double click on it in the Navigator to open it up. Before running the LoadTest you can tweak such parameters as number of concurrent threads to run, length of the test-run, and delay between tests. Once you have made the desired configurations hit the green arrow button to run the Load Test:

In this sample, 5 concurrent threads are running the TestSuite for 60 seconds with a random wait of up to 1 second between the start of each test.

You can track the progress of the load test with the progress bar in the upper right corner. If it reaches a 100% without reporting any test errors you are good to go.

Use the Mock Service

Back when we imported the Weather Web Service we told soapUI to generate and start a Mock Service. That service can now be accessed at http://localhost:8088/WeatherMock. This is convenient for example if you are developing against a Web Service that has been designed (WSDL/WADL available) but not yet implemented. Then you can have the Mock return an actual Web Service response to test your code even though the actual implementation hasn't been completed. A default response has already been generated (under WeatherMock Service, GetCitiesByCountry, and Response 1), which you can edit as you like.

You can also have the Mock service return different responses depending on which request it receives. To demonstrate this, lets create two new MockResponses for the GetWeather operation:

• Click on GetWeather under the Weather MockSerive in the Navigator and select New MockResponse.
• Give it the name "ReykjavikWeatherResponse". Accept the automatically generated response, but put the value "Reykjavik" in the GetWeatherResult tag. (Or even better copy the actual response from calling GetWeather for Reykjavik, which should give you a fully valid response).
• Create another response called AkureyriWeatherResponse and put the text "Akureyri" in the GetWeatherResult tag.

Now put logic in the Mock service for when to return each response:

• Double-click on GetWeather in the Navigator to show the MockOperation Editor.
• Select ReykjavikWeatherResponse under MockResponses.
• Select QUERY_MATCH under Dispatch.
• Click the plus sign to add a new match.
• Give it the name "Reykjavik".
• Select Reykjavik and then populate the XPath value with:

                  declare namespace web='http://www.webserviceX.NET';

                  declare namespace soap='http://www.w3.org/2003/05/soap-envelope';

                  /soap:Envelope/soap:Body/web:GetWeather/web:CityName

This XPath query will grab the value from the CityName tag.

• Under Expected Value enter "Reykjavik".
• Under Dispatch to, select ReykjavikWeatherResponse.
• Repeat the same steps to create a Match that returns AkureyriWeatherResponse when the city name in the request is Akureyri.

Now you can test your mock Match-logic by opening up your GetWeather test and adding http://localhost:8088/WeatherMock as the endpoint to use (select the current endpoint in the dropdown and pick add new endpoint...). Then run the test and play around with changing the city name in the request to get different responses from the Mock service.

Additionally, if you want to test your client-side error handling you can have soapUI generate a soap:Fault response and have your Mock return it. You do that by creating a MockResponse and then clicking the apostrophe icon in the MockResponse Editor. Then edit the auto generated response as appropriate.

Practical Tips: What to use soapUI for

Now that we have covered the basics of soapUI, here are some practical tips for putting it to use during your software development.

Test Web Services You Have to Consume

When consuming external services, before delving into code, use soapUI to "kick the tires" of the Web Service. This especially applies when consuming newly written services. Rather than potentially spending hours pulling your hair over why your client code isn't working, spend a few minutes with soapUI validating and getting familiar with the Web Service you are about to consume. In particular:

• Create and run simple tests for key Web Service operations
• Make sure there are no security/access problems
• Is the web service using some proprietary authentication protocol (NTLMv2 comes to mind) that might give you trouble during implementation?
• Have soapUI validate that responses conform to the Web Service contract (WSDL/WADL)
• Visually inspect responses
• Do they make sense or are they some illegible auto generated garble that should really be cleaned up and restructured by the Web Service developer?
• Do the responses meet your needs?
• Test a few boundary cases
• Does the Web Service implement proper error handling? Or does it blow up with an HTTP 500 error or some non SOAP compliant text message? Does the level of error reporting meet your needs?
• Add all your tests to a TestSuite. That way you can quickly "ping" the Web Service to make sure everything is working on the other end. When a problem arises, taking your code out of the loop is a good way to make sure the issue is on the remote end and not with your own code.

When developing against a newly written external Web Service, it is very rare that the Web Service works 100% out of the box as expected. There is usually a fair amount of communication needed between the Web Service developer and the client-side developer to tweak things until the Web Service works as needed. By using soapUI, you can inspect the Web Service right at the time it is delivered to you, and quickly spot things that may need to be fixed. I usually take 5 or 10 minutes to do so and almost always have a list of things that need to be modified. The response time for getting those changes implemented is usually very short, as the Web Service developer is still engaged in the project and things fresh in his mind. If I don't get back to him/her until some weeks later when I finally get around to implementing my client-side code, the other developer has probably moved onto other things and/or forgotten why he implemented the service in a certain way.

Lastly, if you have received a WSDL/WADL file, but the service hasn't actually been implemented, and you NEED to start implementation against the service (not ideal), then consider using soapUI to create a Mock service from the WSDL/WADL file. That way you can have your code hit the Mock service and at least get some preliminary feedback on whether your client code is working. Since creating a Mock service is really a breeze with soapUI it can sometimes be more practical than implementing Mock objects in your code.

Test Your Own Web Services

When writing a Web Service for others to consume it can be handy to have a soapUI TestSuite to sanity test your service. Of course you should still write unit and integration tests for your code, but having a good soapUI TestSuite can be quick and easy way to find out if all your services are running as expected. When you get that 4 AM phone call saying that something is broke, fire up soapUI and at the click of a button sanity test all of your Web Service operations. If you are smart, you'll hand the TestSuite over to a support team so that you only get woken when the issue truly is on your end ;-) Just make sure to add proper assertions for Web Service responses and include SLA assertions to test that things are not running dead slow.

If you are concerned about the performance of your Web Service or whether it can handle a given load, then a soapUI Load Test can be a convenient way to test that. Set the number of threads to imitate the expected number of concurrent users for your service and add SLA assertions to make sure all requests are handled in a timely fashion. Of course generating all the load from a single machine does not quite imitate real traffic, so for truer numbers consider having coworkers assist you in running simultaneous Load Tests from multiple machines.

You Can Download the older versions of 'SoapUI' from here

Testing becoming the fastest-growing niche within the IT space

Joe A Scaria, ET Bureau Aug 17, 2011, 11.21pm IST

For long the poor cousin of software development, the testing function is forcing its way into the limelight, say software companies. And that trend happens to coincide with testing becoming the fastest-growing niche within the IT space.
Technology company officials say that the biggest difference in recent times is a surge in interest among youngsters to choose testing as a career, as against companies having to push a few staffers into the testing function out of necessity.
"The turn of events leading to an increased interest in testing has been quite dramatic", says Ranga Reddy, CEO of Maveric Systems, an independent software testing major based here. "Even up to the year 2000, testing was almost like an after-thought, and having no specific budgets".
Sumithra Gomatam, senior VP and global head of testing practice at Cognizant, says there has been a significant growth in the testing function over the past five years. "We are very committed to growing this business", says Gomatam, and Cognizant has seen its employees in the testing function grow from 4,000 at the end of 2004 to more than 17,500 now.
Cognizant is also reaching out to engineering college students, providing them awareness about a career in testing by getting experienced hands to interact with the students. Within the company, testing has turned one of the fastest-growing practices.
Krishna Prasad, general manager of UST Global says "Many customers are looking for vendors to provide independent verification and validation (IV&V) services which are separate from the development process. This has led to a surge in demand for QA and testing services and fuelled the growth in testing-focused jobs. As a result, engineers with functional, technical or performance expertise are seeing QA and testing as a viable career path."
Maveric's Ranga Reddy says the software testing industry is growing at 20%, making it the fastest growing niche in the IT space and that the near-term prospects look good because the testing vertical is becoming more mature and an increasing share of testing work is being outsourced by companies in the West.
Reddy says traditionally, 80% of software development work was being outsourced, as against only about 30% of the testing work. "With an increased need to effect cost savings, a larger share of software testing work is also being outsourced", says he.
A recent Nasscom report on the software testing market says the global testing market was worth $30 billion in 2010, and that India's share of it was $3.2 billion. According to the report, export revenues and the number of employees in the software testing industry have doubled over the past four years.

Steve Jobs’ Advice for Software Testers

Actually, in this 2005 commencement speech for Stanford University, Steve Jobs offers timeless advice for people in all professions. But seeing how this is a software testing blog – and seeing how Jobs has recently stepped down as Apple’s CEO – it seemed fitting to post these words of wisdom with our testing audience in mind.

My favorite quote from this speech: 
“The only way to do great work, is to love the work that you do.”

Happy testing!