testjutsu

What I learned from my puzzle exercise

Ben Kelly — Thu, 15 Jul 2010 14:44:50 +0000

I’d like to say thank you to everyone who participated in this little puzzle exercise and most especially to everyone who provided feedback. I hope you had fun with it. Well done again to Rushmila Islam who was the first to work out the puzzle.

I have posted .the solution at the bottom of this post. YOU HAVE BEEN WARNED.

I learned a lot more than I thought I was going to. Firstly and probably the most obviously, I learned a lot about cryptography that I didn’t previously know. Thanks to James Bach for the collection of links.
Braingle was probably the best of the bunch. Thanks also for the link to Sebi’s puzzle.

I found Jürgen Plasser’s answer fascinating. I hadn’t encountered measuring entropy of text as a way to inform possible encryption techniques. It’s something I’d like to look into further.

It was interesting to see how close people got with their responses. Many people had several correct pieces of the puzzle, but not quite enough to solve it completely.

I think most people gave me way too much credit for the amount of crypto knowledge I’d have had as a high-school student. I didn’t have access to teh intarwebs back then, and time that I could have spent in the library was more likely to be spent playing role-playing games or painting miniatures or similar valuable life skills.

One of the things that this puzzle made abundantly clear to me was the value of information before and after it becomes known. Without the key information, it was a real puzzle. Far more so than I had originally anticipated. Having all the information at hand, the puzzle seems obvious and simple in hindsight.

It drove home for me just how difficult it is to convey the value of a tester to those who don’t understand what good testers do. Even the distinction that testers are a source of information (so is a book. so what?) doesn’t necessarily convey the effort that is involved at producing this information.

Some people went to a great deal of effort; tried some very cool things. That was the most gratifying thing for me. The answer was ultimately irrelevant. I got to see how you guys think. As testers, we are often showing others the fruits of our effort, but not the beauty of the effort itself. Having been able to do that here, at least in part, I think is pretty cool. Thank you again to everyone who shared.

SPOILER ALERT – Explanation of the cipher follows.

The message was encoded with direct character substitution with a few added extras. The message reads top-down, right to left. The first two characters provide the character offset – character 1 – character 2 = offset.

The spaces themselves mean nothing, but exist primarily for obfuscation though I did put them in diagonally in the first puzzle to give a clue to the direction of the word flow. Spaces in the actual message are represented by vowels, so in this sense, vowels do double duty in that they can represent their offset character or a space.

Data driven Selenium in JUnit via @Parameters

Ben Kelly — Thu, 08 Jul 2010 14:38:19 +0000

I played around a bit with iteration using JUnit today. I have some generic tests that behave differently depending on the values fed to them. I don’t want to have iteration code living alongside each test (maintenance nightmare), so I wanted to use JUnit’s @Parameters tag to pull in my test data via a Preferences file and do the iteration for me.

It took me longer than I expected to get right, mostly because static methods annoy me and trip me up a bit. (Your parameters method must be static in order for it to work).

However, get it working I did. On the off chance that it saves someone else some time, here’s how it works:


import java.io.InputStream;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Enumeration;
import java.util.Properties;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

@RunWith(Parameterized.class)
public class paramTest
{
	final static String dataFile = "/dataDriver.txt";
	private String words;

	public paramTest(String words)
	{
		this.words = words;
	}

	@Test
	public void verifyThing() throws Exception
	{
		System.out.println("key: " + words);
	}

	@Parameters
	public static Collection data()
	{
		Collection returnList = new ArrayList();
		InputStream dataStream = paramTest.class.getResourceAsStream(paramTest.dataFile);
		Properties dataProperties = new Properties();
		try{
			dataProperties.load(dataStream);
		} catch(Exception e)
		{ System.out.println(e);}

		Enumeration e = dataProperties.propertyNames();
		while (e.hasMoreElements())
		{
			returnList.add(new Object[]{dataProperties.getProperty((String) e.nextElement())});
		}
		return returnList;
	}
}

Interestingly enough, the data comes back in the reverse order that it exists in the preferences file. Something to keep in mind if you want your tests to run in a certain order.

My Selenium setup so far

Ben Kelly — Wed, 07 Jul 2010 11:04:14 +0000

I’m having a lot of fun with this Selenium gig (shh, don’t tell anyone). There have been a few yaks shaved and I’ve seen the inside of some rabbit holes, but there seems to be a lot of good material online to guide you.

