Your browser does not support iframes.

This is inspired by the Jon Bach’s post http://jonbox.wordpress.com/2010/06/08/the-right-combination/. But as my previous star drawing puzzle, it generally uses the ideas from my games played with James Bach.

The mission is pretty simple. Use the hints from left side to enter the proper combination in the right side. Once you got it you will have a confirmation message.

If you need another combination to generate reload the page.

If you found the solution please don’t send it directly in the comments.

Good luck and enjoy!

我看到这是某种流行创造有时一个101名单，因此我认为，我将创建一个自己。

这份名单是有关条款的困难，其中大部分在测试民俗，招聘广告，一些相关的有些失败，但在有关的测试一般的话。

1。测试仪

2。质量保证

3。测试案例

4。测试计划

5。硒

6。自动测试

7。 Pyhon

8。编程经验

9。敏捷

10。白盒

11。黑盒

12。灰箱

13。验证

14。验证

15。软件质量保证

16。 GUI测试

17。单元测试

18。集成测试

19。系统测试

20。回归测试

21。验收测试

22。 alpha测试

23。 Beta测试

24。性能测试

25。负载测试

26。稳定性测试

27。可用性测试

28。安全测试

29。国际笔会（渗透）测试

30。国际化与本地化

31。无损检测

32。烟雾测试

33。特设测试

34。瀑布

35。测试周期

36。 V模式

37。工具

38。探索性测试

39。通过

40。失败

41。输入

42。产量

43。测试队

44。测试团队铅

45。质量保证铅

46。测试方法

47。准仪

48。初级测试仪

49。高级测试仪

50。规格

51。文档

52。问题

53。错误报告

54。 Bug跟踪

55。 Jira

56。 Bugzilla的

57。 QTP

58。测试运行

59。覆盖

60。 ISTQB

61。 ISEB

62。证明

63。测试专家

64。支票

65。价值观

66。神谕

67。算法

68。启发式

69。统计

70。模型

71。州

72。一步一步的说明

72。预期结果

73。实际结果

74。测试套件

75。测试摘要

76。测试方案

77。测试程序

78。 SUT的（在测试系统）

79。测试工具

80。执行测试

81。测试执行引擎

82。测试脚本库

83。手动测试

84。假设

85。会议根据测试

86。路径

87。测试环境

88。用户验收测试

89。风险

90。试验估计

91。测试配置

92。试验结果

93。调查

94。错误

96。 Windows和Linux环境

97。测试Analist

98。测试阶段

99。测试设计

100。固定

101。测试经验

嗯，我可能有重复或忘记了一些重要的，但这个是很常用的术语时，指的是测试。它可能无法在同一范围内，但他们在那里，也许不应该。

Well I got into testing by looking for a job. It came for the time of that. I had some friends then, whom I didn’t considered very intellectual and a couple of them worked as testers. Being in IT area I didn’t though of something else, but didn’t want to be a developer or a call center operator. Testing looked interesting.

So I started going to interviews. Well I think maybe the long hair didn’t help too much at the time. Not sure but quite possible because it wasn’t too neat.

The interviews were pretty lame like some I see now if I try to apply to a job in testing. If I look back there were some very good ones.

Well I got eventually a job, then change it and again and again. Now if I look back for this, the companies were quite OK, unfortunately they were located in Bucharest. I find this city really disgusting. Even if I didn’t travel much and possible its really not the worst place to live, its still a disaster. Unfortunately in the rest of Romania its hard to find something suitable to support yourself. Its really a city with bad karma, annoying people, thieves at any level. If you want to live there you will need to become an asshole as the majority. The city is heavily affected by American companies and American policies, and it will be nice to have something good from this but is too little. Most of the stuff is garbage. In IT a lot is outsourced, although there are some good companies that were successful on their own. Most organizations who want to make branches there, really don’t make a difference in culture or anything with India. Foreigners are not pleasant every-time, and “investors” are looking for cheap labor or cheap girls. And its really dirty, noisy and unpleasant. There are though nice sites to see if visiting and avoiding the bad areas. It doesn’t have some of the big problems that other places have, for example the first armed robbery was only months ago.

