test automation (77)

Form filling using tables (Cucumber/AngularJS/Chai/Protractor)

Rather than pollute your Gherkin with “I fill in …” lines, you can create your own Gherkin and code, using table format. Many make mistaken assumption that Gherkin is somehow fixed format. Yes, the Regex trigger is the “Given”, “When”, “Then”, “And”. But Gherkin is supposed to be based on natural language, so as long as you observe some programming principles to creating new Gherkin, create your own. It’s encouraged as there is no way the out-of-the-box Gherkin provided by BDD products will completely accommodate your project requirements.

How I stopped hating QA

  • September 25, 2015
  • Agile, BDD, ...

Guerilla test management – it became my accidental niche area.  From 2000-2011, I was working in primarily creative, publishing, mobile and media companies in QA/Test Management capacity – usually hands-on (asides pure strategy/management based contracts).  Either welcome or not, I was hired for my pragmatism and multi-disciplined QA skills.  I have built test environments on the sly (not kidding), experienced sabotage, back-stabbing, blame-game defences.  I have managed distributed teams, and have been a lone QA  on multiple projects.  I often had to learn new things, at speed.  What never changes (rarely) is my good-natured optimism, and refusal to allow others negativity to affect me.  But, a few years ago, I had grown tired of my management direction and tired of unhealthy chaotic projects I was hired to improve QA within.  On a personal level, the work felt vague with no focus, and increasing dissatisfaction.

BDD debugger

So what are we really building when we develop in test on a BDD project? A test framework, a test application? Well, both of these, but most importantly it is a debugging application, ideally integrated into CI and/or whatever the code build/deploy process the code goes through. Sometimes the debugging application is part of the application under test, and all for the better.

UI test: the last resort

You can make your life hard doing all test automation using UI tests, or play it smarter, using API services, when the focus of testing is not concerned with actual UI. UI checks are of course always a test requirement, but that does not mean all tests need to be UI, or even the largest percentage. One of strengths of BDD approach to test automation, is in it’s use of a natural specification language (Domain Specifc Language) used to define the test scenarios. These mask underlying test code that can be executed at UI, API or Unit level (or combinations within a test script/scenario).

Utilising API services is useful for background data creation (though also possible to do database unit-level coding to achieve same results). It can also be used when you want to bundle functional steps into one. For example, instead of following verbose Gherkin lines when filling a form, it could be a simpler one liner:

Given I create new valid registered user

Selenium: The doom merchant favourite

Selenium – a firm favourite amongst the doom merchants. You know the suspects – the one who delight in announcing the death of “old thing” to promote “new thing”.  Lazy young bucks, trying to get a ride off slating what came before, with no analysis or reason.  Selenium has stood the test of time, and STILL people misunderstand what it actually is. Strictly speaking, it is a testing framework, which we can “talk” to Selenium (i.e. write test scripts) in many languages (originally just javascript).  It’s strength lies in it’s extensibility, plugging in to all the major browsing clients, including newer javascript-focused headless browser clients such as Phantomjs and Protractor.   Of course here, I am referring to Selenium WebDriver, which is the most used of the Selenium suite of products.