At this point, I’m running my tests directly from eclipse, though we’ll be looking to kick them off with Ant in the near future. I’ll jump off that bridge when I get to it.

LoggingSelenium
I’ve set up loggingSelenium to log test execution. I’m not sure what its current development / support status is over at SourceForge. The documentation it comes with is not real flash, but there’s a decent example here (via here). I have made a couple of custom modifications to the source of loggingSelenium as there are a few gripes that I have with it.
Some of the pluses are:

it will automatically grab screenshots for you when your scripts bork.
it color-codes your asserts and failures
it can wrap JUnit asserts and log them alongside your selenium commands.

Some of the not-so-good things are

it requires a hardcoded path for writing output
it looks like it’s geared to non-windows systems, given that out of the box, the screenshot links in html output don’t work.
the color of failed selenium asserts is different to JUnit asserts, the former being an easy-to-miss beige color.

The mods I made were quick and dirty hacks, one to fix the screenshot link and the other to make the beige color more noticeable. If I find myself with a spare second I want to get rid of the need to use a hardcoded path, or at least make it more nicely configurable. I also want to add a color selector so you can customise your output.

Autodocumentation
I’ve set up doxygen to generate documentation from code comments. I’ve not hooked it up to anything yet, but either an SVN pre-commit hook or getting ant to kick it off shouldn’t be a problem.

Test Structure
JUnit 4 does not require you to extend tests from a test class, which is quite nice, actually. Instead, I have written a parent class for my tests to extend from. The parent holds all of the setup and most of the methods that drive the tests themselves.

Currently I’m writing one test per class. The class contains a single method containing calls to methods in the parent and nothing else, so it ends up looking like a set of test case steps. The parent has the potential to get quite big, so as test case numbers grow, it’s likely that I’ll add further abstract classes between the current parent and the tests to group them more reasonably.

I’m importing data via Properties as a resource stream. I have data that is used to drive the tests and data that is variable, but predictably constrained. For instance, I use a vehicle class number as a driver. The class number refers to a class of vehicle whose data is stored against that number. Depending on the number selected, different vehicle data is populated during setup.

On the subject of Properties – If you’re developing in a language that uses double-byte characters (such as Japanese), if you are generating your Properties files as flat files, you’ll need to run native2ascii on them to convert your double-byte code to unicode. Otherwise, they will not be properly interpreted and things will fall over.

I have just started playing around with the @Parameterised tag and @RunWith(Parameterized.class) to get iteration working with data variation. I haven’t decided quite how I’ll run with that yet. I could do this at a suite level and control iterations of tests by feeding data to them, or I can have each test take care of its own iteration by setting up parameterisation within the tests’ parent class.

Browser setup
I’m doing mobile emulator testing at the moment, so I’ve set up a firefox profile specifically for it. I’m using the user.js file to alter the plugin config so that the browser starts up with the plugin activated and a particular device switched on.

When starting seleniumRC, I specify this browser profile specifically so it is automatically used when firing up the browser. I was hoping to be able to change device type on the fly by mucking around with chrome urls, but I’ve not found an elegant way to do this yet. Instead, I am swapping the user.js file out whenever I need to change. Essentially, you can load up the user.js file with calls to your plugins to switch them on/off and configure them based on what configuration the plugin makes available.

It’ll end up looking something like

