Archive for the Software Testing Category

« Previous Entries
16 07 2010

What I learned from my puzzle exercise

Posted by: Ben Kelly in Software Testing

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.

Comments 5 Comments »

09 07 2010

Data driven Selenium in JUnit via @Parameters

Posted by: Ben Kelly in Software Testing

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.

				

				
Comments 1 Comment »


			

				

                                

			        	

                                                07
                                                07
                                                2010
                                        

                                        
My Selenium setup so far

                                        Posted by: Ben Kelly in Software Testing  
                                


				

					
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(“<plugin.configItem1″, “value1″);

user_pref(“<plugin.configItem2″, “value2″);


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.

				


				
Comments No Comments »


			


				

                                

			        	

                                                23
                                                06
                                                2010
                                        

                                        
One for the puzzle nerds

                                        Posted by: Ben Kelly in Everything, Software Testing  
                                


				

					
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?

				


				
Comments 16 Comments »


			


				

                                

			        	

                                                28
                                                04
                                                2010
                                        

                                        
Adventures in GUI Automation – Verification Layer

                                        Posted by: Ben Kelly in Everything, Software Testing  
                                


				

					
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.

				


				
Comments 1 Comment »


			


				

                                

			        	

                                                17
                                                03
                                                2010
                                        

                                        
Adventures in GUI Automation – getting my bearings

                                        Posted by: Ben Kelly in Everything, Software Testing  
                                


				

					
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 </nerd>). 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.

				


				
Comments 6 Comments »


			


				

                                

			        	

                                                27
                                                01
                                                2010
                                        

                                        
How not to start a discussion

                                        Posted by: Ben Kelly in Everything, Software Testing  
                                


				

					
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.

				


				
Comments 1 Comment »


			


				

                                

			        	

                                                11
                                                01
                                                2010
                                        

                                        
There are such things as stupid questions

                                        Posted by: Ben Kelly in Everything, Software Testing  
                                


				

					
I am making an appeal to those out there who are managing testers, or are in a position where their decisions influence testers.


I loosely follow several testing groups to see what interesting conversations are going on. I don’t often participate, mostly because I can’t commit to having the time to finish a conversation. If I can drop a comment I think will be helpful, then I will.


Then there are questions or statements that make me a little upset. I try not to respond because I tend to say things that are unkind. There are some people out there that need help and seem to be unaware of it. If you manage a testing team and you don’t have a lot of experience as a tester, you may be one of them.


The questions that get me irritated are mostly stupid questions asked by people that (according to their listed job title) should know better. Maybe stupid is not the right word. Lazy, ill-informed, ignorant – these are probably better adjectives.


Recently I saw the following questions asked:


How can testing be monitored? How can we measure the performance of testing?


That was it. No context, no qualification, no further explanation. I assert that becasuse of this, they are stupid questions. I suspect what this person meant is ‘how do I gauge the efficiency and effectiveness of the work that my testers are doing?’, but that’s one of many different possible interpretations of the original questions.


Not to mention the fact that I suspect that what this person actually wants is a bunch of numbers they can use to reassure themselves that all is well, or possibly to threaten perceived underperformers with.


I don’t really want to get into a rant on metrics. It’s been done to death by far more qualified people than I (see ‘meaningful metrics’). What I do want to say is that if you are managing software testers and you are asking questions like this, you really should know better. Stop being lazy and educate yourself. I feel sorry for the people working for you.


For people who are managing testers – especially if you do not have experience in software testing, let me pose the following questions to you.


How do you measure the effectiveness of a systems administrator? a business analyst? How do you know when you have someone who is ineffective in these roles?


Both of these roles require quite specific knowledge. There is also a massive amount of variation within the definition of these roles. A sysadmin that works on webservers is likely to have different strengths than one that specialises in SMTP admin. Of course there will be overlap in their skills, but they are different animals. Applying any sort of blanket measurement to them because they share the same title is stupid.


One thing these jobs do have in common (and in common with testing) is that they are knowledge and service related. If the people they are providing a service to are not satisfied, then you have an issue. You don’t go setting up metrics to count how many shell scripts and admin has written. You don’t judge a BA on how many use cases they write. You gauge their effectiveness by how their work is received by their peers and their clients.


Why would it be any different with testing? Testing requires specialised knowledge. How do you gauge the effectiveness of the people doing it? Look at the information they produce. Consult the people they produce it for. Speak with the testers themselves. Is the information useful, or not? Why/Why not? There you go. That’s how you measure the effectiveness of your testing.


