Deprecated: Function create_function() is deprecated in /home/qualit96/public_html/wp-content/plugins/revslider/includes/framework/functions-wordpress.class.php on line 258
daily post Archives - Page 31 of 39 - Quality Spectrum

daily post

UI Vs API Automation

By |2018-04-22T21:45:43+05:00April 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:

#RSQ

Correlation between shopping and testing?

By |2018-04-22T00:17:12+05:00April 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.. 🙂

Should we have written tests to automate?

By |2018-04-19T21:45:55+05:00April 19th, 2018|daily post|

Off course..

There is the argument against writing ‘typical’ test cases altogether

Regardless of where you are on that spectrum, steps to automate in a check need to be precise

And what we are automating is as important as how we automate it

Running automated checks itself is not the purpose

Rather facilitate testers by running 1 – “mundane” but 2 – “Necessary” checks,

So they can test more important features while the dumb work is done by a machine

Without carefully thought checks / tests, will be hard to achieve this

More on that here:

Unhappy with automation tools?

By |2018-04-18T21:04:55+05:00April 18th, 2018|daily post|

While some tools might have been ‘unfair’ over the years, that’s not the main problem

The main problem with automation I see is, “we don’t know the best way to approach it”

There are a few variables to analyze before you can decide the best way to do it

And generally tool vendors don’t (and probably can’t do) that job for you

While ‘some’ tools have exploited the market IMHO, it’s not just all them

We as a community are still evolving in this department

While a large part of the community is still confused with the OBJECTIVE of automation..

Kinda hard to be successful under such conditions..

Thoughts?

Should you be a programmer to do automation well?

By |2018-04-17T18:36:04+05:00April 17th, 2018|daily post|

Short answer, yes. Long answer:

Firstly, learning programming is not as difficult as expected

Usually people just follow the wrong approach

That’s why I talk about developing the aptitude for algorithm design

Secondly, there are solutions out there recommending automation tools requiring no coding skills

These ‘Scriptless’ automation or keyword automation tools are not ‘sustainable’ and don’t work in the long run

Therefore one needs to learn programming and how to code well

Thirdly, IMHO testers should be ‘Technical’, without knowing what’s going on under the hood, they cannot test well

If you are capable of grasping that much, then learning programming would not be a problem

These topics were discussed in the #PSQC18 conference talk I gave:

#RedefiningSoftwareQuality

The story of excellence

By |2018-04-16T20:37:10+05:00April 16th, 2018|daily post|

Henry ford and his V8 engine

Ford designed and rolled out 4 cylinder and a 6 cylinder cars back in 1909 and 1928

Both were great feats in itself, and not the only ones Ford had earned by that time..

Still he was not done yet.

He knew having more cylinders in the engine would allow for great performance benefits

His team of engineers worked on it for years, keep coming back to him saying it was ‘impossible’ to achieve

After years of pouring in finances and persisting, finally the impossible happened

Our sixth sense is a magnificent gift, one has to wonder how did Ford know this was going to work

But to trust your gut and keep persisting, that is how you truly get success.

So my fellow testers, let’s strive for ‘Technological Excellence”

#RedefiningSoftwareQuality

Which tests to automate?

By |2018-04-13T22:24:19+05:00April 13th, 2018|daily post|

Someimtes folks look at this from the wrong perspective

Instead of looking at what is ‘supposed’ to be automated, they look at what ‘can’ be automated

Not to say try automating stuff which does not justify the effort

But the master set should be out of what we are supposed to test, and then find a subset of tests which can use automation effectively

I suggest 4 points to determine this subset:

Excellence is an attitude

By |2018-04-11T21:48:18+05:00April 11th, 2018|daily post|

Either you have or don’t and it’s not a one time thing

Very few ‘might’ have this from childhood

But many acquire it over time and with practice

Excellence can be a potent driving force behind software quality

Once a culture of excellence is established, then the ride becomes a lot more fun

#RSQ

Debugging Sherlock Style

By |2018-04-10T20:38:29+05:00April 10th, 2018|daily post|

Can we learn something for Sherlock on how to debug UI automation problems?

There are commonalities between debugging and a crime scene

Both have a couple of unknowns we have to find answers to

With the exception of a murderer trying to clean his tracks..

But debugging complex code bases can be somewhat similar too, in terms of the unknowns

The first thing to learn is study data that is available instead of jumping directly into reproducing the problem

Most often we don’t have enough data (or understanding) which is a situation we should not have in the first place

By analyzing data we can arrive at a very precise reason why there is a failure

Which, in turn, helps us solve the problem in the first or second debug attempt

If not, then the good old ‘buck shot’ method hoping to luckily stumble over the problem is attempted (we are all very familiar with)

For more lessons from Sherlock:

Go to Top