Compared to this CZ, I think is much better, although people from Brno tend to say stuff about Prague the way I think of Bucharest. To be honest, Prague is a walk in a park compared to Bucharest. Nowhere is perfect and you don’t know what “surprises” you will get, but still some environments are better, only maybe a little bit at least.

I believe that environment is critical if you want to arrive at some level. You will not go very far sitting in a shit-hole. This is one point I want to make: You have to have a proper environment to do something productive.

The other one, back to my initial, story is to find out how testers got in software testing. So I created a poll for visitors that land and read this page, also happen to be testers.

 Loading ...

Some clipart provided by Free-Clip-Art.com

I want to make a list and explain some of the preconceived ideas about exploratory testing that come mostly from people who heard little or not at all about the term. I used the discussion from a context-driven testing forum, especially James Bach comments.

• Exploratory testing is synonym with manual testing. This is not true because you can use any tool you decide helpful to accomplish your mission, including scripting. Its the same thing as saying that driving is a manual task. You use your head when driving (not all the time maybe or not in all situations but those are exceptions).
• Exploratory testing is called sometimes ad-hoc testing. Ad-hoc is part of ET but not the definition of it. With ET you seek continuously to improve your tests each time. If you go on a trip and visit a lot of stuff, that is close to ET. Having a quick look in a museum is ad-hoc.
• Exploratory testing is a technique. Well ET is not a technique in itself. It might contain a set of different techniques but its more like an approach. Breaking a wall is an approach to make more space in your house for example, but you can use different ways to tear it down.
• Exploratory testing is never planned. This is not necessarily true. You can plan it to some extent. You can plan to split an application to different areas. Then you decide to reorder different because of the new finding done with ET.
• Exploratory testing is not documented. There are examples on how to document ET. One of those is Session-Based Management that can contain data of the tests that have been performed. You can report the path that lead you finding a bug (not referring to steps to reproduce). You can report tools used, knowledge used ( SMPT protocol)
• Exploratory testing is never used in combination with scripting. ET and scripting are opposite approaches but can be mixed. You can create a script to get more data and arrange it so you can find a possible pattern.

I want to make a little intro for scripting that might be useful in testing. Some testers are very scared of it and don’t use scripting at all. Some are scared when see the jobs ads and become obsessed in learning all the tools required.

I will practice on an application used by Markus Gärtner to perform testing but with a different approach. This is Parking Calculator. It is basically calculating the cost of a parking ticket based on the entrance and exit time-stamp.

After you play with it (like 15 min or even less) you can see how it works: gets some input, and when pressing “Calculate” you get a result expressed as an integer (basic case). But what is very important is the URL generated. For example this case:

The url generated is:

http://adam.goucher.ca/parkcalc/index.php?Lot=STP&EntryTime=12%3A51&EntryTimeAMPM=AM&EntryDate=7%2F14%2F2010&ExitTime=12%3A52&ExitTimeAMPM=AM&ExitDate=7%2F22%2F2010&action=calculate&Submit=Calculate

You can see “12:51″ is there in the url as “EntryTime=12%3A51″ for example. “7/14/2010″ is there as “EntryDate=7%2F14%2F2010″. You can change the url itself and see the application appears to fill the data itself. Instead “52″ use “48″. Also important the result of park ticket cost is generated by only loading the link. This means we can use the link directly and read the source code of the webpage to check the result.

With python code we can do this with 3 lines:

import urllib2
f = urllib2.urlopen('http://adam.goucher.ca/parkcalc/index.php?Lot=STP&EntryTime=12%3A00&EntryTimeAMPM=AM&EntryDate=7%2F14%2F2010&ExitTime=12%3A00&ExitTimeAMPM=AM&ExitDate=7%2F22%2F2010&action=calculate&Submit=Calculate')
print f.read()

The first 1000 chars will look like this:

So till this point we have a python script that for a predefined date(fixed not parametrized) is outputting the source code for the page containing the relevant result.
In the webpage source we see result “210″. We can search to find where is located within:

This is a lucky situation because: the result is displayed only once and it has before it a char recognizable for parsing the result “$”. Not to parse the result to get it from the huge page you can do a regular expression extraction or chop out the text. Using regular expression can be more complex.

I will chop it. First start from the dollar sign to the rest of the initial string:

import urllib2
f = urllib2.urlopen('http://adam.goucher.ca/parkcalc/index.php?Lot=STP&EntryTime=12%3A00&EntryTimeAMPM=AM&EntryDate=7%2F14%2F2010&ExitTime=12%3A00&ExitTimeAMPM=AM&ExitDate=7%2F22%2F2010&action=calculate&Submit=Calculate')
text1=f.read()
text2="$"
print text1[text1.find(text2):]

Now we have to truncate the right part starting from firs occurrence of char “<”

import urllib2
f = urllib2.urlopen('http://adam.goucher.ca/parkcalc/index.php?Lot=STP&EntryTime=12%3A00&EntryTimeAMPM=AM&EntryDate=7%2F14%2F2010&ExitTime=12%3A00&ExitTimeAMPM=AM&ExitDate=7%2F22%2F2010&action=calculate&Submit=Calculate')
text1=f.read()
text2="$"
text3 = text1[text1.find(text2):]
text4 = "<"
text5 = text3[:text3.find(text4)]
print text5

If you save this into a file test.py and run “python test.py” you should have “$ 210.00 “.

This is not the way of doing python programming but should help a lot the beginners! We also use the code as secondary need, its not included in some product!

Now let’s parametrize the input so we can use any input data.

We have this parameters:

1. Lot type, “Lot=STP” the default value seen in url
2. Entry time hour
3. Entry time minute
4. Entry time AM/PM option
5. Entry date day
6. Entry date month
7. Entry date year
8. Leaving time hour
9. Leaving time minute
10. Leaving time AM/PM option
11. Leaving date day
12. Leaving date month
13. Leaving date year

We also need to reduce the string used because is very long and hard to work with.

import urllib2

def CalculatePrice(P1,P2,P3,P4,P5,P6,P7,P8,P9,P10,P11,P12,P13):
    urlPage="http://adam.goucher.ca/parkcalc/index.php?"
    urlLot= "Lot=%s&" % (P1)
    urlEntryTime="EntryTime="+P2+"%3A"+P3+"&"
    urlEntryAMPM="EntryTimeAMPM=%s&" % (P4)
    urlEntryDate="EntryDate="+P6+"%2F"+P5+"%2F"+P7+"&"
    urlExitTime="ExitTime="+P8+"%3A"+P9+"&"
    urlExitAMPM="ExitTimeAMPM=%s&" % (P10)
    urlExitDate="ExitDate="+P12+"%2F"+P11+"%2F"+P13+"&"
    urlEnd="action=calculate&Submit=Calculate"
    urlstring=urlPage+urlLot+urlEntryTime+urlEntryAMPM+urlEntryDate+urlExitTime+urlExitAMPM+urlExitDate+urlEnd
    f = urllib2.urlopen(urlstring)
    text1=f.read()
    text2="$"
    text3 = text1[text1.find(text2):]
    text4 = "<"
    text5 = text3[:text3.find(text4)]
    return text5

result=CalculatePrice("STP","12","51","AM","14","7","2010","12","52","AM","22","7","2010")

if result=="$ 210.00":
    print "Test Pass"
else:
    print "Test Fail"

You can see here too many parameters. You can leave like this or group by date and time. You can have 3 parameters by doing that.
You can use the unittest framework, the usual framework for building automated tests in python.
You can parse better the html using BeautifulSoup
You can do better coding.
You can generate a range and expected result for running.
So here it depends on the person doing that. If you do as a task only in work you will care very little for the value of testing and focus on coding. If you want valuable result s from that you will not care too much for coding, unless you have in mind integrating and sharing.
The most problematic issue with automation is that increases thinking but in a direction that doesn’t help too much the testing value, doesn’t protect the application from bugs getting to customers. It only seems more valuable when the other testers not only don’t know scripting but don’t study testing at all.