Month: January 2015

It’s all about laying blame

I heard this in House MD

Good things happen often, Bad things happen sometimes.

If you are are talented and skilled you will try things that others are afraid to try out and because you are going to live dangerously there will be times when you will fail. What you did and What the outcome is are 2 different things. You can fail or succeed but that will have no bearing on whether you are right or wrong. So next time you have to make a tough decision where the chances of failing are high don’t be afraid – do the right thing.

There will be some who will try to lay blame but eventually you will see – people will realize that your process works because you succeed and disrupting your process makes you ineffective and no one wants to do that.

Motivated or Skilled?

It’s interesting how when we have to select a bunch of people to be on our projects we immediately latch onto the skilled ones whether or not they are motivated and the average guys are first ones to go even if they have a vested interested in our success (as they succeed along with us).

Next time when you have to make a choice of keeping someone on the team, pick the one who will do anything to make you successful and you will be surprised what that person will do to gather all the skills needed. He will do everything and a lot more to make him/her successful and in the process you will see success beyond your wildest imagination. You just need to provide them some mentorship – thats all.

Alternatively, keep finding ways to motivate people but don’t forget The Paradox of Rising Expectations.

Just Write away…

I have been meaning to write a few articles for “let’s just say someone” but that publication will mean a bunch of reviews and approvals. I get the fact that I am getting publiched in anotehr brand and they need to make sure it (if not represents) fits the bill. Having said that, the fact that a person is reviewing my article may have very different opinion on the topic and that difference of opinion will impact how my article is reviewed and if gets selected or not.

This article is my POV and what I want to tell the readers, and not what this reviewer thinks and what he wants to get out. This is not just an “edit” on punctuations and language but on my thoughts is my biggest deterrent on writing for any other publication and I realized that those 2 articles have been sitting in draft mode for 18 months now. It just gets “uuggghhh…”

So my advice to myself here and to all of you out there – “just write away.. find a way where you just get to state what you think // dont get stuck into that review trap”.

Unit Testing in AEM (thinking loud)

This is not a recommendation of any sorts but a culmination of ideas and a few options that are available for us to use if we want to do unit testing within AEM. I had done some research for a client some time back and this article is largely influenced by that work but a lot of contextual stuff has been pulled out. I have still tried my best to ensure that the article here holds it’s essence. I will try to do a follow-up soon with a lot more details.

Option 1: Use Sling tools and test in-container

Apache sling has released a set of tools http://sling.apache.org/documentation/development/sling-testing-tools.html which can assist unit testing in the application. There tools offer several ways of doing the testing like a) good old JUnits where there are no external dependencies or b) Use of mocks – sling provides readymade mocks which reduce the effort or c) we can deploy the test cases in a CQ box (or sling) and run using OSGi references.

The approach I am recommending here is where we will deploy JUnits in an already hosted CQ instances and invoke the test cases remotely. I understand that this is not “old school unit testing as i am not abstracting any dependencies and my units include dependencies” but i have a reason for doing that. As a matter of fact if you have been following up my writings on unit testing you would know that I am not a big fan of mocking and actually am very happy to do any unit testing against dependencies if i can set it up.

 To do this we need a few things to happen as follows:

  1. We will need to have a hosted CQ instance that can be used as a container for running test cases
    1. We can use embedded systems but then we will have to spend additional effort creating content and what not. Also the embedded container will be sling and not CQ and we would like to keep the environment as close to what we use as possible
  2. The CQ instance should have a pre-populated set of products and images (this setup does uses AEM eCommerce module and PIM and DAM have been integrated with external systems) and that acts for us as readymade test data. These can be achieved using our backend integrations. We can chose to do it independently or can do it automatically (automation of these things can also happen over time to allow us to start quickly)
  3. For interactions with any backend services (like Order Management, Pricing, Account information), we would need to have a backend service instance running (as i said i prefer systems over mocks if possible) with all the variables and pieces setup. This instance should also have various data setup like user accounts, products instances, availability, prices, etc to ensure our use cases work. There are obvious challenges setting up independent backend services and we can explore one of the following 2 options
    1. Capture all requests and responses for a certain request type and serialize those into a test-data store. It can be a huge XML that we can store in a key-value pair sort of a system – can be a database like mongo (even SQL would do) or we can serialize on file system or;
    2. We can use an already existing backend system

Option 2: Use selenium as the functional testing tool

In this approach I am recommending not to use JUnits at all. The idea is to use the philosophy of system testing which can test all of your units in the code. This is a big departure from the traditional way of unit testing where all dependencies are mocked out, and we can run several tests quickly. While Option 1 is also to the same effect, in this approach we go a step further and leverage our system test suits. The idea is not to do this for every single use case, but pick up business critical functions like checkouts, order management, account management and automate those. The selenium scripts can then be integrated with a JUnit runner where we can then integrate it with CI tools and can run it from Eclipse or Maven and hence can be integrated with CI itself. This saves us the time to write those JUnits and manages a whole suite independently. This approach also needs a hosted CQ instance with product data setup, some content setups, and backend integrations just like in Option 1.

Of course this is bit tricky and not really unit testing but it has some huge upsides if done right.

Don’t be afraid to course correct

When driving a car if you sense a flat tyre; do you stop and fix it or do you just go about driving with a sluggish pace which eventually will lead to an accident?

I guess we all know what we will do! So when we see a problem on a project why don’t we take the time and fix it? Why do we get afraid of telling stakeholders that something has gone wrong and we need to course correct which might lead to an increased cost or a bit of a delay in schedule?

I am sure the counter argument would be – we do fix it or inform it. I am sure if you introspect enough you will realize that we do one of the following:

  1. It’s trivial and we can deal with it ourselves – leads to no communication and eventually there are enough stacked up trivial(s) which eventually leads to cost of schedule gone wrong or;
  2. It’s a engine gone wrong and the cost is already so huge and I will blamed or it will taint my reputation of not being able to handle it well so let me fix it

Either ways you will find yourself screwed compared to if you would just tell the stakeholders who will more often than not be able to share some ideas of how to fix the problem faster. You may still end up bearing the cost (which you do anyways) but your journey towards delivering the project will be so much relaxing and i can almost guarantee your relationships with the stakeholders will be lot more trusting.

Start by getting familiar

The level of confidence a team can get for the number of functional defects that a client can find in UAT has a direct relation to how much they know of the application they are building. You can write any number of scripts (manual or automated) but unless you get yourself to be in a position where you are like a user of the site you will never know if what you are testing will meet the client’s end requirements.

So at some point in time, get to know the application upfront even before you write a single line of code or test script or find someone who does. It’s no different from how our mind works when we travel from home to office or to a new place – either we know where we are going and our eyes and brain give is immediate and instant feedback if we go wrong or we need something like Google Maps to tell us (even though it is a bit delayed).

This is a step that you need to have to be able to deliver Quality on any project