Coding challenge - Sock Merchant

I hate test tasks so much I spend four hours out of five to think why I hate them so much. This time I came up with the following list of whys:

-- expectations are never clear and when they are clear they are clearly about knowing rules for the game, not actual solving something from the scratch, to be successful you need to be familiar with known working solutions, not work on your own;
-- ruminating about what your interviewer brain processes is very distracting, cause practice proves that they may be thinking lots of things, almost all of them not in your favor.

What would be better, array or collections? If you use array they will think you don't know collections. If you use collections they'll think you have a habit of over-complicating things. And if you use for or if  they'll think you've worked with legacy for too long and sustained irreparable brain damage.

Well, anyway, original task is here, and my version of code looks like this:

Know your round numbers or how to get 2^X with bash

Since I haven't written anything valuable for a long time and still have no ideas how to fix it, here is an example of how bash can actually help you quickly get values of two to the power of something. So, here we go

pg@dana:~$ for i in {1..100}; do calc "2^$i" | xargs echo; done
2
4
8
16
32
64
128
256
512
1024
2048
4096
8192
16384
32768
65536
<...>
1267650600228229401496703205376

Just in case you want to get to the bottom of it, this mini-script uses:
-- my favorite calc application (package name apcalc)
-- cycles (for ... ; do... ; done)
-- ranges ({1..100})
-- redirection with xargs ( | xargs echo)

Enjoy your Linux!

PS: 'Round numbers' in relation to 2^X is actually an inside joke from the times when I couldn't afford to rent my own flat and had to share

Mnemonics for maven - three funny phrases to quickly remember what maven default lifecycle is

If you, like myself, often have to switch between different technical stacks, you may know what it feels like not to be able to recall something you put so much energy in just a little bit earlier. Time has come to do something about it.

As you probably remember maven supports three built-in lifecycles: default, clean and site. The latter two are more or less straightforward, but default one is not so. And today, tired of putting it off, I, finally, did these phrases to memorize phases of the defautl lifecycle.

Here they are:

Very Curious: This Parrot's Voice's Indefinitely Deep
Vault Closed To Put Valuables In Dens
Vessel Carries Ten Pink Velvet Ingenious Dogs

First letter of each capitalized word should map on this: Validate > Compile > Test > Package > Verify > Install > Deploy.

Of course, you still have to remember about goals and executions, not to mention the other two lifecycles and their phases, but that's the start.

Good luck.

PS: For more information on maven please checkout these:

• maven official
• brief but informative explanation of maven phases and goals

Build your own Goldberd machine: Selenium via SoapUI

NOTE: The code examples I refer to in this blog are no longer available, but you can still read the text

Hello, friends. Here is how you can have Selenium run from SoapUi Groovy script step. This solution was created and tested with:

• SoapUI 5.X
• Selenium 3.X

In brief, you need to

• upgrade the libs under $SOAPUI_HOME/lib (! not bin/ext)
• use a custom java library (goes under $SOAPUI_HOME/bin/ext)

Auxiliary materials.

Code examples can be found here. An example of a project with a Groovy script is inside the project under auxmaterials folder.

Total automation with sellotape and glue

Luckily for all of us every profession evolves, and test automation is no exception. What I can see is test automation is now more affordable, and is done in a more professional way than before.

Same goes for approaches and tools (and for those who still trust Internet more than their own judgement, some gurus have already posted a very good knock out article leaving losers like myself with a tingling feeling of guilt for being too slow to update the blog).

But there's still another subject I would like to speak about. It concerns the approach to automation in general. Actually, it intends to slightly shift the way we understand automation and targets some of the popular stereotypes in attempt to get rid of them.

Some ideas to help you explain to your project manager why things just do not happen by themselves

You can't always get what you want


Result is not something guaranteed, not something you can count on, no matter what. Result is something you can get, if you are lucky and all the conditions are in your favor, and you can focus, and you are prepared to invest some extra effort, if you, despite all the desperate measures, run out of your resource.

I observed that planning is often done without even attempting to check if the goal or its parts are really feasible. The industry seems to be forming this habit of not questioning the task unless problems are too obvious. They pay you for doing something. And that means there's no way back, because some other people have already committed to do it, so now you have to provide a solution to support their commitment.

This way of doing things is not very helpful when it comes to planning, especially if area is not sufficiently familiar.

Flow for Managers

There's no such a thing as a universal way to do your job and not let it kill you.

To achieve the best results some professions need to work in a flow, and some -- in a quick succession of tense-release phases. And, among other things, 'the result' is assessed by how much better your life has become (or maybe it took a turn for the worse).

It looks like Pomodoro-like techniques are best for managers who are forced to operate in a quickly changing environment, while flow is necessary for engineers and researchers.

QA Venn Skillset Maps

I would like to share with you this little trick.

I use it every time when I need to find out, how hard it would be to learn something new. You can use it for yourself or for your team members. There are a lot of situations when you may need it, for instance:
-- you are building a matrix of competence, 

-- or calculating the team capacity,

-- you are thinking about taking a different a job, 

-- or starting a new project and not sure if you are up to it,

-- or maybe you are hiring someone and need to assess their skillset.

Average QA expertise can be represented as a Venn-like diagram. As you can see, it consists of three major parts:

• skills related to the test itself (QA): such as QA theory, certain cognitive skills, decision making skills, logic in a broader sense;
• tools-related skillset (Tools): knowing our tools, whatever they are, from test management systems to programming languages;
• knowledge of the domain (Domain): dark secrets of this particular trade, be it banking, telecommunication or IOT.

Some Examples of Bash for Use in Test

Time has come to finally write something of technical nature, not just another advice on how others should work to make me happy. So here is a cheatsheet for a tester who spends at least some of her time with nix console. For obvious reasons it wasn't my intention to cover everything, so please take it just as a memory refresher (or a source of ideas it you find it useful).

NB: It is assumed that as long as you understand what man is, you are fine (use it if my explanation is not enough).

The major three - On the importance of smiling

You lot, you spend all your time thinking about dying, like you're going to get killed by eggs or beef or global warming or asteroids. But you never take time to imagine the impossible, that maybe you survive. This is the year five point five slash apple slash twenty six. Doctor Who, IX (quoted by Internet transcript)


In my experience, probably the most popular reason of a conflict is when someone (apparently unaware of what's important and what's not, or, worse, having his or her own opinion about the matter) tries to push their agenda, thus putting your interests in danger. That's what missionary's complex feels and looks like.

I don't know why (and probably the origin is not that important here, unless we regard a problem from neuropsychophysiological point of view) people (we) sometimes tend to feel their (our) job as a kind of a mission. It may be good when we want a good motivation. It is not that good when we need a team to function harmoniously. Meaning, if not altogether without a conflict, but at least without coming to a halt due to unresolvable contradictions between its members.