Daily Posts

Generally how does your team go about doing testing or automation?

Most people (in my experience) jump right into writing test cases or automate written tests… anything wrong there?

The source of tests is usually a bunch of written statements without any context from which testers start create test scenarios

Occasionally might have a chat with the BA or product owner if they find the time.

What’s missing here is the context, the understanding of what problem we are trying to solve

Now just if you wrote a ‘story’ doesn’t mean you got all the context.

It is imperative to talk to marketing, product and support to understand why we are building this product, how is our solution different from others in the market.

Understanding the competitive advantage and pain points of the consumers gives the testers context and a yard stick to gauge what’s important.

Shadowing how the customers use the product in the field is another good way of gaining context into the solution.

Any other techniques you’ve used to understand the context better?

Why do many enterprises go through Re-Orgs?

Here are a few reasons I’ve figured out so far:

• To increase efficiencies
• To reduce cost
• Technological innovation
• New management comes in with a new mandate

The root cause of most of these is large organizations having problems with adapting to change and having a hard time innovating

Could be because of:

• People are far away from the vision of the organization, feel like a small cog in a big machine
• Extra governance, lots of red tape,
• People become complacent doing the same job day in day out
• It gets harder to hold people accountable due to long and complex processes
• People have no reason or motivation to change

IMHO the mother of all problems is lack of motivation.

Whatever course of action is taken to solve the organizational problems, if the teams are not motivated, long lasting change is highly unlikely to happen.

Leadership lesson – Give permission to challenge

 

What does this mean:

• People sitting at the meeting table should feel empowered to disagree with any point of view, especially if it is of the leaders in the room

 

Why is it important:

• It is not individuals who take the day, teams are the ones to bring success. Physiological safety is the secret of team’s success
• Unless the team feels they are empowered to speak their mind, physiological safety cannot exist.

 

How to do it:

• The leader should not share his / her opinion at the outset, so everyone feels comfortable to share their opinion
• Probe people to challenge the status quo
• Do not let anyone feel punished for challenging the status quo – ever

 

Trouble shooting:

It is possible you might sometimes face confrontation for the sake of it and not for improvement. In such a case:

• Time box the discussions and assert a decision must be taken before a set deadline
• Try to use as much factual data as possible
• If a decision is being taken against what the data says, bring back the discussion to deciding based on data

 

Reference material:

• How Google works by Eric Schidt
• Chapter – Decisions, the true meaning of consensus

 

While redefining the QA function at work, I keep coming back to this question:

What is Software Quality?

If we deliver exactly what the requirements / user story says, is that quality?

We’d say that’s validation, so we must also do verification which is ‘are we building the right thing’,

The problem there is, in a large organization a bunch of ‘groups’ have to sign off.

Now the ‘end users’ (if you will) don’t align to a single version of what’s expected.

That’s why I sometimes feel developing software is not a science, it’s an art.

It’s an art to bring a vision of a select group of people to life.

The details of the vision for all might be different, but they all might be connected with a common emotion.

Therefore, in the end, it’s about answering to that shared ‘emotion’ of the stakeholders.

Going through the SAFe DevOps course I realized there were a few good points.Going through the SAFe DevOps course I realized there were a few good points.

Again I don’t believe in following any Agile framework to the book and take them as just guidelines, but the SAFe DevOps section does help to put things in perspective.

The image [1] attached is called the ‘DevOps Health Radar’ depicting the different stages of how an enterprise can deliver value to customers from:

1. ‘exploring’ an idea, to

2. Development, testing at speed through continuous integration, to

3. Deploying to a subset of users through ‘dark launches’ and ‘canary releases’, with sanity tests in prod,

4. To finally ‘releasing’ to all the customers on demand and validating the assumptions business had in the exploration phase

Reference:https://lnkd.in/fcZB5sB

[1] : Rights SAFe (Scaled Agile), Illustration graphics by Quality Spectrum

The new UAT: Dark Launches and Canary releases

Here’s what they mean and the difference:

