alikhalid

About Ali Khalid

This author has not yet filled in any details.
So far Ali Khalid has created 134 blog entries.

A Test Harness / Testing tool made of

By | April 30th, 2018|daily post|

Angular 4 + Spring Boots + SQL..

Configuring an ERP can be VERY problematic

Getting settings the exact way a client has can be tough

There are other ways to do that (e.g. use dockerized environments) but there is the old fashion way too

Set your test environment like your client’s do the tests, revert it back

For applications having lots of configs this can be hard

That’s how we started with creating tester’s “own” test product

It had to be scalable, since there are a lot of things we might add to it

So needed a proper structure, which lead to a full-fledged product, a testing tool with:

Front end: Angular 4
Server side: Spring boots
DB: SQL

More on this in coming weeks..

#TechnologicalExcellence #TechnicalTester #RedefiningSoftwareQuality

Looking to select an automation tool?

By | April 29th, 2018|daily post|

Can your brain focus on multiple things at the same time?

In the information economy the people to thrive are who invent

The terms knowledge worker(Peter drucker) and smart creatives (google founders) are common

Yet how much of our time do we spend on thinking deeply?

Shallow activities, just passing the buck around does not create the needed value

At the minimum work with focus and precisely on one thing only

More on the subject: “Deep Work” by Cal Newport

Using multiple tools for automation

By | April 27th, 2018|daily post|

I think you should have the capability

An argument for not using a multiple tools is “Too many cooks spoil the broth”

While this was more valid years ago, now most vendors know there is an inevitable need for integrations

Automation used to be just UI automation, now we have API, DB level checks as well

Distributed teams have caused different team dynamics needing a whole set of reporting and management tooling

Then we have CI / CD in the mix which also would need to be integrated

Case in point, the automation framework must have the capability to support and use multiple tools

#RedefiningSoftwareQuality

More on that here:

 

 

Parameterizing Jenkins

By | April 26th, 2018|daily post|

Did you know you can parameterize your jobs?

Especially helpful for automation

You can parameterize things like the app version / browser / DB / automation framework parameters from within Jenkins

Scheduled job runs will have default values selected every time they run

For manual job runs you can choose to select options from drop downs

The benefit:

All execution resources / environments management and results are centralized

Setting up new run routines or special case quick runs makes a big difference

And the kicker is the visibility you get from all the results in one place and accessible to all

Reasons why we automate

By | April 25th, 2018|daily post|

In the start I thought just to reduce cost, here’s what I’ve learned till now:

– Yes some folks still think to reduce cost; <False> Automation only increases the testing cost

– Substitute testers; <False> Automation cannot substitute tests done by a person

– Increase test coverage; <True> Can rapidly increase features checked

– Provides confidence; <True> Increases the team and the customer’s confidence in the product

– Reduces time to market; <True> Can reduce testing time and supports continuous integration

– Shows commitment to quality; <True> While employing automation does show that, however not a good enough reason in itself

– Can find more bugs; <False> Automation checks ‘stable’ features, ideally it should not find ANY bug..

Care to share other reasons you observed?

#RSQ

Should testers be technical?

By | April 24th, 2018|daily post|

I strongly feel they should

Firstly, let’s define technical: “Who knows how the product is designed and works”

Doesn’t mean you have to be an architect, but reasonable understanding how it works

The reason:

80% code of an application is written at the back end, isn’t it logical to spend time testing on that layer?

And without knowing how that works, it cannot be tested..

Toyota had to recall 2.1 million cars on account of a bug

More on that story here:

#RSQ

PSQC 2018 Conference Talk

 

Humans are underrated

By | April 23rd, 2018|daily post|

“Excessive automation was a mistake” , “Humans are underrated” Elon Musk while commenting on Tesla’s production line

Firstly, Shout out to Elon Musk for being so transparent and honest despite his position

To the point. apparently Having too much automation turned out to be a problem..

It’s ahead of its time, the technology is probably still catching up

In this case, it was just adding (a lot) more robots to the assembly line to what already existed

Then how can anyone expect automation in test to be anywhere near testing how a human does

Bottom line, it would be ‘decades’ if EVER, for automation to substantially substitute for a tester (referring to AI as well)

On the flip side, Automation is still needed for a lot of other reasons..

#RSQ

UI Vs API Automation

By | April 22nd, 2018|daily post|

Which to focus more on..

UI automation is the first place most automation efforts start from

However, the products we are working with have most of the code written at the back end

While the front end has just a small amount of code we have added, all our testing efforts are focused there

With API / Web services automation, one can cover more code coverage

Besides, UI automation is comparatively time intensive, fragile and slow to execute

More on that here:

UI Automation Vs API Automation

#RSQ

Correlation between shopping and testing?

By | April 22nd, 2018|daily post|

After a long day of shopping, while me and my wallet were perspiring and thinking about testing, here’s what we feel:

Shopping considerations – function, fashion and price

The same goes for testing

Function – We need to be sure it does what it’s intended to do

Fashion – The design must feel right, sits well with the users

Price – The cost should justify the effort. Spending lots of effort on testing something trivial every release might not be wise

So next time when testing a feature, think of it as going shopping

P.S.

To make the response homogeneous, imagine a shopping day with the family than just yourself.. ūüôā