alikhalid

“Within 6 months we’ll automate the testing”..

A goal one of the prospective client’s had for me, you can guess what happened next..

I understand that was a way to sell automation to management for budget approval, but was a horribly wrong statement

I’m glad to announce I never agreed to the crazy plan

The root of all this, IMHO, lies in misunderstanding what testing is

The idea of ‘testing’ being automated is impossible, unless we can create ‘Autobots’ or ‘Desepticons’!

‘Testing’ is a process of thinking, communicating with people, strategizing and continually adapting

We don’t have sophisticated enough systems to do that right now, and not sure when we will reach there if ever

But then how do you convince management that automation benefits everyone?

Here are my thoughts on calculating automation ROI:

#QsDaily #TestAutomation #AutomationRoi #Testing

Deciding what to automate?

Let’s decide what to ‘TEST’ first..

This is a follow up post from earlier where I mentioned METS

The idea of METS is to have a concise look of the important features quickly

And this is not needed for planning testing only , rather far more important for automation

Unless we are automating “what’s important”, we’ll get nowhere..

So first decide what to test, then talk what to automate

In this video I discuss the importance of deciding what to test first:

#QsDaily #testautomation #testing

Automation ‘Wisdom’ reinvented

I’m guilty too, thinking I was the first to discover some automation wisdom

The reality is, thorughout the decades of evolution in automation and automation tools, there have been common misconceptions ‘discovered’ again and again

And probably a lot of folks starting new in that wave of evolution were not aware about these problems seen in the past

In a talk with @Jim Hazen, we touch base on the same topic and Jim shares his experiences around it:

#QsDaily #TestAutomation #AutomationEvolution #TechnologicalExcellence

To write ‘traditional’ test cases or not

Whichever camp you are in, we all agree they are time consuming

There are many methods suggested in the community to document scenarios rather than all the ‘mundane’ steps

It becomes easy to refer and update, and takes less time to write

One such method was presented by @Greg Pascal at the #TestingGuild hosted by @Joe , which I loved instantly

It’s a one liner summary of test scenarios for one module with rows listing feature names and 4 columns signifying the scenario’s importance from critical to low

Sample sheet:
https://goo.gl/AggDE6

I like the concept because it’s simple and easy to
update

With ‘agile’ kicked in, it’s been a big excuse to NOT document ANYTHING, which has made domain knowledge a problem

IMHO, testing strategies like METS could be of great help in such cases

For more on that, here’s Greg’s website on the subject:

#TestCases #Testing

When I started learning #docker it was a bit confusing

To ease the learning curve, here’s how I explain docker to testers:

(simplifying things A LOT to make it easy to understand here)

1. Imagine a windows environment ‘X’ running on a desktop machine
2. Now create an image of that environment ‘Y’
3. Run that image (Y) on top of your desktop environment (X)
4. Any app running on Y would not affect X right? So that’s the first thing to appreciate.

5. Now whats common between X and Y? The OS, windows in this case.
6. So let’s take out what’s common, the OS. Remove the duplicate one from Y

And that’s what Docker does, it removes the duplicate OS and related resources, and uses the OS from X for running stuff on Y as well

All this while maintaining the isolation of both environments..

Along with a bunch of other benefits that come with this..

To read on the evolution towards docker and a brief intro on how it works:

As tester’s our job is to identify risks in the AUT,

Come hell or high water we have to get the job done

Wrote an article for #StickyMinds on the subject.If a feature is impossible to test from the outside, it surely can be done through fault injection

All you need is determination to get the job done.

https://lnkd.in/fKAjnsc

A message from Bill Gates for folks from all walks of life

Then why do testers working in tech shy away?

Coding is like learning any other skill

You don’t have to be extraordinarily intelligent or gifted

Half of coding is about understanding a problem and thinking of a how to solve it

More here:

#QsDaily #TestersGoingTechnical #TestAutomation #Testing

– Always prioritize people over process. People are far more valuable than any process implementation. Don’t loose them.

– Management always wants to make decisions based on numbers, learn to give estimates.

– Don’t stop learning, try new stuff all the time. Also every problem you face is not unique. There are surely other people out there who have solved this before.

More to come in future posts.

http://testingguild.com/ and thank you Joe Colantonio for hosting this.

#testing #testmanagement

The #TestingGuild2018 conference just kicked off – 100% online filled with testing Awesomeness organized by Joe Colantonio.

Tomorrow at the conference I’ll be sharing a story illustrating the importance for testers to be technical.

In the #TestingGuild2018  conference I’ll be talking about how beneficial it can be to test your product across the complete technology stack.

Teaser of the presentation: