daily post

One of the toughest jobs in an organization is change management

Because we humans don’t like going out of our comfort zone, but it’s equally important..

Those who don’t change will die out, no matter how big they are,

But how to change? I’m no expert but here’s what one of my Guru’s taught me:

“Culture always comes from the top, Change the person at the top, and the effect will trickle down”

To change one person’s mind is easier than changing many at the same time

I know that’s easier said than done, and many of us have thought at some point “I might as well argue with a wall than this person”,

But whenever I’ve tried to push change from the bottom up, it has never worked.

A note to the wise, when building a team, don’t let the culture just grow like a mushroom,

Once formed will be very hard to change, so make sure you’re consciously building the right one.

For multiple products (with different teams) creating one huge solution,

How would you structure the automation framework? Here are few options:

Solution 1 – Separate frameworks for all products

Solution 2 – One framework for all products across the same automation type

Solution 3 – Common framework and libraries for each automation type, with separate POM and tests layer for each product

There can be other ways, these are the three I have seen been used over the years.

Which one do you think would suit best for this structure:

– Different teams working on separate products eventually all joining to become one huge solution
– All these products have separate time-lines, but are also interdependent on one another
– End to End tests will obviously be needed to verify across all the product lines as one holistic solution

(I don’t want to share my choice upfront to avoid any bias)

For multiple products (with different teams) creating one huge solution,

How would you structure the automation framework? Here are few options:

Solution 1 – Separate frameworks for all products

Solution 2 – One framework for all products across the same automation type

Solution 3 – Common framework and libraries for each automation type, with separate POM and tests layer for each product

There can be other ways, these are the three I have seen been used over the years.

Which one do you think would suit best where:
– Different teams working on separate products eventually all joining to become one huge solution
– All these products have separate timelines, but are also interdependent on one another
– End to End tests will obviously be needed to verify across all the product lines as one holistic solution
(I don’t want to share my choice upfront to avoid any bias)

#QsDaily #automation #frameworks

The importance of leadership and believe in their vision

A lesson I was reminded of in the orientation today

In a presentation we went through the history of Dubai and achievements of the Emirates Airline

Born and raised in the Emirates, listening about it’s history from it’s elders, I’ve always had tremendous respect for the founders and specially Sheikh Muhammad.

The best line I felt was when he founded Emirates Airline while handing over initial capital for setting up and said something along the lines:

‘You should be self-sufficient, don’t ever ask for more again’, and to my knowledge the airline never had to..

The man had such a great vision, determination and conviction.

I’ve heard people say, “When money talks, bull***t walks”,

There are many other countries with massive wealth but are not successful.

It’s not just finances, having a vision and conviction to get it done is far more valuable.

As a reminder for myself and the reader, have GRAND visions, 10x your goals,

And then believe in them as they were the past, “UNSHAKABLE CONVICTION”.

IMHO this is the greatest recipe to success.

#QsDaily #success #leadership #goals

Everyone feels it is necessary for testers and developers to collaborate,

But then why don’t we see them do it most of the time?

Off course there is no one answer to this.

Over the years I’ve seen many reasons, and will keep discovering new ones.

The one that I hate the most – middle management is not ready to loose control.

Sometimes management at both sides wants to ‘horde’ power and deliberately create these barriers.

“Your tester should not talk to my developer, there taking too much time”

“Developers should do their unit test and not ask testers to do that for them”

The root cause at most of these, afraid to loose control and give freedom to the team to act for themselves.

I can tell you from experience, loosing control is sometimes scary, but you need to have faith and build mutual trust.

With these silos the product suffers, and the workplace becomes an unpleasant place for no reason.

So build trust and have faith. You tried to hire great people, now give them the liberty and freedom to shine.

#QsDaily #testers #teammanagement

Java Vs JavaScript for automation?

Here are a few factors I would consider:

– Community support: much more for Java

– Ease of coding: JavaScript code will be short and easier. However Java would be more capable to scale for very complex and large frameworks.

– Ease of learning: JavaScript. It’s a procedural language, Java would require learning OOP concepts.

– Learning content availibility: Java, since it’s the most popular language for automation

– Integrations: Java, most automation related open source libraries would interface with Java code

– Interfacing with AUT front end: (this means accessing front end AUT methods, running JQuery / JavaScript commands directly). JavaScript would win here naturally. However Java wouldn’t be that difficult either.

– Long term perspective: learning Java will create more career opportunities because of its wide use

At the end I must add, depending on how comfortable you are with programming, it’s a good idea to start with a simpler language like JavaScript and python, then move your way up.

You’ll never (or should never) get stuck with any one language. So pick the one that suits your current situation.

Automation tool selection can be a big problem,

Here are a few fundamentals I try to stick to:

1. Goals of the project
– Be crystal clear on what you want to accomplish with the project
– While most automation projects might have similar end goals, not all would have the same priority

2. AUT
– The most important factor to dictate this decision, understand the AUT (Application under test) and figure out what you should value the most in your automation framework.

3. Integration
– Your automation framework might not (or should not) comprise of any one tool,
– Make sure it integrates well across the SDLC especially any CI tool (even if you have no plans for CI)

4. Support
– Automation tools have to put with a LOT of change,
– Make sure the community surrounding the tool / library is very active and on top of their game,

A few more points and further elaboration on the ones discussed here in linked article

#QsDaily #automation #automationtool #automationframeworkdesign

http://quality-spectrum.com/automation-tool-selection-dilemma/

“How long before you typically ‘hand over’ automation”,

While THE question might be valid in certain circumstance, it completely misses the spirit.

Automation can NEVER be ‘handed over’ and be done with it (unfortunately),

Simply because as your application evolves, so should your testing, and so should your automation,

Wishing for the day when automation will become ‘automatic’ is an absoltely wrong goal to have.

Linking an article further elaborating on the subject.

#QsDaily #automation #testing #roi

Building a test arsenal is THE MOST important aspect of automation,

Yes, that’s right for automation, because the automated scripts are as good as WHAT they are ‘checking’..

Often the focus shifts from inadequate testing practices to directly building automation,

While investing in automation is essential, equally important is ‘finding’ the scenarios to test.

Unless there is a great ‘Testing acumen’ built within the team, that automation is not going to give the desired results.

All automation will do is reduce the ‘checking’ time you spend, and if you are not very sure what to test, then what’s the point?

It’s like trading in a car for a jet, but not sure in which direction to go in..

#QsDaily #automation #testing

A lot of candidates have a hard time finding jobs,

And employers have a hard time finding good employees too, here’s my thought on that..

Employers are looking for a very long (and many times invalid) set of skills, giving what’s really important a low priority.

Similarly, employees are not always clear on what they enjoy doing, and most end up hating their 9 – 5 jobs.

The answer, IMHO, is to find what you as a candidate are passionate about and love to work on,

And the employer to find our their core values and look for people sharing the same belief system and ENJOY working on that craft.

E.g., it’s not necessary every Java developer with 10 years of experience is passionate about working in that field (tragic really).

In the linked post (below) I talk about finding what you like doing and employers finding people who align with their values.