user_pref(” user_pref(”

You can hunt down config items by typing about:config into your browser. Any config item that is not set will be invisible however, so I ended up looking through the plugin’s jar file to see what else I could see.

So at this point, I have a loose collection of parts that are not quite all tied together but it’s getting there.
Other things I’m contemplating in the not too distant future is a web front-end so non-technical testers can select test suites and kick them off at will.

While I haven’t gone into code-level specifics, the links should provide a fair amount of detail. Let me know if there’s something I’ve not explained so well. If you have comments or questions re any of this, I’d love to hear it.

One for the puzzle nerds

Ben Kelly — Wed, 23 Jun 2010 10:20:29 +0000

In the spirit of recent puzzles/challenges, I thought I might throw in one of my own. In high school, my class was given an exercise to come up with a coded message that the rest of the class would have to work out the cipher to.

I didn’t take it that seriously at the time and put in some sort of lame effort at home that afforded me the most time in front of the Commodore-64 instead. Most other kids did the same. Clearly the teacher had been hoping that someone in the class was a secret genius and would put together something brilliant. His disappointment when this did not occur was palpable.

I got thinking afterward that it was a wasted opportunity. I quite like puzzles, I like being creative, but I’d never put the two together. I spent a little bit of time coming up with something that might have been worthy of the assignment. I never did anything with it, or showed it to anyone, but I was reasonably sure that no one in that class at least would be able to figure it out. I should have put my money where my mouth was then. I might have been able to turn a profit betting people they couldn’t solve it in a given time limit. Ah well, hindsight is 20/20 as they say.

Instead, I present my code and the message it contains and invite you to work out the key. If you do figure it out, please don’t post the solution, but I’d be really interested to hear about how you went about attacking the problem, so by all means leave a comment.

The message: the quick brown fox jumps over the lazy dog

IMPORTANT EDIT: In a moment of paranoia I double-checked my key and noted that there is a small change to the decoded message. In the coded text, ‘jumps’ is actually ‘jumped’. To those of you who have started, I apologise profusely. This means that there is an extra letter to the message than you thought you were dealing with, and rather than an ’s’, you have a ‘d’ and an ‘e’.

The revised decoded message is:

The message: the quick brown fox jumped over the lazy dog

The coded message:
n g o c w u o y j r
f l l l q m v e k
o i y k b v r x a
k s e a t d i b o
v h a v e u i p l

edit: James Bach has rightly pointed out that I could have worded my challenge a little more clearly.

There are an infinite number of keys that can associate your output with your input. For instance, the key might be simply to look at the first letter in the top left, and “n” means “quick brown fox…”

My intention is that people would attack this problem as though they did not know what the message was in an attempt to resolve the letters presented into the answer provided. I had a particular key in mind when I put it together, so the letters do resolve into the message given.

Enjoy.

Update
Okay, so a few people have asked for hints.
Here’s the deal – I’ll post a few hints, but I’m curious to know what you’ve tried and what you thought. I’ve posted one hint below. I will post more, but I’d like to know – How did you approach the problem? What strategies did you employ? What effect did the hint(s) have?

Hint 1

There are red herrings

Hint 2

There is a hint in the layout

Hint 3

Some letters are overloaded (have more than 1 meaning)

Congratulations to Rushmila Islam, who has at least worked out the message component, if not the complete cipher (which is trivial once the message is in-hand). Here’s another pangram (one with all the letters this time).

The coded message:
k e i f v a l p q u w
b m a g n z i e c e

m g d r w o o t a h
y j a w u x a g e s

I kinda wish I’d put this one up first now. It looks trickier
Rushmila (or anyone else) – care to post the decoded message?

Adieu to QTP. Now for a closer look at Selenium

Ben Kelly — Mon, 21 Jun 2010 15:40:06 +0000

To borrow from Groucho Marx – QTP, I’ve had a wonderful time, but this wasn’t it.

So thankfully I’ve been able to step away from QTP for the moment. Given that QTP doesn’t recognise Firefox so well after v3.6, and since we use a firefox plugin for most of our mobile testing (FireMobileSimulator), yours truly gets to switch to Selenium instead. I’m thankful for having had the opportunity to work on QTP, mostly so I have a better understanding of its limitations and shortcomings. I can argue more coherently against what seems to be in most cases, a ridiculous waste of money.

I view QTP a bit like one of those unfortunate bears in a Chinese bile farm. You can see how at birth it had the potential to be something majestic and powerful, but instead it languishes in a cage, irreparably twisted and deformed by years of abuse by the ignorant.

In comparison, Selenium while not without challenges of its own, has been by and large a real joy to use. For starters, having any number of fully fledged languages to work in is almost unbelievable after having toiled in VBScript land for far too long. In fact, the first problem I faced was which language do I go with?

I ended up choosing Java and JUnit, mostly because it’s what the current dev team codes with, and I simply cannot be arsed copping the flak I would get from management for introducing another language into the picture (as wonderful as jruby and jython are, I’m sure).

I didn’t realise quite how much thinking in VBS had stunted my thinking in other languages. I do a bit of coding in my spare time, but as far as automation coding goes, it took me a good few days to get comfortable again remembering the power that a real language gives you. I was all set to start importing test data from excel when a timely tweet (and subsequent blog post) from Adam Goucher reminded me that Java has these nifty things called Properties that you can import. (This is why tools like twitter should be allowed in the workplace btw – okay my RSS reader would have picked it up, but not before I’d wasted a lot of time).

It’s been a bit over 3 years since I last looked at Selenium. It doesn’t ‘feel’ all that different, but it does seem a lot easier to work with than I remember it being. Within a couple of days I’d whipped together a script to cut down some checks that took 4 hours manually to a little under 2 minutes. W00t.

I added loggingSelenium to my test setup and now have some pretty colours that light up for people who are impressed by that sort of thing. I’m now in the process of putting together a few more tests and a framework that will support them and their inevitable expansion.

There are a bunch of setup how-to’s out there, so I won’t be doing that, but I will drag together some of the more useful links that I’ve found. Stay tuned

Adventures in GUI Automation – Basic Hierarchy

Ben Kelly — Thu, 06 May 2010 10:24:07 +0000

On the suspicion that my last post amounted to a bunch of word salad for a few, let me see if I can add some clarity by describing the basic hierarchy I’m using for my framework.

At the top level, I have a suite control script that looks like this:

doSetup ‘Calls to set up data and environmental variables and such like

Call Script1
Call Script2
…
Call Script n

Each script that is called is some sort of major transaction that an end-user would recognise.

If you missed the update I made to my last post, I’ve moved a number of function libraries to classes to lessen the amount of coupling required between the ValidationManager and the scripts. There is a small overhead involved in that the relevant class has to be instantiated at the start of the script. For debugging purposes, I have also added a commented-out debug section that calls the setup function that the suite control script does. Each script looks a bit like this:

‘#begin debug
‘doSetup ‘uncomment this if debugging this script
‘#end debug

Transaction = loadTransaction ‘This is the instantiation of the class that holds the Transaction’s functions

Transaction.function1
Transaction.function2
SharedFunction
Transaction.function3
…
Transaction.function n

For functions that are shared across multiple transactions, I have left them as a standard function library. On the plus side, the Transaction namespace aids clarity and lets you know where your functions live. On the downside, you can no longer access them by using the right-click->go to function definition option. No biggie imho.

The transaction classes aren’t that much different from your standard function library other than the fact that they’re wrapped in a class definition and there’s a bit of setup stuff at the start.

Class Transaction

Dim VerificationManager

Private Sub Class_Initialize()
VerificationManager = loadVerificationManager ‘Here’s where the verification manager is instantiated
EndSub

Public Sub Function1
do.something
VerificationManager.CalculateExpectedState(”someAction”)
do.someAction
VerificationManager.Verify(”someAction”)
do.somethingElse

End Sub

…

End Class

I’ve still not gotten the all-clear to post the verification manager code, but as mentioned previously, it is a class also. There are 4 methods; 1 for setup and 3 relating to verification.

CalculateExpectedState calls a file called “someAction”. someAction calls a setup routine that creates a new dataSheet, also called someAction and populates it with expected data.
Back in the class method, the action takes place, at which point we return to the verification manager when Verify is called.

Verify calls the someAction file which calls a second routine that gathers data from the app and does any calculations required and stores the results in the someAction dataSheet. Verify then calls a diff function that compares the expected and actual results and reports. Finally, verify calls UpdateMasterData, which compares the actual data with the master data sheet and replaces anything that was changed.

At this point, there is a new data sheet created for each different call to the verification manager. This has the potential to get out of hand as the number of verification points increases. I’m thinking of using a single sheet and dumping the results to a file at the end of each verification. I’ll see what else occurs to me as I go.

I promised to talk a bit about what I’m doing with data. I still need to cover that. I’ve been having fun trying to define heuristics to govern where the data should drive the scripts and where I should handle variance programatically. I think I have something that works. We shall see.

Adventures in GUI Automation – Verification Layer

Ben Kelly — Wed, 28 Apr 2010 09:14:44 +0000

One of the things I really like about the Logical Functional Model is the concept of removing verification code from the execution code. Another is updating verification data on the fly to reduce the likelihood of false positives.

These concepts are especially appealing since QTP’s in-built verification method is not worth using. Verification points are script-specific. You can’t update and re-use them multiple times within a script or share them across multiple scripts. Maintenance nightmare.

Instead, what I have done is to write a custom verification layer. Here’s how it works. At the start of my control script, I instantiate the VerificationManager, which is a class I have written to take care of verification code.

If a function that I am executing needs to do any verification, I pass the class to it by reference UPDATE: I’ve switched how I call this now. I’ve turned function libraries into classes. Each class instantiates the VerificationManager as part of its own setup and the functions can then call the VerificationManager without having to handle it as a parameter. There are several reasons for this – I’ll go into these in an upcoming post.

Within the function (now class method), there are 2 calls to the VerificationManager, one to set up the expected data and another to retrieve the actual data.

Where you call these depends on what setup you need to do beforehand. If you’re getting expected values from the application under test, you’ll want to do so before you execute the code you want to verify. If you’re grabbing your expected data from the data table, then you can do it just before you call the code to retrieve the actual data.

That probably looks like word salad on first read through. If you haven’t already, I strongly suggest you take a look at the verification chapter in Michael Hunter’s description of the LFM. It took me a couple of read-throughs to really get it, but once I did, I was impressed.

How does the VerificationManager work?
It’s as generic as I can make it. It has 4 methods.

CalculateExpectedState(someAction)
Verify(someAction)
Diff
UpdateMasterData

CalculateExpectedData and Verify both make calls to files called StateGenerators. It is the role of the StateGenerators to hold the logic and fetch the data required to do the verification. In simple terms, they are function libraries that are loaded at runtime by the VerificationManager.

You’ll notice that the parameter for each of these methods is the same. They call the same StateGenerator and this parameter tells them what name to look for. The VerificationManager loads the StateGenerator specified and executes one of two functions – either a ’setExpectedState’ or ‘getActualState’ function.

Each call to the verification manager will use a different name. There will be one StateGenerator for each call. The StateGenerators all have 2 functions, all of them identically named. What they contain differs based on what they need to verify. There might be a series of calls to the global data table to grab data that needs to be checked, or there could be logic to calculate an expected value from a set of other values.

The setExpectedState function creates a new data sheet to hold expected data. If any of this data comes from the GlobalDataTable, then the new data sheet has an identically named column. Likewise if there are any new columns that need to be added to the Global data table for future reference, then this happens here too.

Once the code to be verified has executed, the call to Verify happens. Verify grabs expected values from the application under test and adds them to the second line of the expected data column. It then calls Diff, which (as the name suggests), compares each value of row 1 with the values in row 2.

The diff method logs both successful comparisons and failures by making a call to the standard QTP reporter. Right now, I’m going for simplicity; there’s a lot more you could do with this if you wanted. You could add weights to each verification item and log a severity message based on the weight of the failed item. You could call a custom reporter (which is a good idea, given that any time you tell QTP of a failure, it treats the entire script as failed). You get the idea.

Lastly, the Diff method calls UpdateMasterData. This routine simply loops over any difference and checks the global data table for columns of the same name. If they exist, the global data table is updated with the new value, so that if any comparison is made against it later in the script, it will be made against what we see in the system during this run.

I’ve asked my current employer for permission to post the code, as it’s completely abstract and contains no proprietary data. No word on whether they’ll go for that yet, but if so, I’ll update that here. Hopefully there’s enough here already to be useful.

Adventures in GUI Automation – getting my bearings

Ben Kelly — Wed, 17 Mar 2010 10:05:49 +0000

So I mentioned some of the inherent issues that I dislike about QTP 10. One of those appears to be that reusable actions intermittently fail. An action in QTP is a tool-defined item that collects a number of GUI manipulations (or function calls) into a named action. It sounds handy. It probably would be if it worked reliably, but it doesn’t – at least not for me. The other thing is that if you have reusable actions (let’s say for instance that you keep your common ones in a single file and call them from other files), you cannot modify those actions without first closing your current test file and opening the one where the action is defined.

Instead, I have organised my scripts into a series of user-centric actions, which I have defined as functions in function libraries. To be clearer, each function executes a series of steps in the gui that an end-user would recognise as an action. e.g. log in, navigateToQuotationScreen and so on. This seems to work pretty well. I end up with a QTP screen that looks like a high-level checklist of how to execute a particular workflow. You do not have the editing restrictions that you do with reusable actions, as you can have as many function libs open as you like.

Neato. So I’ve been using the record tool to get something that works. Mostly because I dislike VBScript. I think it’s the Orcish of programming languages (Maybe not even that. Maybe it’s Kobold ). The recording tool creates a bunch of objects and sticks them in the object repository. That’s fine, saves me having to do it myself. Drawbacks to this are that for dynamically created objects, you may end up with a bunch of identical objects with different names. Not too hard to figure out, given that you should be naming your objects something sensible anyway. You can weed out the dupes when you do this and update your script accordingly. I’m definately going to check out Albert Gareev’s suggestion of dynamically loaded object repositories. That sounds quite handy. I will say though that at the moment I’m being assisted by some not-so-technical testers who I am weaning away from the keyword view and the active screen.

The recording tool doesn’t always use the best code for the job. It’s the same old story – want the job done right? Gotta do it yourself. After the initial script is in place, I’ve been reading through the code and separating it into user-centric actions. At the same time, I look for:

places where the code can be optimised
places where data should be dynamic
any fluff commands that QTP put in
potential duplicates in the OR

At this point, what I’ve ended up with is having a series of user-centric ‘tests’ – I’ll call them transactions. Each one is an action (as every QTP test has 1 action by default), but consists of a series of calls to function libraries. Each function is named for a step that a user might consider part of the transaction. For example, if we were talking about a program that provides a quote for car maintenance, the list of function calls might look like this:

enterVehicleDetails
selectServiceTypeAndLocation
selectPreferredDates
completeQuotation

Each of these functions lives in an associated function library. These functions may in turn call helper functions (such as date/time functions to enter date ranges in the future). Each transaction hides the ugly details of what is going on under the hood and while you don’t get to use the ‘keyword view’ anymore, you do have a clearly labeled set of steps.

So at this point, I have some scripts. They work. They’re not robust and they don’t do any data verification to speak of, but it is a beginning. Next up – parameterization and making use of the data table.

Adventures in GUI automation

Ben Kelly — Fri, 05 Mar 2010 09:50:39 +0000

So I’ve been hacking away at QTP for the last couple of weeks (no, I didn’t make the decision to purchase it, yes I have to use it as the political consequences of not doing so are more painful).

I’m not a massive fan of QTP, mostly because I think that it’s really bloody cheeky for a company to charge six figures for a product because of its feature richness, then charge 5 figures for training because it’s so complex that no one can use the damn thing, not to mention that all the official written how-to information is safely tucked away behind a walled off site, available for those who pay their support fees. For the same price HP charge for basic QTP training, I could fly any world-class tester out here for a week to hang out with me and my team. I know which option I’d get more value from.

Luckily there are plenty of useful sites out there maintained by QTP users, which is handy because if your support fees are not paid up, you get bugger all from the source.

QTP 10 has some inherent bugs that annoy me and I’m still dubious about how well the shared object library will work for me in the long run, but leaving the ranting and bitching aside, I should say that it does seem to be doing what I tell it to most of the time.

I’m attempting to implement Michael Hunter’s Logical Functional Model (which I think is really bloody clever, btw) as best I’m able. It’s still early days yet, but we’ll get there. I do run into problems a lot, largely because if my inexperience with the tool, but perhaps some good will come of it if I share my pain with you I’m going to post bits and pieces that I discover, just in case they’re useful to others. I don’t know how well QTP will fit the LFM, but I’ll see what I can do about documenting my progress with that as well.

For the moment, here are a few links that I have found useful:

The SQA forums QTP FAQ
CodeWanker (love the name)
Sachin Dhall’s QTP blog
Dmitry Motevich’s blog (vlog?) QTP How-to movies

There are a few others out there, but they’re full of ISTQB ads, so I don’t really feel like linking to them. I’m sure you understand.

How not to start a discussion

Ben Kelly — Wed, 27 Jan 2010 00:07:35 +0000

I gues I must be feeling punchy lately. No new content here for a little while, but I felt the need to respond to someone who linked to one of my posts. What I probably should have done was commented here and sent a pingback, but does anyone click on those anymore?

I digress.
Marcin Zręda has written an article that describes his conclusions from his experience with ET. The problem is, these conclusions are not presented as conclusions of his experience, they are listed as things that are good and bad about ET (with a line about them being drawn from his experience buried in the first paragraph).

I wrote a lengthy reply which I think should serve to counter most of the the errors he has made in describing ET. Marcin has mentioned in the comments that the article was to serve as a jumping off point for discussion. In my opinion, this will likely have the desired effect, but misrepresenting experience as fact is one way to get people off on the wrong foot when having dialogue with you.

In this case, rather than wanting to know more about Marcin’s experiences, I wanted to correct what I saw as horribly misleading statements about ET. Now that I see he was trying to engender conversation, I am disinclined to continue.

‘I have these experiences with ET – what do you think? How does your experence compare?’ – sets a much different tone than ‘here are some good and bad things about ET’ (followed by a list of flame bait)’. I think that as testers we have a duty to be better than that. If you want to have a discussion about testing, or even an argument about it, there are plenty of people out there to have those kinds of discussions with, but be up-front about it. Be open about it and you will likely find that you will both learn more and keep your credibility intact.