Error message

  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2040 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2050 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2040 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2050 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2040 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2050 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2040 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2050 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2040 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2050 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2040 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2050 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 2040 of /home/www-data/ukalf/wwwroot/includes/common.inc).
  • Warning: date_format() expects parameter 1 to be DateTimeInterface, boolean given in format_date() (line 2050 of /home/www-data/ukalf/wwwroot/includes/common.inc).

Agile

How to install Bonobo Git Server On Windows

Alan Richardson's Blog - Wed, 16/01/2019 - 17:00

TLDR; Bonobo is a free and simple to install Git Server for windows.

The Bonobo git server install page instructions don’t fully match the process I had to use to install, so I’ve documented the process here.

I will show you the steps to install a local Git server on Windows 10.

Install Steps for Git Server

The Git Server used is Bonobo Git Server, this runs on IIS on Windows.

https://bonobogitserver.com/

Pre-requisite:

  1. use Turn Windows Features On and Off to install
  2. Internet Information Services > Web Management Tools > IIS Management Console
  3. Internet Information Services > World Wide Web Services > Application Development Features > ASP .Net 4.7
  4. Internet Information Services > World Wide Web Services > Common HTTP Features > Static Content

Install:

  1. download the zip file
  2. unarchive the zip file
  3. copy the contents of the zip file folder to “C:\inetpub\wwwroot”
  4. change the security properties of the App_Data folder to allow modify access to the IIS user
  5. check Anonymous Authentication is enabled
  6. visit http://localhost/Bonobo.Git.Server
  7. create a user
  8. amend settings to “allow user repository creation” and “allow push to create repositories”
  9. create a repo
  10. push repo to your server
useful git and shell commands used
git status
vi readme.md
git init
git status
git add -A
git commit -m "my first commit"
git status
git remote add origin http://servernameorip/Bonobo.Git.Server/test.git
git push -u origin master
Step By Step Video Showing Install of Bonobo Git Server

Watch on YouTube

Categories: Agile, Software Testing

A Tactical Automation Case Study - Java, JavaScript, API and Dev Tools

Alan Richardson's Blog - Mon, 14/01/2019 - 07:00

TLDR; Automating is not limited to “Test Automation”. With the ability to code, we gain the flexibility to approach problems in multiple ways. We can refactor tactical code to become strategic code.

I needed to migrate some data from one system to another. To do it manually would have taken me about 1.5 to 2 days. I automated tactically and was done in 2 hours.

I have a full video report of this work on Patreon

I needed to automate migration of URLs from one system to another.

Since I was only ever going to do this once, I consider this tactical automating.

Getting Data Into A System

The System I needed to move data to did not have:

  • a bulk import function
  • a formal API

But, it is a web application, and it has a GUI.

This means that if I can model what the GUI does then I might be able to automate it. And I don’t mean automate the GUI, I mean automate the messages that the GUI sends.

In Automating And Testing a REST API I referred to this as “App As API” and the book contains a longer write up of this approach.

Basically:

  • I use the GUI
  • I have all web traffic going through an HTTP Proxy (I used BurpSuite)
  • I determine what are the minimum necessary HTTP messages to replicate
  • I copy and paste those messages into an IDE
  • I automate those messages directly
  • I refactor them to have the paramaterised data that I want to upload
  • I create the data in an Array
  • I loop over the array and send the messages
  • I send all messages through a proxy so I can see the outcome and the content
  • Initially I run everything in debug mode so that I can check if it is working and review the outcome in the System GUI.

Note:

  • The App doesn’t have an API, I sent through the HTTP messages that the GUI sends
  • I don’t attempt to replicate all the messages, just the ones that make a functional difference
    • with many apps you’ll find logging calls, diagnostic calls, health check calls, etc.
    • I just used the ones that trigger functionality

The code is simple:

  • I have hardcoded strings
  • I refactor those into parameterised Strings that use a String.format
  • I did not create any payload objects because I’m working tactically rather than strategically
    • If I was automating something complicated then I might use payload objects, but I didn’t need to.
  • I needed an object to represent migrated data
    • I used a private inner Class
    • I often do this for initial work, then refactor to a public Class when other test classes need to use it
  • I created a data class, a POJO with a constructor, where all the fields are public final and set by the constructor
    • because I didn’t need the overhead or protection of methods for the fields
    • I only needed a single constructor
    • e.g.
    class ShortUrl{
        public final String path;
        public final String url;
        public ShortUrl(String path, String url){
            this.path = path;
            this.url = url;
        }
    }
  • I sometimes start my strategic automated code with inner classes and then refactor to public classes, and refactor the public fields to private fields with public accessor and setter methods.
Getting Data Out of a System

I tried to use the “csv export” from the System, but it didn’t have all the fields I needed.

I raised this with the vendor, and they confirmed it was a bug that they will fix, but I’ve already worked around the issue. Tactical automating is often used to workaround bugs and issues.

This is a JavaScript heavy GUI, so I can’t use an HTTP request to parse the data from the HTML.

In these circumstances I automate in the Dev Tools Console.

Useful JavaScript constructs to learn:

Also a grasp of CSS Selectors can help.

For Parsing data I do like Regex:

let regexp = /.*\/(.*)\/(.*)/ig;    
let matchOne = regexp.exec(notes);
var project = matchOne[1];

Very often when I’m working with JavaScript from the console I end up building a string as I loop over lots of data:

var reportLine = '"'+url+'" => "'+shortUrl.trim()+'",';
console.log(reportLine);
output = output + reportLine +"\n";

I often console.log it so I can see it for debugging, but by building a string output it is easy to output it to the console and then copy and paste into another System. If I console.log every line then copy and pasting the output is a pain.

Working tactically means:

  • I write code that works
  • it may not do everything at once, so I have to change variables, tweak conditions etc. when I want to run against different data sets
  • I will probably run it multiple times
  • it is supporting what I am doing rather than trying to automate a workflow reliably from start to finish
More Regex

I also used Regex find and replace in Visual Studio Code. This is becoming my favourite Markdown and text editor.

I find this useful as a tactical way to convert code from one language to another

find: (.*)=> (.*), replace: new ShortUrl($1,$2),

The above allowed me to convert a PHP Array to a Java Array of objects.

Mix of Skills

To automate like this I have to use:

  • Technical Web and HTTP skills and tools that I have built up from testing
  • Java and Libraries that I use for automating strategically
  • JavaScript which I frequently use for in browser automating and adhoc GUI querying and manipulation

All of the code was tactical.

  • I haven’t saved it
  • It wasn’t intended to be maintained
  • I refactored it only as far as I needed to make my work easier
  • It wasn’t intended to run reliably, sometimes I have no synchronisation and execute it in debug mode to have synchronisation points
  • It has minimal error handling and checking, it relies on me spotting problems to stop execution

Tactical is often a first step to creating strategic automated execution, and with more refactoring I could have created a long term strategic automated migration. But I didn’t need to.

No doubt some of the code snippets I’ve included here seem like ‘bad practices’. And they might be if this was strategic.

If you want to see this in action then I have a video in Patreon, but hopefully there is enough here to encourage you to learn some of the tactics and approaches that I used for tactical automating.

Categories: Agile, Software Testing

Pro Con Critical Evaluation - but What If?

Alan Richardson's Blog - Wed, 09/01/2019 - 07:00

TLDR; Any time you see a list of pros and cons on the internet and ‘believe’ the pro or con, ask yourself “But What if…?”

I see a lot of pro and con posts and questions on the internet. They lack the context behind the pro and con identification, so I find it hard to use them directly.

P.A.C.E.S Pro and Con Evaluation System Promo

Pro/Con Articles are easy to write and plentiful

Pro/Con articles are plentiful. And some companies make a business out of selling you reports filled with pros and cons or approaches and tools to help you identify the ‘best’ one, without undue effort on your part.

pros:

  • you might see some benefits that you didn’t know about
  • you might be more interested in a tool/approach/technique that you had ignored

cons

The pros and cons tend to be based on unstated assumption about the environment that may not apply to you.

The pros and cons are based on someone else’s experience, and potentially an environment.

  • You might not have that experience.
  • You might not work in that environment.

As such they might be misleading.

Question: do you read them with this critical view in mind?

An Exercise I Conducted - What are the pros and cons of Test Automation?

As an exercise, I executed a web search for “pros and cons of test automation” and evaluated the results. I’m not mentioning which search engine I used and which sites I paraphrased the pro and con below from.

Pro: Test Automation is useful for repetitive tasks that are boring or are susceptible to human error

Great.

But…

Assuming What?

If I ask myself what are the assumptions?

  • Assumption: repetitive tasks are boring
  • Assumption: repetitive tasks are susceptible to human error

And then challenge the assumptions.

But What If?

But what if it wasn’t boring?

  • Perhaps you should make the task non-boring first before leaping to automating?
  • what makes the task boring?
  • Are you repeating the task with exactly the same data? Perhaps you should vary the data?
  • What is the output of the task: data or information? Does it always show the same result? or do you have to work to interpret the output?
  • Do you care about the output? If not, perhaps you should stop?
  • Does it always provide the same output? e.g. if it is a ‘test’, has it ever failed? Perhaps the risk it is testing for now has a very low likelihood?

But what if it wasn’t susceptible to human error?

  • Does that mean automation isn’t useful?
  • How will automation make it less suitable to human error, won’t that make things harder to automate?

But what makes it susceptible to human error?

  • Perhaps you should make it not susceptible to human error and identify what makes it error prone.
  • Perhaps you could automate some of the task, rather than all of the task? e.g. data setup.
  • Is it the task that is error prone, or is it the variation in the task that exposes an error in the system, that when it is automated and executed consistently the error goes away?
    • e.g. people type at different speeds, when a slow typist uses this, the system times out, this makes it susceptible to human error. Automating it removes the human error and hides the fact that the system is unusable to slow typists.
    • perhaps the system needs a fix?
  • Perhaps you should train your staff to avoid errors?
  • Perhaps the system is hard to use?
  • Perhaps you need to rotate staff to different teams so that things are not ‘boring’ but are ‘new’?

There are environmental nuances that the pro does not elaborate on. If you experience the symptoms that are part of those nuances, perhaps you should fix the cause.

And I could go on:

  • identify ‘but what if?’ scenarios that invalidate, challenge or questions, the pro or con
  • find more pros and cons

But I won’t because then this will be too long and then this would become a post about “Pros and Cons of Test Automation” and I intended to explore the “Pros and Cons of Pros and Cons”.

I think it is a useful exercise.

Pro-blogging tip. Pick a 'pro' or 'con' from any list and discuss it in more detail in an article. --> Critical Evaluation of Pros/Cons lists

Points I want to draw out:

  • their environment likely differs from yours, but their pros and cons may not help you identify the differences
  • you might not have the skills, approach, environment to make their ‘pros’ work
  • you might be able to find a better solution than theirs that better matches your environment
  • treat any list of pros and cons as ‘possibilites’ rather than ‘absolutes’
  • ask questions of the person creating the pros and cons to see if the underlying environment matches yours

Exercise: perform a google search for “pros and cons of test automation” and evaluate the content of the results.

Or choose your own search term. I don’t mind. I’ve done the exercise.

Does it need to be “But.. What if?”

I don’t just have to ask “But… what if?”.

That would be overly perscriptive and doesn’t take into account the actual wording or context of the pros and cons.

The point is to challenge them.

e.g.

  • When would this pro/con be valid/invalid?
  • What needs to be true for this to be valid/invalid?
  • What assumptions are encoded here?
  • Is there an agenda behind these pros and cons?
  • Am I seeing a description of the only experience this person has?
    • i.e. are they recommending a tool because it is the tool they use?
  • Did they actually try other tools and approaches?
  • Did they have the skills and experience to make those other tools/approaches work?
  • etc.
PACES - Pro And Con Evaluation System

I might summarise this as:

  • identify assumptions
  • identify bias
  • challenge the assumptions
  • challenge the statements made

I might refer to this as “Pro And Con Evaluation System” i.e. PACES.

But I won’t. And neither should you.

Or should you? Challenge that assumption.

Categories: Agile, Software Testing

Patreon for Software Testing and Development

Alan Richardson's Blog - Sun, 06/01/2019 - 08:00

TLDR; I create a lot of exclusive content at Patreon.com/eviltester have you had a look at it?

I’ve been doing a lot of writing recently - but mainly on Patreon. I’ve started writing (as much as possible) daily logs covering, testing my work, tools, development, books, etc. And a lot of it is exclusive to Patreon.

You can find my Patreon at Patreon.com/EvilTester. The main information tier is $5 a month and as long as you are a Patreon you have access to all the content on Patreon.

I don’t like to release ‘daily’ and super frequently on a blog like this, but Patreon feels like the perfect place to do that.

I enjoy seeing updates from people I support on Patreon and I took the idea, of building Patreon into my normal working day as much as possible, from the artist Graeme Neil Reid. Graeme posts updates of his work in progress and general stuff.

In the last months my logs have covered:

  • SASS, SCSS and CSS, and refactoring web sites
  • Reframing Software Testing and models of testing
  • Boundary analysis
  • Dev Tool Features
  • Observation, Biases and Team Building
  • Books on Compilers and Computer Science
  • Prepping for conferences and practicing talks
  • Importance of Cache in testing and security testing
  • Risk analysis during defect fixing
  • Exercises on observation using Magic videos
  • and so much more…

I’ve created almost an exclusive daily logs every day since October 2018, and intend to keep creating daily as much as I possibly can. The written posts were getting to be pretty long posts so I also started creating video posts with a written summary.

Some of the Patreon posts will eventually spill out into videos and blog posts e.g. a recent YouTube video spun out of one of the logs, and once I’ve got my head around some of the foundational testing thinking in more detail I’ll probably blog or create videos about that.

I find creating daily on Patreon useful because it helps me explore what I’ve learned and helps push me to learn in a purposeful fashion. It also forces me to ‘teach’ quickly, after I’ve done something. I also feel I can be even more ‘me’ on Patreon.

I’m also creating micro courses - and there are two very complete courses on JavaScript console testing, and Test Ability Audit. I’m working on a course on Blogging/presenting and the blogging part is pretty much complete and I’m working on the conference part at the moment. I’m also building up material for exploratory testing.

Patreon supporters also get ad free access to my YouTube videos and practice or unedited versions of my conference talks.

If this looks like it might be useful then you can see why I’m doing it on Eviltester.com/page/patreon.

Or go straight to Patreon.com/EvilTester where you can sign up and get immediate access to all the content for only $5 a month or ‘bits’ of the content for only $1 a month. And I have released some of the content for free so even just browsing the list of posts should add some value.

And its cool to join for a while, consume the content, drop out, then come back later. You have complete freedom for when, and how long, you subscribe for.

Sign up to Patreon at Patreon.com/EvilTester

Categories: Agile, Software Testing