Ramblings of a software tester…developer…tester…

Ramblings of a tester who is a programmer who is a tester who is a developer…

Why the expressiveness of your Tests is important – Part One

Hello Everybody.

This time I’d like to write about the expressiveness of a Test. I think that it’s very important to write understandable and expressive tests. In older times I was studying novel writing. There is a rule which a novel needs to follow. It goes something like this: “A novel needs to lead its reader and make him understand in the simplest way what’s going on, with whom and why?”. In other words, it’s not a puzzle. It should be obvious what the test is trying to do and it should not require the reader to try and solve it in order to understand it.

I’m planning this as a series since there are multiple problems with a test I can talk about here.

Geb Tests


    def "login to the home page"() {
        given: "I am at homepages"
            go "http://localhost:8080/home"
            at HomePage
        when: "I entir my credential"
            filloutLoginForm("username", "password")
            at MyAccountPage
        then: "I can accass my wallet"
            waitFor { contains("Balance") }

Now, read this test. It doesn’t really make any sense at the first read, right? You need to actually think what is going on there. Of course if you read it slow enough you’ll get what it’s trying to do. But you don’t know what fillform does. Apparently it also submits the form because after fillform you are suddenly at MyAccountPage.

There are several things wrong with this one, let’s start with the pageobject.


At and toAt return page objects. We can use that to actually make the calling explicit and make it more readable and identify where a function comes from.

    def "login to the home page"() {
        given: "I am at homepages"
            go "http://localhost:8080/home"
            HomePage homePage = at HomePage
        when: "I entir my credential"
            homePage.filloutLoginForm("username", "password")
            MyAccountPage myAccountPage = at MyAccountPage
        then: "I can accass my wallet"
            waitFor { contains("Balance") }

This reads much better now. You know where the function is coming from and your IDE will not go nuts from things it can’t find. And you have autocompletion so there is no fear that you simply mistype something.

Side effects

Next step, let’s remove some of the side effects.

    def "login to the home page"() {
        given: "I am at homepages"
            go "http://localhost:8080/home"
            HomePage homePage = at HomePage
        when: "I entir my credential"
            homePage.filloutLoginForm("username", "password")
            MyAccountPage myAccountPage = at MyAccountPage
        then: "I can accass my wallet"
            waitFor { myAccountPage.accountIsDisplayed() }

Now this is again much better. There are no steps left out. And you can test now the FillForm and the submit independently. Like, submitting the form without filling it out! Or filling it out and not submiting it. Reads better, is explicit, more easy to understand.

And the last one for today:


I wonder if you noticed it… The grammar is a little bit off in the tests. A small mistake here and there. You might think that, who cares? That’s a very bad thought. I think the correct grammar reflects caring. It reflects that we thought about this test and that we thought about the quality of it. Because it means that after you wrote it, you actually re-read the test to make sure it’s understandable and readable.

So let us correct that:

    def "As a player I can log in to check my account."() {
        given: "I am at the homepage"
            go "http://localhost:8080/home"
            HomePage homePage = at HomePage
        when: "I enter my log in credentials."
            homePage.filloutLoginForm("username", "password")
            MyAccountPage myAccountPage = at MyAccountPage
        then: "I'm directed to my account page."
            waitFor { myAccountPage.accountIsDisplayed() }

I also took the liberty of re-phrasing some of the text so that it shows what the test is about and what the user really would like to achieve here. Now try reading that last one. Does it make more sense? Did you understand it at first go? Did it read like a good story?

There is a coding practice which goes something like this: “Good code is code which doesn’t surprise you as you read it.” Which means the exact thing happens which you thought of would happen. I think that applies to tests as well. The steps of the test shouldn’t come to you as a surprise. Especially if you know what the application is supposed to do.

So that’s all for today folks. Thank you for reading! If you have a nasty test which you would like me to dissect and make it better and human readable, please share it in the comment section and I will do my best to come up with a good solution for it.

And as always,
Have a nice day!

Updating All Jenkins Jobs Via Jenkins API – Python

Hello everybody.

I would like to share with you a small script I wrote to update all, or a single, Jenkins job from a Python script remotly.

This will enable you to update a Jenkins job from anywhere using an admin credential based on a config.xml template that you have. With this, if you want to apply a config change to all or just a single job in Jenkins, you don’t have to go and do it for all the rest. You just call this script and it will cycle through all the jobs you have and update them if the begin with “yourpipelinedelimiter” or if they aren’t in a restricted list of jobs. The delimiter helps to identify pipelines which are dev pipelines. If you have multiple pipelines which are helpers or builders and you don’t usually apply the same config to them, than the delimiter can help identify the dev pipelines you actually want to update.

Enjoy, hope it helps someone.

And now, without any further ado:

	Created to update multiple pipelines in jenkins with a given configuration and job list.
	Example 1:
	Updating a single pipeline's job with a given config.xml.
	python update-jenkins-jobs.py job-name config.xml pipeline-name
	Example 2:
	Updating every pipeline in jenkins dynamically. !!!WARNING!!! This updates every job EXCEPT of the ones specified in restricted_jobs.
	python update-jenkins-jobs.py job-name config.xml
from xml.dom import minidom
import requests
import sys
def update_pipeline(pipeline):
	Takes in a list of pipelines to update.
	config_file = open(config_to_use, 'rb')
	headers = {'content-type': 'application/xml'}
	print("Updating pipelines: ", pipeline)
	for dev_job in pipeline:
		url = "http://jenkins:9999/job/%s/job/%s/config.xml" % (dev_job, job_to_update)
		r = requests.post(url, data=config_file, headers=headers, auth=('user', 'password'))
		print("Updating pipeline: %s; Response Code: %s" % (dev_job, r))
def get_dev_pipelines():
	Gets a list of pipelines which can be used by update_pipeline.
	r = requests.get('http://jenkins:9999/api/xml', auth=('user', 'password'), stream=True)
	job_list_xml = r.text
	xmldoc = minidom.parseString(job_list_xml)
	itemlist = xmldoc.getElementsByTagName('name') 
	dev_job_list = []
	restricted_jobs = ["yourpipelinedelimiter-dev-pipeline1", "yourpipelinedelimiter-dev-pipeline2", "yourpipelinedelimiter-dev-pipeline3"]
	for s in itemlist:
	    if ("yourpipelinedelimiter-dev" in s.firstChild.nodeValue) :
	    	value = s.firstChild.nodeValue
	    	if (value not in restricted_jobs):
	return dev_job_list
job_to_update = sys.argv[1]
config_to_use = sys.argv[2]
dev_pipeline = []
if len(sys.argv) > 3:
	print("Args length:", len(sys.argv))
update_pipeline(get_dev_pipelines() if not dev_pipeline else dev_pipeline)

Thanks for reading.

The seven Principles of Context Driven Testing – Mind Map

Hi Folks!

I just wanted to share with you my mind map on the seven principles of Context Driven Testing.

I used the notion of dragons since it’s seven. And a dragon is usually seven headed in my mind…

So without further ado…


Click for larger image.

I have a hand drawn as well but I’m guessing that one wouldn’t be of much use since it follows my own imagination.

Here are the seven principles in points which correspond to the leafs.

  1. Value -> Practice -> Depends -> Context => The value of any practice depends on its context.
  2. People -> Working -> Together -> Important => People, working together, are the most important part of any project’s context. ( The mob, trying to kill the dragon by working together. )
  3. Problem -> Project -> Solution => The product is a solution. If the problem isn’t solved, the product doesn’t work. ( The sword. It’s a sword but if it doesn’t kill the Dragon it’s useless. )
  4. Good Testing -> Intellectual Challenge => Good software testing is a challenging intellectual process. ( Well it’s a dragon with glasses. That’s something you rarely see. )
  5. Good Practice | Bad Practice -> In Context -> No Best Practices => There are good practices in context, but there are no best practices. ( This one was a little bit tricky. But basically you want to solve the dungeon and not plow through it )
  6. Uncertainty => Projects unfold over time in ways that are often not predictable. ( For me this one word was enough. )
  7. Exercised By All In Time -> Judgement | Skill | Cooperatively => 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. ( It’s a flexing dragon… Easy, right? )

So this map helped me to remember everything. The descriptions, applications that are further described I remembered by using this mind map as a loci.

I hope somebody found this useful.

Thanks for reading!

Python Course Review

Hello Everybody.

Today I’d like to write a little bit about a python course I did.

It’s an 8 week course on algorithmic programming with fun little projects. I’d like to write down some of my solutions with pseudo code for my own better understanding and for the sake of sharing knowledge. I won’t, however, share full projects since that would be against the honour code.

Let’s begin…

Week Zero

This week was all about getting the hang out of reading the posts and the documentation and the questions and getting used to the wordings. The tutors really out did themselves. They tried to make a course that can be both funny and teach something at the same time which is anything but easy.

Even though the tasks that were given were interesting al-bight at times a little bit far stretched and could have been easier done if used something else to complete them. But if we would have done that, what’s the point of it all then?

So I’ll try to recall everything solely based on my notes taken in those 8 weeks. Let’s see how much I truly learned.

Assignment of week one

We were to build the game 2048 which if you played you know what it is all about.

2048 Game

The goal is to add up numbers so that higher and higher numbers are created. There is no real “end” of the game. You can continue as long as you have space left although the intended goal is to create 2048. There are a couple of clones of this game and we were supposed to write one this time of our own.

We approached this game with the intention of refreshing our memory about Python. Handling matrices python syntax, counting indices and a bit of assessment about the general understanding of Mathematics and programming from the populace.

I must say it was hard. It was hard to get back into the habit of properly thinking about something at first. It was hard to get used to Math again which I missed for a very long time. I forgot many things and as English is not my first language many things written about Math in English were extremely hard to understand in the beginning.

But thankfully for my trusty mathematics Bible in Hungarian I was saved.

Math book

This book is 1448 pages long but contained all the information necessary to get my mind back into the game. And oh boy was it worth the initial trouble. I had to first realize that I forgot so much it was very painful and immensely disappointing, frustrating and shameful. But you should never give up and so I fought my way through it.




And it was extremely helpful to do Tests First. As the grading was based on how many of a given set of Unit Tests were passing it was very helpful to start tests first which were leading the design of the program. Also it was crucial to work in as little chunks as possible since one could easily lost himself trying to grasp a problem proving to be too large to look at from afar.

The hard part about this project was the Merging of the numbers and creating the proper grid which results from the Merge. Here are some examples:

  • [2, 0, 2, 4] should return [4, 4, 0, 0]
  • [0, 0, 2, 2] should return [4, 0, 0, 0]
  • [2, 2, 0, 0] should return [4, 0, 0, 0]
  • [2, 2, 2, 2] should return [4, 4, 0, 0]
  • [8, 16, 16, 8] should return [8, 32, 8, 0]

In order to achieve this you must trim the zeros like this [2,2,4] and than produce the result which is [4,4] and put a couple of zeros at the end [4,4,0,0]. My first though was to use the Deque class in Python in order to achieve this but that was an outside module which was not allowed.

It was an interesting way to begin the course. Many people left at this point and were leaving afterwards too. Most of them in frustration that they were missing the python knowledge the rest out of frustration of not knowing the necessary math. At the end though it was getting easier to follow the problems after we got used to the conventions and sentence structures. The professors were also helpful and sometimes re-worded some of the descriptions to better describe what they wanted.

Week One

So after a hard start we moved on to a very interesting week one. This one got me into a certain game I don’t want to see ever again… It’s name: Cookie Clicker.

We sort of had to re-create the cookie clicker but without the clicking. We only were supposed to re-create the buying of upgrades and simulate a sequence of clicks via the means of a cycle.

In this week the description of the tasks was, at the least, confusing. They started to use the term time which lead many to believe that we were somehow supposed to use python’s date / time methods and libraries. But after a couple of re-reads it was apparent that by time they actually were referring to cycle count. 

Knowing this made the task at hand a lot easier. This time around our main focus were the following:

  • Mathematical Sums
  • Finding the Max
  • Higher – Order functions
  • Plotting with Python

The course just went into overdrive. We were looking a lot at thing like these:

n i=0 α^α^α^α^..α^α^(n+1) − 1 / α − 1

It was rather awesome though frustrating at first like I wrote earlier. These were the easier one.

Finding the maximum is trivial. Especially if you are using a built in max provided by Python. But if you mix it with Higher-Order functions it gets interesting. If you want to do anything else as well and not just a max, for example getting the index of the maximum item as well, you usually end up writing a custom Max any ways.

Plotting in Python was exquisite interesting. The garphs which were produced showed as an insight into how powerful a solution really is or how effective. Here came in the Big-O notations almost. To see if a function was exponential, logarithmic or plain polynomial. O(n), O(n^2), O(logn) etc, etc.

This resulted in very interesting graphs like this:

Screenshot - 250814 - 18:10:34


Week Two

So last week we had plotting and counting this week was even more interesting. Week Two’s main focus was Probability. Specifically the Monte Carlo methods. Tl;dr; it describes that if you try something enough times you can derive a result that will be, with very high probability, the one you are looking for (expected value).

We tried out this algorithm by playing a nice game of tic-tac-toe.

The point of this exercise was to create a machine player which, after running a 1000 or so random scenarios, was choosing the best option given a certain game state. It was difficult to get the results to always return a correct answer. At this point last weeks plotting became important since if your Monet Carlo algorithm was not fast enough the program was running increasingly slower and slower.

I was not very satisfied with my solution. It worked, but it was very slow and it wasn’t always returning the best option…

Week Three

So what comes after probability? Correct. Combinatorics. 

The next hill to climb was combinatorics. Fortunately for me I love probability and combinatorics so this was a little bit easier for me. I was getting the hang out of function calculation as well so I wrote better homework and better projects at this point. Which is the aim of the course, right?

The game we used for this approach was Yahtzee.

Now let me say this without too much remorse. I truly, fully and with all my heart, hate Yahtzee. I think it’s stupid. I’m sorry. I truly do. The only thing I can think of when I hear yahtzee is the South Park version of it.


South Park Version of Yahtzee + Tron:



I share the enthusiastic look of Stan here.

Anyhow, moving on… Thank to the coursera Gods we weren’t suppose to write a whole game of Yathzee just a very simplified version of it. We were supposed to count the upper combinations on the second throw. So you already have one throw and you must choose how many die you want to hold on to to maximise the possibility of the best outcome possible. Huh… come again?

So you already had a hand. And now the program was to determine which die you were supposed to hold on too in order to maximise the score you can achieve with the remaining two throws.

There were a few interesting things that came in with this task. For example this was the first time I could use a Dict init from a list with a zip.

hand_dict = dict(zip(list(hand), [0]*len(hand)))

And this was the point in course were I found perhaps the most interesting thing. I found an actual use for reduce which was working. I was beginning to get into the habit of using map, filter, reduce.

This was the beauty:

my_list = reduce(lambda z, x: z + [y + [x] for y in z], hand, [[]])

This piece of code produced all the combinations of a given hand which was a list of Tuples. It merged them into a list of lists which I created a list of Tuples out from. After this my life was never ever the same again.

Week Four

For me this was the most interesting part of the course. I LOVED this task. Focus was:

And the task with which we were supposed to achieve this was…. Zombie Apocalypse. It was sort of like Conway’s Game of Life. Given a grid in which there were Zombies and Humans  Obstacles.



The Zombies could only move up, down, left, right. The humans could flee diagonally and none of them could penetrate an obstacle. It was very much fun to write this. The most challenge was to learn the proper implementation of the breadth first search algorithm as the Zombies had to detect the nearest Humans to move towards to and the Humans needed to see the nearest Zombies to flee from.

Week Five

Halfway through it was become difficult to maintain the time needed for this course. I was finding myself applying a few late days here and there. This was a two months course after all. I did not have all the time in the world at my disposal. But I managed to submit everything without penalties.

So this weeks task was rather mundane. It was a world wrangler. Which means given a word generate valid words from the letters in the provided word.

The algorithm we were supposed to use though was for me a bit of a challenge. I’ll be honest with you, for me, it was a little bit hard to wrap my head around this one. But eventually I succeeded.

It was Merge-Sort and Recursion. Let me tell you this now, I hate merge-sort. Recursion I do love though. What I never learned though and was very interesting for me to learn now was recurrences in mathematics. Well never learned is a bit harsh since I knew Fibonacci already and Pascal’s Triangle but the mathematical definition was a refreshing new view. I’m talking about Recurrence Relations.

F_n = F_{n-1}+F_{n-2}

This is the Recurrence relation of the famous Fibonacci. Easy, right? Well the hard part is when you are trying to get the closed-form-expression of a Recurrence.

Week Six

Finally it was coming to an end. The last week was easy so this week had to have a punch. And oh boy it did. This weeks focus:

If I hated merge-sort I hated minimax more. I don’t know why but it was again very hard for me to properly grasp this concept. I mean I understood what needed to be done of course but writing it done with code proved to be more difficult then I thought it would be.

After hours of research and reading finally I could come up with a solution which was working. I wouldn’t say it was good… But it was working.

The game with which we were supposed to demonstrate this algorithm was… Tic-Tac-Toe. Turns out that it’s rather common place to show off minimax with tic-tac-toe as it was fewer possibilities. The point of the exercise was the following…:


To create trees out of the possible moves given a certain game state. This time we wanted to make absolutely sure that if we can’t win the game at least we won’t loose it. And that’s the point of minimax. It will minimize your losses.

Now there are several things about this algorithm that are hard.

Performance of Minimax

It has and always will be a very interesting task for programmers to try to achieve a better performance for these calculations. Since it’s trying to build up a tree with all the possible combinations a game can have it will end up with a huge tree which will take ages to traverse.

A few of the solutions could be to exit the search once you have a definitive answer. If you find a winning move there is no point of looking any further. You just stop.

You can create the tree dynamically. You can make it somehow intelligent enough to predict a possible best first move and then use minimax on the rest. Or use Alpha-beta pruning.

Week Seven

And so we are coming to an end. Last weeks assignment was basically to put all the previous weeks knowledge together to create the application called 15 puzzle.

Now, there was however a little addition to the previous knowledge. It was invariants. Now, I love Logic. And I’ve been actually using invariants in computer science programming and testing for a long time so this part was not really a problem.



An example of an invariant in python would be something like this:

while x <= 5:
  x = x + 1

This is a loop invariant example. In you find a very useful invariant in your program you can write an assert for it which will help you debug your code and work in small chunks. Invariants will make refactoring your code a hell of a lot easier. As if your invariant is suddenly false you need to check what went wrong.

while x <= 5:
  x = x + 1
  assert x <= 6

This assert will make sure that if your invariant for whatever reason isn’t true your code fails immediately.

End Credits

So this was the end of the course. I learned a a lot from this course and I’m very proud of myself for completing it. I took away a lot from this course. I took away confidence and logical thinking. I took away greater trust in my Python knowledge and that it’s very important to keep my skills from deteriorating.

And I think math is important for proper, deep understanding of programming as a science. I think refreshing my math skills gave me at least a deeper trust in my ability to write a piece of code however complicated it might appear. After writing a minimax algorithm I think some Hibernate with DIP and SRP will prove to be less of a problem. Or at least a different category of a problem…. Hehe.


Thanks for reading!

Five reasons why a tester should learn SQL

Hello Folks.

So last I was writing about why a tester should learn Javascript. Today I would like to write about why a tester should learn SQL.

There, I said it. I know many people, especially testers, don’t like SQL. They view it as a monster best be avoided. Something only Database people will know. Something which is so scary and ugly, nobody really wants it.

But I will give you a couple of good reasons why you shouldn’t be afraid of SQL. And why you should welcome it as your best friend and partner in crime.

Let’s go.

Reason Number One: Data gathering

This one is obvious and clear as the sun. You can use simple queries to mine for data. To look up changes and compare time intervals between insertion and update events. You can monitor certain tables so that when they are updated, you’ll get a red flag.

Reason Number Two: Test Run Statistics

This one is from my friend Adrian. Basically if you would like to know more about what’s happening with your tests when they run, for example:

  • Run time
  • Frequency of Test outcome
  • Failure rate
  • Environment details -> Execution slave

One interesting way to achieve this is, to have the test report running and outcomes into a little mysql database and than create queries of certain types like, show me the last run of every test called xyz and show me the environmental details and the run time. With this closely monitored you could find out that Slave #345 is sluggish because each time the test ran on it, it took more then 10 minutes where as the others only took 5-6.

Reason Number Three: Data Manipulation

So after monitoring comes naturally the edit. Understanding how databases work and knowing a few queries here and there can help you manipulating your data in a way that it will be easier to test data dependant scenarios.

Instead of making a new entry you could edit what you already have.
For example:

You have a customer and you want to test the system’s ability to handle people on your site who are suspended from access. But the ability to suspend is not yet working. Will that stop you from testing this feature? Will you put this feature into blocked because: “Ohh, we can’t yet suspend a player so we need to wait until that’s done.”

No. You don’t wait. You dig into your database, find the necessary record, change it’s state to the desired state; even if it has a foreign key which needs to be updated or that status doesn’t exist yet, in which case you ADD it to the list of states yourself. You don’t let yourself be stopped just because something is not done yet. You move on by being clever.

Reason Number Four: Understanding Data migration issues

A big issue these days if you go into a project where you have a previous version of what you are currently building will be migrating over old data into the new database scheme. Testing such a thing can be a pain in the butt. But it will be a LOT easier if you understand the changes. If you know what changed, how and why, you can manipulate your data in order to fit the new scheme. Or if you need to test it you won’t be afraid of running some stored procedures in a dummy database with old data and than run a few queries to see what broke and what didn’t.

Do you have a foreign key violation somewhere when you migrated over and have no idea what do to? Time to learn some SQL so that you don’t have to run to somebody every time you encounter it. Even if you can’t fix it, the database engineers or the devs who will fix the bug will be very happy that you provided as much information as possible in your report.

Reason Number Five: Security

SQL Injection is still at large. Even with these days frameworks doing full escapes it can’t hurt to test a couple just to be on the safe side. And writing a clever script that mines for accessible tables here and there is an essential skill in a security tester’s repertoire.

Reason Bonus: Performance, HibernateQL, Information

Lastly a bit of a bonus are these three.


Suppose you are running a web application. You access a large list and you notice that it’s sort of sluggish. You first blame it on the network so you test it locally. It seems to be better now so you move on but it leaves a little voice in your head so you can’t abandon it. You go back and try locally again with a bit more data in your database.

You notice it’s a little bit better but it’s still somehow sluggish. Suddenly you get a hunch and turn on SQL logging in your tomcat instance. You click the link again and wait with eyes wide open on what happens next. It’s your worst nightmare.

The SQL queries the whole database with a simple select and than filters the data on the front-end side. Which is a really really dumb thing to do. So you file a bug for which the title is something similar to this: “Customer Transaction History query doesn’t apply WHERE | INNER SELECT | PAGING on SQL rather it filters on the application layer.”


This is the SQL language of hibernate which is the underlying technology in many java web frameworks these days. It uses it’s own thing called HQL. Main difference, as this page already says, is that it’s a full blown Object Oriented query language which understand inheritance and polymorphism which is very exciting.


Last but not least I mentioned this one earlier. You can provide more information in your bug reports as in what data you used, where was it happening, what was the last update date, which environment and what query was executed ( if you have query debugging turned on ). Whoever reads that bug report will find it very helpful that you provided enough information to reproduce it anywhere.

Because many times the culprit for a bug is the underlying data.

Reading and Practising resources

Here is a very awesome picture of how to understand JOINS which is everybody’s fear.

SQL Join Cheat Sheet

SQL Join Cheat Sheet

And a post on Coding Horror which is essentially the same but I like how Jeff writes.

Also if you would like to practice writing SQL scripts and no longer be afraid of them all the rest of your life go to this site => SQLZoo. It’s an interactive way of trying out your SQL skills and testing them on very clever database structures.

But if you, like me, love to learn PLAYING than THIS is the place for you => The Schemaverse. It’s a SQL based space shooting strategy game awesomeness! Have FUN learning SQL.

Thanks for reading!
Have a nice day|night!

TDD is Dead – Not really

Is TDD dead?

Not really. So let’s talk about this topic for a little bit.

I’m sure you already read a gazillion posts about this debate but frankly I’m writing this for myself, to rant a little bit, you know… Because somebody is wrong on the internet and I must intervene.

So first of all, the hashtag #tddisdead (and I will use it shamelessly as well). This is clearly an attempt to get as many peoples attention as you can. TDD is NOT DEAD. Obviously since it has soooo many supporters how could it be dead? It’s like asking, is Design Patterns dead? Or is Functional Automation dead? Or is Oreo cookies dead?

No, it’s not dead. And it won’t ever be dead. It will maybe change into something new, something better even, but it will never be dead. So let’s skip that part.

Now, about the debate.

I haven’t hear so much bull spoken for this long since I watched the political debate of two fractions in my home country. The right wing extremists against the left wing…. I don’t know whats. And it was just that. A political debate. It had no merit and no value whatsoever. At all. Nothing.

And right in the middle DHH says this:

“…you’re not done until you also have tests for a piece of functionality — I’m completely on board with that.”.

That made the whole conversation completely irrelevant.

Every counter against TDD I heard was bull. Not in that debate, in general. People are either too lazy to write them, just don’t want to get out of their comfort zone, don’t really care about tests, or don’t really care about quality or under time pressure ( I get to this later. ).

Which brings me to my next point.


People seem to not care about quality that much. Would they, they would understand that having a bulletproof west will save your life when you get shot in the chest with a 357 magnum. You can flush out early design flaws you can detect early bugs and do a better system design.

Sure if you are the most intelligent man on the planet maybe you can come up with a perfect system on the first draft and then implement it flawlessly so that it doesn’t fall apart in two months time. But most people can’t. Most people make errors on the way.

And yes, writing tests can be hard. But guess what? If writing a test is hard because that part of the system is complicated, than it will be that part of the system which will react the worst to change. And only change is constant. Which brings me to the next item…

Time constraints

So your manager is sitting right next to you and saying come on we are paying you to write code and not tests so do it! And you have to have a feature done today but if you write a suite of tests you’ll only finish tomorrow. Sure, your estimate at that point will become a very quick one because you make a sacrifice of trust.

And then the next story comes along and you say… “Sure I can do that as well. No problem I know how my system works, right? Hmm… why the hell did that break all of a sudden? I didn’t change anything in that module… Ahh damn it I said I’ll be done today, so let’s just fix this quickly and then move on to the next card.”

And the next story comes along… “Sure I can do that… wait a minute… Didn’t that part brake already twice? Damn, better refactor. Ohh shit, why is that now breaking???? Damn it I said I’ll be done tomorrow, better patch it, and then move on. Hmm let’s write a test here to make sure this does not break. Ohhh damn I need PowerMock for that stuff since it’s in another module. Why the hell is that there? Should it be here in the first place since it’s somehow used by that other class there? Interesting. Let’s refactor and put it in here so I can mock it. Ahhhh f*ck now all the rest of the system is not working. Damn, I’ll just use PowerMock. Shit. Checkstyle error. PowerMock is not allowed?? What?? Who the f*ck says that?”

You get my drift. And suddenly you end up with estimates of WEEKS!!!! instead of days / hours for a simple story.

Finishing it up

This a rant only. It’s my personal opinion, experience and observation of a 10 year time period in Software Testing. Starting with at least a Weak Skeleton and a few upfront tests will help you in the long run. Writing at least ONE – TWO acceptance tests WILL help you understand business logic better. Writing ONE or TWO unit tests will help you understand your logic better. I’m not saying write a whole damn suite of tests I can understand you don’t want to do that, but for quality’s sake write at least a couple.

You will love it, I promise you that.

Thanks for reading.

Five reasons why a front-end tester should learn Javascript

Hello everybody.

Today I would like to write about a very interesting topic, I hope. So let’s get started.

As the title already suggests, I’m writing about why a front-end tester should learn at least a little bit about JavaScripting and the DOM.

Ohhh and contrary to the belief CSP ( Content Security Policy ) will not be the death of such scripts. There are white-lists and workarounds and exclusions which can be implemented in order to allow local JavaScripting to continue. So don’t fret… Read on.

Reason Number 1: Injection

Every front-ender tester has a waste amount of tools at their disposal. Various things, like Firebug and web developer Toolbar and… Bookmarklets and Greasemonkey and Tampermonkey. These are the real powerful tools though. Your main objective at this point would be to inject something into your current site.

Suppose a scenario where you are testing something and you have an API at your disposal for a quick edit on a customer, like closing his account or giving him money, or doing something with his appliances. Suppose you don’t want to always switch away to another tab or call a service with certain parameters or go to a rest client and initiate that from there.

Suppose you could have a small injected DIV right on the page you are which gathers information for you, like the customer’s username, and wallet and whatnot, and with a simple press of a button, you just closed their account. Neat, isn’t it? Simple, fast, very comfortable with just one press of a button.

Suppose you have a DIV at the corner of a page, or even a drag and drop enabled one which you can drag around, with an arsenal of these buttons RIGHT THERE on your page. You don’t have to switch context at all.

These days it’s especially easy with tools like jQuery at your disposal. You just inject jQuery first, if the site is not already using it, and you are good to go and do whatever you like to do….

Reason Number 2: Data gathering

While we are testing these application we always create some kind of a report. That report contains many things about the customer, or it’s appliances or the things he does, does not. All these could be constantly gathered by your script as it runs in the background. It gathers statistics and information which otherwise you would have to gather from some transaction history, or some kind of an action history. But no… Not the JavaScript Wizard.

You, would just press a button and the script would generate a report for you. It would even print it out. Create a persistent layer in which you are gathering information continuously. Create a small mySql database on your local machine and have the JavaScript enter data into that. Tadaaam…. Usage statistics at the touch of a button. All there, only waiting to be extracted.

Reason Number 3: Tempering

In understanding the ways of the DOM and the JavaScript you can create some very interesting test cases not to mention XSS attacks which is essentially JavaScript Injection. That’s always fun and produces many very good bugs.

Cookie manipulation. You want to simulate something? Like a time-out or a session loss or anything like that with a push of a button? Easy…

Reason Number 4: Shortcuts

You have a massive field like registration that you need to fill out? The shortest way is to have an API which you can call via a curl script. But if that’s not available and you would like to exercise the front-end any ways, then you will end up wasting hours and hours on always filling out all of those pesky fields.

And suddenly I’m hearing: “But I’m using Selenium plugin for that.” – you might say. Sure, use that. But I’m using Chrome. “But there is iMacros for that.” – you might say again. Sure, I know… But! Let’s see which takes longer…

Open selenium, load the script, run it, see it fail, run it again, ahh success, good. Same with iMacros. As opposed to, having a Bookmarklet right in front of you, on your bookmark, and with a click of a button, or with entering something into the browsers search bar, you suddenly fill out the form and press submit.

You see the difference is that JavaScript runs faster and more accurate by it self in such short things then with a wrapper around it. And it’s faster accessible as well.

Reason Number 5: Security

There are all sorts of things that a security tester can do with a small script which gathers session information and availability.

Reason Number 6: Accessibility

This is of course the easiest one. There are ample of scripts and browser plugins to test accessibility which is an all time favourite for everybody in the front-end land. Make your life a little bit easier. How bout just running a bookmark like HTML_CodesSniffer an see a very gorgeous result like this:

Ain’t it beautiful? What stops YOU from writing your own?

So get out there and learn JavaScript. It’s easy. I’m not telling you to become a front-end developer, just know thy tools and you shellet receive the blessings of the IT Gods.

As always,
Thanks for reading.

Note taking what when how often

Hello Everybody.

Today I would like to tell you about a little conversation I had with my friend Adrian.

The topic was about how, when and what to log during a testing session regarding a story.

So let’s see what came out of that talk…

Logging your work

The question is really not whether you should log your work or not, but rather to what extend. Because we all know that you should log your work. It helps you recall and helps you organize and think out testing strategies. But the extend and methods are a big question. So here is my routine.

Visually inclined

I am a very visual person. I log my work with doodles and such like Mr. Huib Schoots who uses Sketchnote taking. You have seen some of my sketches if you follow my twitter feed, like this one => . You know I like to draw so for me colour and organizing and doodling is key to make a note more personalized and live.

That comes with a drawback. The draw back are many…

First of, I need to do that in a notebook. I could bring my wacoom tablet to work and draw in paint, but that wouldn’t be the same. And I don’t particularly like drawing on a tablet actually.

Second one, it’s completely unsearchable. As Adrian pointed out, you can’t search in a notebook, even if you are using side pointers like a sticky note or something. You won’t be able to instantly find and track down something you did. And after a while it gets cluttered with doodles and the notes are lost in-between. It will be very colourful and utterly useless.

Third one is, it’s slow. Typing is much faster.

On the bright side… I love doodling. And if I can draw something up with a picture I will understand it much faster rather then reading a few lines of words chunked together.

If I draw an awesome diagram I will get what’s going on much much faster.

And it will be more fun to actually right it down with a nice fountain pen with a beautiful tip that can create such marvels that you don’t want to put it down.

It’s portable. I can carry my notebook everywhere. I should be able to do the same with a laptop, but since it’s tied into a dock station and I don’t want to carry it around with myself everywhere I won’t do that. I could create notes though in my notebook and then write them down into the laptop after I’m done? Sure…

So now let’s go and see the other one.

Electronic note-taking

I think I already pointed out a few positives about that. It’s searchable. Definitely. It’s fast. Yes. It’s more convenient, more organized can be backed up and you won’t run out of ink or space or somebody won’t take it away to a meeting because “Ohh I saw it on your desk and I needed a paper hope that’s okay.”.

I understand the benefits of it. But it’s very very rigid. It has no colour, no personalization and no feeling whatsoever. It’s frigid, standardized and without life. So I need something to make it a bit better. I have a couple of tools for that.

First off I need a good graphics maker to create diagrams. There is an awesome free tool pointed out by Adrian to do that called yEd. Download the zip and run the jar. I can live with that. Creates nice diagrams and flowcharts.

It’s quite powerful. Go look it up. There are a gazillion picture on Ze internet.

But the notes still lack personalization. There are a couple of tools which you can use if you, like me, shy away from everything that’s Microsoft, you have the opportunity to use Emacs with the org plugin which makes absolutely amazing documents.

It’s awesome but the problem is that it will only work with Emacs and nothing else. And from time to time I don’t like the controls of Emacs. I’m a sublime text person. So recently I found a little plugin for sublime text called PlainTask.

Here is an example of how it can look like:

I LOVE it. You can add little notes and set a task to complete or defer it and it sort of highlights and things like that, which I like. It’s still not doodling but it get’s the job done and will be searchable and will be fast and available. And you can use Sublime text’s awesome power of foldering. Create a root folder and open it with sublime. Then create one folder / story you are testing and put everything related to that story in that directory and then press CTRL+O and unleash the magic!

Instant search and organization at the power of your fingertips. Even search IN the files themselves.

This makes it a bit better and bearable. Which brings me to the final topic.

Note taking frequency

So my friend argued that he create a folder for EVERY story he ever tests. Even if it’s only one word he puts into it to as a memory trigger he does it. I argued that that seems to be a little too extensive. But he said in return, and I have to agree on that, that once you stop doing something because of an excuse like, ahh I don’t need to do it because it’s a small story, you will stop doing it completely. And this is actually true for everything in your life. And as somebody who recently started running ( 1 month ago ) I understand the weight of that sentence very well.

So I would say do as much note taking as you can even if it is a little word that jogs your memory to remember some detail about the story. Even if it takes more time to create the folder and the note, it will help you at least to remember doing it and testing it if nothing else.

Although I don’t think I will do one for everything I will certainly try. Now with these awesome tools at my disposal I might even enjoy the rigidity of the keyboard more. ;-)

Thanks for reading!
Have a wonderful evening!

Using Chrome Search Engine – Multiple Search Params

Hello Everybody.

Today I would like to write a few words about Chrome’s Search Engines.

You’re probably already using it for a couple of things, like Google, or Amazon searches or YouTube or anything like that. But are you using it to access environments and testing tools faster, with queries?

For example, here is a quick Jira Search made easy:

Keyword: jira
URL: https://atlas.projectname.com/jira/browse/PROJECT-%s

So just type: jira|space|9999

Will immediately bring you to your ticket.

“Bah, why would I want that?” – you ask.

Well, it’s easy, and quick access, but wait. There is more. How about you want to access a test environment that changes only a number?

Keyword: testenv
URL: https://qa%s.projectname.com/testenv

Just type: testenv|space|14

“Humbug!” – you might say. “What if I have a different URL for an admin site and my main web site AND the number, hmmm? Also I have that stuff bookmarked anyways…” – you might add in.

Well, don’t fret. By default, Chrome, does not provide this. I know FF does, but I don’t like FF. That’s that. So I have to make due with what I have. And indeed there is a solution for using multiple search parameters. It’s is a JavaScript you can add in into the URL part and Chrome will interpret that. You can find that JavaScript in a few posts but you will find that THAT script is actually Wrong. Here is the fixed Script, courtesy of yours truly:

var s='%s';
for(i=0; i<urlchunks.length; i++) {
	if (typeof schunks[i] != 'undefined') {

So no you will have an entry like this:

Keyword: testenv
URL: paste in the upper script

And try… testenv|space|admin;14 => which should result in: https://admin.test14.projectname.com/

The location.replace at the end will bring you to the web page. It’s interesting to note the s will be replaced by admin;14 which is a nice magic by JavaScript.

NOTE: This only works on a page like google.co.uk. For chrome pages, like the new tab, omnibox has this ability disabled unfortunately. :(

“Well then it’s completely useless, isn’t it?” – you might say. Well, it’s usage is limited in power, that’s true. But it’s still useful as I’m sure you have a couple of pages open anyways which you don’t mind using up…? And you have to remember less keywords only a few powerful ones.

Credit for telling about Chrome Search Engines power in the first place goes to… *drumrolls* => http://www.testfeed.co.uk/

As always, thanks for reading.

How I started Running

Hello Everybody.

Today I would like to write about something non-technical. I would like to write about running and how I started it and what my experiences were with it.

So tl;dr… here we go.

What led me to running

There were actually two things that led me to start running. Three…

Reason One: The accident

I’m a bike person by default. I *hate running with a passion. One day I was riding my bike in the woods when suddenly I hit a big ol’ tree trunk right head on at which moment my bikes front fork bent inwards and became completely useless. At this point I had to walk home. Repairing it proved to be a bit time consuming so I had to think of some other way to have my regular exercise.

Reason Two: The comic

In the earlier days I’ve read a web comic from The Oatmeal, namely this one =>http://theoatmeal.com/comics/running

It inspired me so much I just needed a last kick to get started.

Reason Three: The other accident

About two years ago I had an accident and I broke my ankle. Cycling was one of the ways to exercise my ankle and now that my bike was gone I had to think of something else.

So with the Blerch on my back and all these wonderful reasons and because I believe that if you hate something but it’s good for you you have to find a way to make it your best friend….I begun.

How to begin…

Hence my first todo item on the list was to start thinking like a runner. I would like to run today. I want to run. I love to run. I need to run. I miss running because it was a very bad weather outside and I couldn’t go and now I will run twice as much tomorrow.

Start running…

This one seems obvious and… It is obvious. Just start it! Go out and run a few paces. It will give you a feel for how much you really need it because you are out of shape.

So… After I got my mind set on starting running and finally went outside a park which is nearby I started my first ever run.

First time running

Let me tell you at this point a few things you will need.

– A new heart
– Some lungs
– A new back
– Some legs
– And a couple of ribs

Your first run will be terrible. It will be awful. You will whease. You will shuffle. You will suffer and would like to give up immediately and go home an sit before the computer and do nothing and enjoy that none of your body parts hurt.

You need to get past this feeling. And don’t overrun on your first run. You don’t need to run 10k on the first try and you probably wouldn’t even make it. Just run for 10 – 20 minutes. You can walk in between if you get tired nobody will kill you for it or you won’t be less because of it. You can walk and bend a little bit. Your back will probably hurt so stretch a bit.

Which brings me to preparations.

People say that for short distances you don’t need to prepare. I call bull. Everything hurt on my body on my first try and on my second it was much better when I did it with preparation. A couple of things to do:

– Stretch = Important. Legs, back, front, side.
– Vaseline = If you have squishy parts on your body that touch while you are walking, like in between your legs just right after your pelvis where your legs connect, apply a bit of Vaseline. Trust me. You will be thankful for that. Where your body meets and if you run for 20-30 minutes it creates a log of friction. Vaseline helps you to protect against that. Later on long distance runners usually use it on their nipples to avoid getting a rush from the t-shirt they are wearing.
– Gear = This is an important one. I provide a different section.

Once you are geared up you are ready for your first run. It will be wonderfully painful but will be soooo gooood afterwards it’ll be all worth it.


Before you start running you need a proper shoe. There are countless blogs about what shoe to use what leg type you are and so and so forth I say f*ck that. On your first run make sure you by a basic running shoe like these =>Shoes

It doesn’t even matter if it’s a cheap one. A bit later when you feel you are ready you can invest into a proper running shoe. I’m using a Karrimor D3O. I heard absolute terrible reviews about it but frankly for me it’s extremely comfortable and I never had any problems with it. I like it. I might switch after a year or so and see how another brand fairs but for now, it’s perfect.

I advice against running for prolonged time with a shoe that’s not a running shoe. You will immediately feel the difference. As with a not running shoe your legs, back, side, lungs, heart everything will hurt very badly and you will hate running even more.

For a shirt I recommend this one => Halfords Cycle Shirt

The colour is unimportant. And yes, it’s a cycling shirt. And why? Because it soaks up sweat immensely powerful. And it needs to be a tight fit for it to work. You will enjoy running much much more if you are not sweating all over the place.

For a pants I recommend this one => Amazon Man’s Running Tight

Why a tight? Because it will keep your muscles nicely wrapped and warm and it will soak up even more sweat and it really dries quickly and is easily washable. If it’s a nice weather outside, just put on a short and go.

A couple of things other Blogs don’t really talk or mention.

A running belt. It’s very useful to store stuff in it like =>

– Keys
– Water
– Tissue => You will need it. Every part of your body will loose some type of liquid.
– Phone / Music playing device => There are proven fact that music will help you run better
– GPS => For later because tracking your run will help you get it to improve.

Closing words

It will be hard to start. I know it will be. It was for me too. I’m running for a month now and I finally managed to get into a mind state where I actually LOVE it. I LOVE it. I want it. And I miss it if I’m not able to run. It’s a great exercise. Take care that don’t run everyday. It will make you very tired and give up easily. Run every second day and then increase as you like. But even then include REST(not the protocol…) because your body, tissues, muscle bones need to regenerate.

Don’t overexert yourself. Jog, walk run slow. Doesn’t matter, just run. That’s the point.

Have a very clear mindset.

And run in nature if possible because a treadmill is immensely boring and will kill your mood very quickly. And running in nature will provide diversion and wonderful things like this (my view when I run) =>

After a month of running my record is 7kms and 50 minutes. I started from zero basically. The human is the best runner in the world. I lost 5kgs without changing my eating habits. Just right now as I’m typing this I’m chewing on a gummybear.

So get out there and start running folks. It will help you immensely. There will come the time when you feel the euphoric moment of speed and the wind in your face as your body explodes in a glorious mixture of pain, adrenalin rush, speed, velocity, happiness and bliss. As your body stretches and pulls your weight and your legs launch you forward into the world the feeling as you run faster and faster ignoring everything and just fly. You will start to cry, laugh and sing at the same time.

Running will do that to you.

You have been warned.

Now go…. and live a full life.

As always, thanks for reading!