alikhalid

When non-tech people hear ‘automated’, what does that mean for them?

From past 100 years history, Automated = losing jobs. In testing however, that’s not completely true. Here’s why:

In other industries remedial and repetitive jobs are being automated rapidly, blue collar jobs.

Like car assembly lines, bank tellers, until recently driving cars / trucks and making Pizzas.

With AI and ML, some white collar jobs are also a target e.g. radiologists.

However with testing, actions to ‘test’ a software are not always as simple.

It’s not just a matter of performing some steps from a test case,

It’s more about collaborating, discussing and clarifying requirements,

Challenging the understanding held by different groups and figuring out what the business really needs,

Talking to different groups and communicating the AUT’s actual response.

There are a lot of activities involved in this, especially collaborating and reasoning with people,

Which are not based on a set of principles we can script in advance.

While that does not mean automation tools will not be used (more in the next post), I feel they cannot replace testers.

Lots of systems reusing different JSON schemas, which we need to mock,

By using JSON schema / template files to construct and push custom JSON messages to different systems..

Here’s where I have reached so for in solving it and the implementation steps:

Step 1 – Basic structure to push a given JSON file to one system

Step 2 – Add support for more systems to push messages to

Step 3 – Create library to take a ‘JSON Schema’ as a template, and fill placeholders with test data values

The need arises when we have mulitple products to push messages to, all having different JSON message structures,

For testing these systems, instead of having ‘n’ number of JSON files, one per script, I’m thinkging of having standard templates for each product

Which will hopefully make it easier to mock test JSON files, and

Instead of passing the complete JSON, just the template name and a few variable values should do the trick

Still each script might have a sort of ‘config data’ file, but should be quite homogenous within products

Any other ways you’ve tried to implement this, or thoughts on this implementation?

#QSDaily #Automation #MockingData #JSON

To couple your framework tighty or loosely, that’s the question!

And here is my thought:

The first answer straight away is – loosely coupled off course,

Which is true, but how loosely?

The answer would be highly dependent on the context and usage, so there is no single answer.

Here are some general considerations to think about:

– Configurability
– Maintainability
– Reusability
– Robustness
– Scalability

Unforunately, most of these are polar opposites
– Reusability / configurability vs maintainability
– scalabiliy vs robustness
– configurability vs robustness

The trick is to strike the right balance between these factors,

Which would depend on the context and usage.

To give an example, a common one which I always mention is configurable vs robust,

As you add more features to your application / framework and make it more configurable,

It is bound to be more prone to errors and unknown states in the system.

That’s why we have the McCabe complexity measurement..

Anything else you would consider to determine how loosely your product / framework coupling should be?

#QsDaily #automation #FrameworkDesign #SoftwareArchitecture

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/