text: On November 13th and 14th, the Nymi team was onsite at the Biomanufacturing World Summit in San Diego. Similar to the show we attended in Berlin (see that post here), this latest show was a mixture of keynote speaker sessions and having one-on-one conversations with thought leaders in pharmaceutical manufacturing. This format meant that we were able to both demonstrate the Nymi solution, but also gain insight as to where the industry is heading, and what it will take to get there.
  Though there were many topics discussed over the two days, the most prevalent one across multiple speaking sessions, was the need for improved operational performance as a way to increase quality, become more agile, and improve cost containment. It was discussed that embracing new technologies would be an integral part of making this happen.
  It’s at this inflection point that professional services companies, like Nymi, have to ensure that the latest innovations we’re bringing to market not only look to answer the challenge of Industry 4.0 but do so in a way that best helps ease the potential burden of the transition. Seamlessly integrating with the current technologies, while simultaneously setting our partners up for success in the future is something that we need to be conscious of as we implement our solutions.
  The Nymi solution is ideally suited for a vertical like pharmaceutical manufacturing, where strict regulatory compliance to tracking genealogy, serialization in the supply chain, and having a safe, secure method of managing user access to areas of the facility to support RABS, are all necessary components along the manufacturing chain. Layer on creating a state where a user is always authenticated (vs. point in time authentication, i.e., usernames and passwords) and you have a complete solution for compliance, security, traceability and efficiency that is unbeatable for data accuracy and integrity.
  Behavior Driven Development is a software development process that is based around the desired behaviors of a system; defining a framework for collaboration that is both precise enough for developers/QA and human-readable enough for business stakeholders and non-technical team members.
  Requirements are framed as user-focused scenarios (effectively acceptance criteria), composed in plain English with a descriptive grammar in the form: Given [some initial conditions], when [something happens], then [something should happen].
  The controlled structure of BDD requirements lend themselves to test automation. Frameworks like Cucumber and jbehave start with Scenarios defined in the plain "business-readable" language and then structure the test code in and around it.
  As the developers of Testpad, a tool to help you manage your manual testing, it's perhaps not obvious that we promote the idea of automating as much of your testing as is humanly/reasonably possible. If you're not automating any testing yet, stop reading and get on it!
  But you can't automate everything, and probably have lots of tests that you haven't got around to automating yet... in which case, despite wanting to automate everything, you have plenty of manual BDD testing to organise. Which leads us nicely onto the new support in Testpad for writing test plans as collections of scenarios in the Gherkin syntax...
  The Gherkin language is a formalisation of the Given/When/Then style of test definitions, as used by most prominently by the Cucumber automation framework amongst others.
  Testpad now automatically looks for this formatting and colors the keywords if it finds them. If Testpad doesn't recognise your way of formatting Given/When/Then, you can force ON the syntax highlighting. Equally, if Testpad is thinking you're using Gherkin when you're not, you can force it OFF.
  By default, every row in Testpad, that isn't a title row, is a "test" that will collect a result i.e. Pass, Fail, Blocked etc, along with optional Comments, Screnshots and Bug Numbers.
  When importing (or writing) BDD tests, this means rows that begin GIVEN and WHEN will also be regarded as tests looking for a result:
  For lots of customers, this is just fine, and recording a "Pass" against a GIVEN statement can just be interpreted as "yep, set that up, no problems", and a "Pass" against a WHEN statement can mean "yep, made that happen, no problems".
  For other customers, there is a preference to only record results against the THEN statements that define what should (and therefore might not) happen. To this end, Testpad offers a couple of options:
  Whilst Testpad's free-form layout can be used for almost any test process, Testpad excels in writing plans that are guides (whether high-level or detailed) for Exploratory Testing. The idea of exploratory testing is that you don't follow prescriptive instructions for what to test, but instead leave the human brain free to be inquisitive and tenacious in hunting down unexpected behavior. Test plans for exploratory testing are therefore "guides"; checklists of features that you don't want to forget to take a good look at.
  However... BDD/Gherkin tests, on the other hand, are more proscriptive, defining in significant detail what needs to happen given/when/then this or that happens. This is of course great for Acceptance Testing; proving that the stated requirements have been met. But alone, this is then less useful for having confidence that the system is bug free.
  If bugs crop up in the field after Release 1.0, go back to your Scripts (checklists) in Testpad and add tests/ideas/notes to the relevant scenarios to protect against regressions next time.