Before that, UAT (User Acceptance Testing) is where once the software is shipped from IT, business / end users have a look and run their own tests to see if the product is as per expectations.

Now that was inefficient and UAT sometimes takes a lot of time, which can skyrocket time to market.

How the industry is solving it?

productionize the software, but to a user’s subset

Launch to a certain few clients / users of a certain market segment. The Idea is to get ‘real’ users actually use the product.

This way feedback from customers is quicker and as real as it can be.

The catch:

To do dark launches or canary releases, besides the obvious of having scalable infrastructure,

You need to be able to roll back and fix forward real quick, for which you need CI/CD in place.

Because there is always a higher chance of something being missed, so we must be able to fix it real quick.

If you were to describe what QA’s role would be at an Enterprise level, what would you say?

Here’s my thought so far:

Fundamental goal: Validate goals set by business for the end product are achieved and highlight any risks to decision makers. This can be done by:

– Help POs, PMs and business in making sure the articulated user stories fit the purpose (question requirements)

– Ensure testability within the system architecture

– Foster a ‘quality first’ culture / build ‘testing acumen’ by promoting and teaching the test mindset within the whole IT organization

– Test the holistic system from end to end’s functionality, usability and non-functional requirements (performance / security)

– Ensure tests among different integrated systems and low level components are done

– Enable CI/CD pipelines to significantly reduce time to market

What else would you add?

#QsDaily #Enterprise #Testing #TestingAcumen

Universal truths to ‘internalize’ to really go agile:
1 – We cannot estimate effort
Without accepting this, we try to ‘accurately estimate’ the amount of work and run into the same trap

2 – We don’t clearly know the requirements
Again, instead of focusing on getting the product out in the hands of the customer ASAP, we sometimes try to ‘refine’ the product

Off course this is easier said than done. To significantly reduce time to market a lot of enablers would be needed.

However, without the mind set change, all the tools in the world wouldn’t bring about the desired results.

#QsDaily #Agile #estimation #requirements

When to ensure testability for your product?

While designing the architecture..

While mkst of us know this, very few actually see it through.

We build a piece of software and then decide how to test it,

Instead while designing it make sure you have ‘test probes’ in there.

When I worked for safety critical applications, we left test points on the PCB to check the circuit

Those points were not used for any feature of the product, but were there just to help test it.

So, testers get involved when the architecture is being designed,

Or the architects trained to ensure the system is testable themselves.

What is the difference between testing micro service and monolithic applications?

First off, the definitions:

Micro-services: Software is developed as several small ‘services’ which can operate autonomously

Monolith application: One giant software with all services within the same software package

The fundamental difference for testing these is scalability and integration.

Micro-services are designed to scale up and down as users of the service increase, so testing this scaling up and down is important.

Secondly the integration tests become more important. Communication between these services is different from a monolith and should be accounted for.

While there will be many more subtle differences in testing these depending on your context, these two areas would always be of importance.Anything else you would add to the list?

While DevOps is thought to be synonymous with tools and automation,

Actually, IMO, it has to do more with cultural transformation..

The ultimate goal of DevOps is to bring what we develop faster and more useful to our customers

While automation is certainly a big part, even more important is the culture.

The tools just fast track the thought process we have,

It’s the experimentation with different ‘thought processes’ which is the secret

I always quote “Companies to take ideas to in the hands of consumers the quickest will win”,

Because they can experiment easily, and don’t have to fear a failed experimentation.

Now if the culture is not there, experimentation will not happen.

Then all DevOps will do is to facilitate in getting more “crap” out of the production line, but just “quicker”…

 

#DevOps with #CulturalTransformation = Measurable business value

#DevOps WITHOUT #DevOpsCulture = Same old crap, just delivered quickly

Automation helps by doing repetitive tasks efficiently

What happens when your code is not exactly ‘reusable?..

Automation engineers sometimes are trying to script for the immediate test scenario

And forget the whole point of automation was reusability.

This is different from a script breaking from not have good selectors..