Without the qualitative information these people can convey, you can collect all the metrics and numbers you like. You can draw all the conclusions from them you like, but those numbers alone are not enough to make any meaningful distinctions.


Worse still, if you’re judging the effectiveness of a testing effort during a project by things like bug counts and test case coverage, you’re potentially ignoring important information. A simple example – we have X open bugs. So what? What does that mean? So you’ve covered 100% of test cases – what does that mean? What other testing have you done? What did that find? What does that mean?


If you are using numbers as a barbiturate so that you can feel reassured about how the project is going – if you look at the numbers and and nothing else, and you accept them at face value, then you are being lazy. If you don’t have time to dig deeper then that’s a bigger problem, not an excuse.


If I sound a bit defensive, it’s because I am. I’m sick of seeing lazy people give testers a bad name because they don’t understand testing, aren’t interested in learning about testing and yet want to have some way to control testing because that’s how they think it works.


If you manage testers but you don’t trust them to be able to do their job, and if you aren’t willing to learn about the difference between effective testing and ineffective testing then have the stones to step aside from someone that is. You are worse than useless in your current role.You are a hindrance and are in all likelihood making people deeply unhappy.


If you are willing to learn, do try and think it through. What is it you are trying to achieve? Are you doing it because it’s genuinely useful, or because that’s what everyone else seems to be doing? Do some research. Plenty has been written down about it. At least that way when you ask a question, it will be an informed one. When I read questions like the above, here’s how it comes across:  ‘o hai, I ar new manager. Plz hope me teh metriks with xamplez kthxbai’.


I think that as managers of testers, it his high time we raised the bar. We have a duty of care to understand what they do and the challenges they face. To support their work and to maximise the effectiveness of their efforts.If you are not constantly seeking sources to help you do this, then you are doing them a disservice.


If you have your heart set on measurement, then please, at the very least learn the difference between first, second and third order measurement and how to apply them.


Additionally, it’d be a bonus if you understood more about testing and how testing fits into software development (please do your testers a favour and read this book).


Hopefully for you this is the tip of a very large iceberg. If you do these things, you will look back at questions like the ones posed above and wonder how you could ever have been that naieve. If you can cultivate a habit of curiosity and the desire to learn then you stand good chance of becoming the sort of manager your testers need you to be.

				


				
Comments 3 Comments »


			


				

                                

			        	

                                                23
                                                11
                                                2009
                                        

                                        
Lessons Learned in Translation 3

                                        Posted by: Ben Kelly in Everything, Japanese, Software Testing  
                                


				

					
I wanted to tackle something a little heftier than the last post to see if content that was less straightforward to explain was also challenging to translate. I went with lesson 28 – Exploring requires a lot of thinking.


The translation had a few things that were interesting, including the title. I’ll put up the translation, let you formulate your own opinions (and give Japanese readers the chance to tell me that I’ve got it all wrong), then explain what I took form it.




Lesson 28


探求のためには三つの思考法がある。

When it comes to exploration, there are 3 ways of thinking


探求は探偵と同じだ。調査の結果、何が出てくるか全く想像も出来ない。探求は空間内の移動だと思えるとよい。思考法には前向き、後向き、水平がある。

Exploration is the same as investigation. What comes out of the results of investigation is impossible to imagine. You can think of searching as movement through space. Ways of thinking are forward, backward and laterally.


前方思考：既知から未知へ、目の前の事実からまだ見ぬものを探索する思考法である。既知の行為による結果や影響を探索するのだ。

例）　プリントを見る。クリックしたら、何が起こるのだろう？

Forward thinking: From the known to the unknown, from the immediate facts search for the things you have not seen before. Seek out the results or effects of known actions.

e.g.) Look at the print menu. If you click it, what do you think happens?


後方思考：問題や想像から既知へとたどり、推測の正否を確認する思考法である。

例）　文書を印刷する方法があるだろうか。メニューに印刷の項目があるか確かめよう (Solow 1990)。

Backward thinking: from questions or conjecture get to a place that is known. Check the correctness of your guess.

e.g.) document print functionality probably exists. Make sure there is a printing option in the menu.


水平思考：思考の寄り道をしてみよう。思いつきで脇道を探索し、また本筋に戻る (de Bono 1970)。

例）　おもしろいグラフィックだな。よし、何か複雑なグラフィックを印刷してどうなるか見てみよう。

Lateral thinking: Try taking detours in your thinking. Thinking of an idea, investigate side-roads and return to the main thread.

