Comments for Quality Spectrum

Comment on What is API Testing by Umer Ali

Umer Ali — Thu, 14 May 2020 02:27:47 +0000

Hi Ali,
Thank you for the insightful article. I would like to ask you a question; In your own words, when do you think it is suitable to do API Automation and UI Automation?

Comment on How to Hire an Automation Engineer by Ali Khalid

Ali Khalid — Sat, 09 May 2020 14:40:41 +0000

In reply to Sami ullah. It is very unfortunate & sad indeed.

Comment on How to Hire an Automation Engineer by Sami ullah

Sami ullah — Sun, 03 May 2020 14:56:15 +0000

You have listed the things nicely..sadly testing interviews revolve around theoretical knowledge rather than practical..

Comment on My key learnings in 2019 by Ali Khalid

Ali Khalid — Tue, 07 Apr 2020 16:21:42 +0000

In reply to Bernard Londeix.

Thank you for adding Bernard. Finding the right software metrics to measure is something I’ve been trying to research for years. The problem is as you said, most ones are based on ‘how closely are you following the process’, instead of telling ‘what value have you delivered’.

So far the only two I’ve got are 1. measure speed of delivery – how quickly you release 2. Number of bugs coming from the field. Both are easier said than done, but are the only two which can truly measure success

Comment on My key learnings in 2019 by Bernard Londeix

Bernard Londeix — Wed, 01 Apr 2020 11:02:38 +0000

Yes, I am in line with what you said. But also DevOps proposes a Development Life Cycle that include an interest for software metrics. The only hic-up in this metrics is that the Agile derived metrics is a metrics of the Process. I would prefer it to be a metrics of the ‘value’ provided.
I trust that any Quality interested person would be happy to seek a resulting output be conform to the expectation.
Best regards, Bernard

Comment on Develop your API Contracts by Ali Khalid

Ali Khalid — Sun, 26 Jan 2020 16:25:05 +0000

In reply to Maria.

For API’s the service provider should write a ‘contract’ (behavior) of the format of requests to send to the API, and what will be sent back in response. Essentially requirements of how the API will behave. These are called contracts, because it’s an agreement between the service provider and user of how the API will behave.

Documenting the ‘contract’ can be done through a wiki / confluence page, but best practice dictates to use API documentation tools like swagger, this was the contract is documented from the actual code, not a static document which have to keep up to date all the time.

Comment on Develop your API Contracts by Maria

Maria — Thu, 23 Jan 2020 11:16:05 +0000

What do you mean by conttact written up? Can you give an example, please?

Comment on Don’t start with learning Selenium by Ali Khalid

Ali Khalid — Thu, 16 Jan 2020 16:06:53 +0000

In reply to Jason Yang. Thank you for adding Jason. Automation is means to an end, to facilitate testers to highlight risks as early as possible. Where applications are not built with REST APIs, we can still have API tests. IMHO UI tests need to happen, but just to test the code running on the UI, not the whole business logic piece.

Comment on Don’t start with learning Selenium by Jason Yang

Jason Yang — Thu, 16 Jan 2020 06:55:23 +0000

I seem to have different feelings about Selenium. I think it is a great platform to teach QE how to start thinking like a developer with the design and function of an automation framework and what that framework targets. Sure API is important, but not all web applications, especially ones from the late 90s and early 2000s have a fully functional REST API for people to work with. You talk about a means to an end, but what end are you implying? Good quality? Ensuring quality, I feel, is an exercise but one that must be practiced constantly without end. We don’t stop testing just because we are between releases, and we shouldn’t stop testing just because we stop supporting software. This is why we have CI/CD. Automation is a tool for continuous QA, not a “means to an end”. On your third point, yes if you have a bad foundation, then everything else is bound to crumble. But being afraid to build that foundation on something that has been proven and has patterns and software models already designed and mathematically proven for it only prevents you from making progress. And yes without knowing how product architecture is setup, we cannot test to the best of our abilities. Have you heard of black-box testing? Have you ever reverse-engineered something from a set of test-cases derived from a systems manual and test exploration sessions? Yes UI testing can be unreliable and cumbersome, but the UI is where your clients and customers are going to see the defects you missed first. The UI is how your clients and customers will deal with those bugs, and whether or not they continue to use your product. I strongly believe that it is the UI that is a better introduction for SDETS to understand the problems and frustrations that they are trying to solve, and moving into unit tesitng and API testing only strengthens their toolkit and helps them build better automation frameworks. Without seeing the application of the APIs, students are more likely to get bored with API testing.

Comment on Building Psychological Safety by Ali Khalid

Ali Khalid — Mon, 13 Jan 2020 14:49:20 +0000

In reply to Robert Day. Very true Robert, and I guess we've all seen this where management is just giving lip service, this exercise then just becomes a change of guards, thats it.