Daily Posts

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:

15+ years of coding experience, two dozen testing tools?

While there are a lot of opinions on the subject, I try to go for the essentials

1. Algorithm design aptitude. If our framework is in Java, I’m not focusing on Java developers only. If the candidate can demonstrate reasonable algorithm designing skills, that’s enough for me.

2. Testing Acumen. Not just fundamentals of software testing memorized word for word, rather have the technical depth on various topics around software testing and depth on the topic.

3. And the most important piece, the right attitude. The skills mentioned above can be acquired, but without the right attitude, it’s just impossible. Down the road you’ll have to let go of that person, period.

#QsDaily

The Journey of a technical tester

Story of a hypothetical tester learning over his career to become more tech savvy and improving his craft

The first “story-presentation” I did for a conference, #PSQC2018

The presentation illustrates some fundamentals testers can learn over the years and the reasons why it’s important to learn these lessons

With a touch of humor, few core concepts related to the technology stack are explained as well.

The complete presentation can be seen here:

While testing in any shape or form is certainly adding value, but getting the most out of it is something entirely different

More than often I’ve seen teams having no idea where to focus testing on

In the #TestingGuild2018 conference I’ll be presenting a story talking about this subject

How to figure out what’s most important for the product and focus there first

Why we need to prioritize?

One answer would be: 80/20 rule..

(in our context) 80% results come from 20% effort, find that 20%

Teaser of the presentation here:

“Just because something works, doesn’t mean it can’t be improved”

And improve we must

Automation frameworks in an extremely volatile environment

Unless you keep up with the change, big problems are in store

#QsDaily #AutomationFrameworkDesign

Teaser of a presentation prepared for the #TestingGuild2018

The second in my series of story-telling presentations at conferences.

For registering:
TestingGuild.com

And if someone knows how to code, it does not mean they know designing algorithms

At the core of programming is thinking, thinking of the best way how a machine can do a task

Often you would come across folks who can write some code, but cannot think of a process themselves

And try jamming in pieces of code from different places instead

Taking a solution from how we’d do it in our head to getting it right in the code is sometimes easier said than done

To learn this skill, it’s best to follow some basic steps until this becomes second nature, in short which are:

– Solve problem on paper
– Write solution steps in detail
– Write pseudo code
– Script in desired language

More on that in a separate article.

#QsDaily

I call it debugging the Sherlock style

Once something unexpected has happened, evaluating the evidence to find the actual story

This is particularly true for long automation batch runs where a script passes in a single run, but consistently failing in the batch

I’ve observed people mostly just hope running the script again and again will reveal the problem itself

Taking a moment to understand what might have gone wrong, and doing some targeted debugging can save a lot of time

My thoughts on why to analyze and how to do it:

#QsDaily

Teaching devs testing or testers learning programming?

And if you feel there is no need for testers to be technical, that’s another discussion entirely

I feel teaching devs testing is more of an attitude training

That’s the difference between testers and developers, how they approach the problem and the end goal

Naturally there’s a lot of fundamentals, techniques and concepts but what’s more difficult is the attitude

For testers learning programming, mostly its acquiring another skill, rather revisiting a skill they tried to learn before

For some it’s easier said than done, but in the end it is a skill like any other

And in case programming is frightening for you, that’s another discussion too.

Personally I’ve always felt changing an attitude is much harder than acquiring a skill, probably this would depend on a lot of other things as well

#TestersBecomingTechnical #RedefiningSoftwareQuality

After the #AutomationGuild2018 (expert round table) and #PSQC2018 (Asim’s journey to becoming a technical tester”)..

Listen to the next exciting story of Billy at #TetingGuild2018 https://testingguild.com/

A story of when a testing team took responsibility instead of hiding behind excuses and the results it had for the product

Some very important lessons learned which have been a driving force for me since then

If you want to work on #RedefiningSoftwareQuality and are passionate about evolving testing, this is THE presentation for you

P.S.
Will be sharing a teaser (hopefully) in a few days.

(Asim’s) Journey of becoming a technical tester:
https://lnkd.in/fJaiaXb

Other community engagements:
https://lnkd.in/ffFWrcs

And it’s implications for automation learners

It goes like this, place a marshmallow on the table, tell the child if they don’t eat this marshmallow for another x minutes, they’ll get a second one, then leave the room.

The jist of it is, kids who can delay gratification will probably be more successful.

And I feel this holds very true for automation learners.

Starting and staying with very basic automation concepts and trying to squeeze every opportunity sitting at that level is not helpful.

Learn to do the grind today and wait for the rewards later on.

Invest in learning how to do automation well instead of doing just the bare minimum and hoping to succeed.

Yes the industry does need automation engineers, but far greater is the need for excellent ones!

#QsDaily #LearningAutomation

Here are the few places I’ve used it in:

Create isolated AUT instances
– We have separate DBs for different AUT versions
– Using docker can instantly create multiple AUT instances
– Different approaches to do it, one can be to just hook up multiple DB versions to the same app server

Multiple execution environments

– Selenium grid(s)?
– If your automation tool allows, can create multiple execution environments
– Can hook them up with Jenkins and everything will be done on the fly

I’m sure there are other uses where the AUT is NOT containerized and we can still leverage docker.

Have you tried something different? would love to hear..

Deciding what to Automate?

First let’s talk about what to test

Often when teams talk about what to automate they jump straight to regression tests

I like to start with ‘Do we have a good set of scenarios to test’ to choose from?

What to test would depend on changes, features inmportant for product positioning, most sought out features by clients, features with most bugs from the field and so on..

Once we have that list, we can talk about what to automate.

Here’s the discussion on the subject:

#QsDaily #QsEpisodes

Does verifying ethical boundaries of a product come under testing, E.g. Data privacy?

If it’s expected by management then off course, if not then?

In this age I feel we’ll have to face more ethical problems than ever before

As technology’s reach increases, more possibilities open, creating more social challenges as a by-product

As a tester, Identifying and factoring end user’s needs and wants is paramount

Keeping a moral high ground has always been tough

The decision would boil down to every person’s core values I guess

Felt this is a question many of us might face in the coming years (if not already)

Thoughts?

#QsDaily

We all learn in different ways, lessons that stick usually have more effort and emotion involved

This is one such story of debugging an automation framework problem

There were quite a few lessons we learned and have been vital in our success

If I’d have to mention just one, “Whatever can go wrong, will go wrong” (Murhpy has a lot to answer for..)

So try to figure out what can go wrong and prepare for it

For a brief summary of the story:
https://pos.li/29s544

The complete TechBeacon article here:
https://pos.li/29s545

Perhaps one of the most common and used among the Java community

For automation engineers, specially working with object oriented languages like Java and Python this is important

These will create clearner, less complex and reduced coupling in you framework

The principles might be a bit complex to understand at first,

But are very useful and worth the time spent

#QsDaily #TestersGoingTechnical

Many time it’s just inadequate planning

Sometime the change is misunderstood

Assumed as a small / localized / easy fix

One thing leads to another and we’ve opened the pandora’s box

I’ve always felt the first mistake of misjudging the change is the main culprit

BTW, this goes for automation framework changes as well

The rule of thumb I use: “If any other module of even class can get affected by the change, don’t do it at the end”

A few more tips in this article

#QsDaily #QsArticles #NotSoSmallChanges

Jim Hazen and I talk about how we keep repeating the same mistakes..

Some sample cases would be:

– Record and playback
– Automation would render testing team’s unecessary
– Treating automation as a part time activity
– Having the wrong goals to measure automation
….

To be honest, this can be a very long list, but you get the point

Here’s the discussion about why we probably keep running into the same trap every time a next wave of evolution in automation comes around

#QsEpisodes #AutomationMistakes #HistoryOfAutomation #LearningFromMistakes

Unfortunately, mostly are love and hate relations, especially between Superiors and Juniors

And here’s what I’ve experienced over the years:

– Every Superior has resentment to every team member, it might seldom and negligible, might be frequently and severe

– Similarly, every team member has resentment towards every superior, it might be seldom and negligible, or frequent and severe

Striking a balance between the love and hate is extremely hard, and equally important

The question is, how to deal with it

Well, everyone has their own way, I try to spread goodness and have no ill-will

It’s tough, seems impractical sometimes,

But my faith dictates, in the end those who spread goodness are the ones with the greatest impact and success

#QsDaily

Well, it does and does not.. Let me explain

By testing ‘just’ the API, yes some checks programmed for the client side will get skipped

However, API automation is not to ‘replcae’ UI automation

It is supposed to work in ‘conjuction’ with UI automation

And not only UI, but in coordination with unit tests as well

Therefore, if we look at just API / service layer tests only, then we do loose areas to test

But when working in conjunction with UI and Unit tests, (the way it should), then we don’t forego any code from being tested

#QsDaily #UiAutomation #ApiAutomation

References:

https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid

There are some ‘dumb’ routine tasks we have to do as a tester

Not all of them require a signifanct amount of intelligence and can be done automatically

And I’m not talking about checking as in testing something, rather activities other than actual testing

Some AUT upkeep tasks like configuration updates, checking installations, maintaining environments, compying stuff from one place to another

Having a single tool to do all of these things might be an overkill in the start

But certainly can prepare a bunch of smaller programs for routine tasks and controlled from one place (Jenkins..?)

Call it a stripped down dumb version of Jarvis if you will..

I know @Alan Richardson has talked about something similar

Care to share something you are using along those lines?

#QsDaily #Jarvis