daily post

Or just a general I’ll do task A, and be open to anything that comes your way to do also?

We have a lot of distractions around us (more than we should have)

And the human mind can truly focus only on one thing at a time

That’s when the 2x – 10x effects come in – through focus (also known as ‘deep thinking’)

With a to the minute plan, at least for work hours, you would react all day to external events

Which would have diminishing returns and you wouldn’t accomplish as much as you could have

Track your day and be very particular about where you spend your time

After all, time is the most valuable asset we all have!

And are the terms framework, library, tools and dependencies interchangeable?

You might say they are not, but I’ve often seen these terms used for the same things

I’m not trying to distinguish between them all, but framework has a much larger meaning than the rest

Therefore any one library, tool or dependency cannot be a framework

Dot Net is a framework, no one would call JavaScript a framework?

Then why do we call automation libraries like RestAssured, JUnit etc. a framework?

More here

One way is to write (BDD) feature files for the story

User stories are an improved form of the traditional ‘FRS / SRS’

And sometimes the ambiguity we saw with traditional requirements can be felt in stories as well

Feature files explaining how the implementation should work is a great way of clarifying

It makes the ‘subjective’ nature of the story to a more ‘absolute’ expected behavior

And you can link your gherkin files to your user story

More on that here

If the purpose of end to end is testing different layers of the technology stack, this certainly does not do the job

UI automation does check the logic and data back to DB and return till the UI

But testing at the UI has a limited scope compared to service or DB level

If you do have UI automation checks, assuming your testing actually testing the complete technology stack is not accurate

Some scenarios are going through, but you might be, missing out on a lot

Therefore, having tests on layers should really be considered ‘end to end’ – complete stack testing

#RedefiningSoftwareQuality

I’ve seen different people having different interpretations of the term

Most common and (correct) IMHO is testing along the stack

A test which covers functionality of the UI, service, business layer and the DB

Hence end to end – from UI to DB

The other meaning taken is testing a use case from start till the end

The ‘ends’ meaning start and end of one complete user flow

This meaning is seldom used, I think is not the correct term and should be described as use case or something to that affect.

#RedefiningSoftwareQuality

Agile is not a direct pre-req to CI, although they both work towards the same goal

Agile is a development process encouraging to develop, ship and iterate quickly

Continuous Integration facilitates shipping quickly

By using tools to move a software update from development to deployment

So yes, you can achieve CI without strictly following agile

But some form of agile practices might be essential

CI would not be effective with a waterfall resembling process

More here:
https://lnkd.in/fYvwAiF

Today’s research concluded there is no ‘simple’ way

We as automation engineers can understand the necessity of clearing cache

However, turns out this is now a standard development practice to handle revisioning of your client side scripts / files

In which case you don;t need to clear cache to see the latest changes

In the abnormal case where it is not done by your AUT,

The only way I found was running ‘incognito’ mode.

The closest solution was Chrome’s ‘command line switches’, but there is none for clearing cache or running in ‘disable cache mode’

To do that (disable cache in regular mode) from the UI for testing:

https://lnkd.in/fnfAnuA

If someone knows a way to do this through scripting (JavaScript, cmd whatever), let me know (for chrome)

Might not be strictly any one, but my vote is for soft science

IMHO: Testing is about validating an ‘imagination’

An imagination of a feature, which a bunch of people from different backgrounds decided on

And mostly not everyone was imagining the same thing to begin with

And sometimes most stake holders are not on the same page till the very end either

So, it’s more about managing ‘perceptions’ of what the feature should do

And therefore, more of a social science than a hard / pure science

#RedefiningSoftwareQuality

Creating: recording and deleting data..

Either you create data on the fly, or have it in the system before hand (like seed data)

Recording meaning forms to write test data in, DB, excel / csv, other file formats, within the tool and my favorite: JSON

Deleting: once the test is executed delete all data not needed anymore aka clean up script

And my favorite data management style: Restore the DB. Have a baseline with all the seed data, restore that before execution. Before executing next time restore again..

From an article I wrote for TEST Magazine (Sept 2017 issue):
https://goo.gl/TFtSqE

What goes in the user story and the feature file?

Feature file: behavior of the feature described in ‘simple language’ (called gherkin)

This is what I use to help distinguish:

User stories define the ‘what’ of the feature to implement

And the feature file explains ‘how’ the implementation will behave

Both have thier own place and importance, therefore should not be tried to combine into one another

Plus I feel this is where BDD has the greatest value, elaborating the user story in terms of the precise desired behavior of the implementation and used across the team

More here:
https://lnkd.in/fRrAM7Z