e.g.) That’s an interesting graphic. Right, let’s try printing complex graphics and see what happens.


テストする製品なくても探求プロセス使える。こうした思考プロセスで、一連の文書を探求したり、プログラマにインタビューしたりすればよい。より豊かにより観念化されたモデルを創り上げることによって進歩するのだ。また、モデルを使えば効果的なテストを設計することができる。

Even if you don’t have a product to test, you can still use an exploratory process. Using this thought process is good for exploring a series of documents, or interviewing a programmer. By creating enriched conceptual models we make progress. Also, if you create a model, you can design more effective tests.


Original text


Exploring involves a lot of thinking.


Exploring is detective work. It’s an open-ended search. Think of exploration as moving through a space. It involves forward, backward and lateral thinking.


Forward thinking. Work from what you know to what you don’t know; what you see toward what you haven’t yet seen. Seek ramifications and side effects. Example: I see a print menu item. I’ll click on it and see what happens.


Backward thinking. Work from what you suspect or imagine back toward what you know, trying ti confirm or refute your conjectures. Example: I wonder if there’s a way to print this document? I’ll look through the menus and see whether there’s a print item. (Solow 1990)


Lateral thinking. Let your work be distracted by ideas that pop into your head, exploring tangents and then returning to the main thread (de Bono 1970). Example: That’s an interesting graphic. Hey, I think I’ll print some complex graphics and see what happens.


The exploratory process works even if you don’t have a product to test. You can explore a set of documents or interview a programmer, using the same thought processes. You make progress by building richer, better mental models of the product. These models then allow you to design effective tests.


I got the feeling that the tanslators wanted to make this a little more ‘concrete’ than the original. Not saying they editorialised, but there do seem to be some liberties taken.


My own take is that the original lesson describes one possible way to organise your thinking but isn’t necessarily looking to lock the reader into 3 distinct ways of thinking. There are other ways you could choose to organise your thinking. This translation has echoes of the book title ‘lessons learned’ vs. ‘immutable laws’ – one feels like a coversation (or an argument), the other a decree.


Okay, so I’m projecting a little bit, but I do think the renamed title takes something important away from the lesson. The words are there, the same structure is there, but the meaning I take from the Japanese version is different from the one I take from English.


As an aside, the word they chose for ‘exploration’ was 探求 (tankyuu). The two dictionaries I consulted listed this as ‘quest, search, pursuit’. When I looked for ‘explore’ I got 探検 (tanken). They share the same first character (tan), which means to search for or look for. 求 (kyu) means ‘want, demand, require’. 検 means ‘investigate or examine’. Based on the characters, I’d have thought 探検 was a more fitting choice for ‘exploration’, but perhaps the general usage of the word has connotations of an outdoors expedition. I’m not sure (I’ll ask around).


I think I’ll see what else I can find, maybe try a few lesson titles and see what the differences are there.




When it comes to searching(exploration), there are 3 ways of thinking





				


				
Comments No Comments »


			


				

                                

			        	

                                                14
                                                11
                                                2009
                                        

                                        
Lessons Learned in Translation 2

                                        Posted by: Ben Kelly in Everything, Japanese, Software Testing  
                                


				

					
Here’s my latest foray into re-translation. Actually, this seems to be a pretty good translation of the original text. I suspect what I need to do is find some of the more difficult passages and see what I can find around those. I’ve been looking at the shorter entries to this point because hey – they’re short and my kanji reading is still really slow.


I’ll look to get something a little meatier in my next post on the topic.


Lesson 35




結局、テスト結果は製品に対する「印象」に過ぎない。

After all, test results are only an impression of the product




製品の品質について知っていることは、すべて製品に対する推測に過ぎない。

With respect to quality, what you know about the entire product is just conjecture.




どんなに支持されても正しいとは言い切れない。

However much support  is available, you cannot simply declare it correct.




だから製品の品質状況を報告するときは、どんなテストしたか、テストプロセスから考えてどんな限界があったかといった条件を必ずレポートに付けるべきなのである。

Because of this, when reporting the condition of quality, you should add to the report qualifications such as the kind of testing that was done and any limits to the test process.




Original text:


In the end, all you have is an impression of the product. 


Whatever you know about the quality of the product, it’s conjecture. No matter how well supported, you can’t be sure you’re right. Therefore any time you report the status of the product quality, you should qualify that report with information about how you tested and the known limitations of your test process.



				


				
Comments No Comments »


			


		
		

			
« Previous Entries