Writing similar code across the project in multiple classes / files

And again repeating that in mulitple projects across one on multiple products

So make sure to keep each component of the framework reusable

As reusable as possible, not for just your project, but if synergies exist, between projects as well.

The concept of ‘loosely coupled’ somehwat captures this idea.

#QsDaily #Automation #FrameworkDesign

 

More on the subject here:

 

A couple of ways to cope with web browser version updates,

Using the AUT’s own JavaScript functions is one way to mitigate issues, let me explain..

Depending on what type of application you are using, there can be custom JavaScript code running on your AUT

For cases like on interacting with a certain control a custom written JavaScript method is called to collect some data and pass to an AJAX call.

Think about it, wouldn’t the developer be using some methods to write data in the fields? Or read data from them?

In few cases they are the same as the Selenium library would use, however in a few cases there would be some custom methods,

Written by the developer or provided by the framework.

For instance, on entering data in an certain element on the web page, a JavaScript method is called parsing the data and sending an HTTP request.

Now instead of trying to interact with the element through Selenium / other library, call the JavaScript method,

Which is going to be called anyway on the mouse click / enter event, but can save you a lot of grief if Selenium has a hard time interacting with the element due to a browser update etc.

Working together with teams can be difficult sometimes,

Instead of treating the situation as ‘Us’ Vs ‘Them’, here’s what I think:

All of us have similar desires, dreams and fears.

And each person is operating under certain limitations restrictions imposed by the environment they are in.

Mostly their behavior is driven by goals and limitations around them.

Being empathetic and really trying to understand thier limitations makes things a lot easier

It’s hard, time consuming and requires more attention,

But has lasting results and builds trust.

Granted cannot mot be done for every situation,

But where taking this hard route possible, this can do wonders,

Time and again I have experienced exponentional results with this, more on that in a separate post.

#QsDaily #Positivity #Empathy

Time, Money, Freedom; What’s more important..

Time is the single most valuable asset, here’s why:

Money:
– There is more than enough money and resources to go around, we’ve trained ourselves to believe in scarcity and spend our whole lives chasing it.

Freedom:
– In this age I suppose freedom is a relative term now, someone is more free than the other based on their circumstance,
– But NO ONE is absolutely free of any consequence. You are as free as you ‘think’ you are!

Time:
– The asset which is truly scarce is time.
– It cannot be replicated, or bought. A second gone is lost forever.

Successful people utilize their time to the fullest. The one to manage time the best will win.

An inspiring video from Arnold Schwarzenegger where he talks about his success and how he managed his time shared below.

#QsDaily #time #success

What is the most precious asset on earth each person has?

Options:

a – Money
b – Time
c – Freedom
d – Not mentioned here..

Here are some clues:

– Everyone has it, less or more,
– Everyone needs it, but always under estimate how much they need it, and
– Most of us are easily willing to trade it for other things..

What do you think?

P.S.
This is improtant for testers to learn,

It teaches us what is important, hence what to prioritize for..

#QsDaily #goals #testing

Since testing cannot be automated, therefore no need to learn automation.

While the first half is true, the conclusion is not..

While collaborating, investigating and reasoning with people cannot be automated,

The kind of applications we are building now cannot be completely ‘checked’ in person either because of:

1. Size of the applications
Layers of abstraction have made things easier to develop, and add features more quickly,
Making applications exponentially grow in size.

2. The complexity level
Desktop apps, to monolithic web apps to native mobile apps to now miro-service architectures,
It’s quickly becoming impossible to test core features of applications without a LOT of different tools

3. Required speed to do the job ‘in time’
A first mover’s advantage can mean the make or break of the company. This coupled with the drastically evolving technological landscape for software development has spiked the need for rapid deployment.

These three things are fundamentally shifting how we can adequately test applications.

We need grunt workers to do the heavy lifting for us,

‘Probes’ to get into the system which we cannot easily test,

Which all points to the need of automation and a LOT of testing tools.

#QsDaily #Automation #WhyAutomate

 

 

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