Paul has 15 years of experience in software development, design of frameworks and testing automation. His level of efficiency and problem solving ability may impress even experienced guru. Paul is the founder and CTO/CIO of Beaufort Fairmont Automated Testing Service.
Does your team struggle to write good gherkin in BDD? Do you know good Gherkin when you see it, but struggle to describe what makes it ‘good’? Join us July 23 to continue our learning of BDD and Gherkin!
Using Gherkin, teams write “Given-When-Then” scenarios in plain, understandable language. Writing Gherkin may seem easy, but writing good Gherkin is hard. In this webinar, we will cover the basics of Gherkin along with four tried-and-true techniques for writing good Gherkin. We will also see how Gherkin scenarios can be automated using popular BDD test frameworks.
In previous webinars, we learned about pragmatic uses of Behavior-Driven Development. Now, we’ll take a deep dive into Gherkin, BDD’s most popular specification language.
You will come away from this webinar ready to write good behavior specs without making common mistakes!
Andy Knight is an engineer, consultant, and international speaker who loves all things software. He specializes in building robust test automation solutions from the ground up. He currently works at PrecisionLender in Cary, NC. Read his tech blog at AutomationPanda.com, and follow him on Twitter at @AutomationPanda.
Imagine having all entry-level developers work on a project together. Imagine having a leader or manager that had never participated in a software development project. It would be chaos!
There’s no way an experienced software leader would assemble a team like this. Not if they wanted a product from the group in a reasonable timeframe with some expectation of quality.
Junior developers aren’t a problem. We’ve all been junior level. If you’re learning new things you get to be a noob all the time. I recently felled some trees with my Dad. It was my first time. I had a lot to learn. Not only did I feel like a noob, I was one. I had to understand that fact and accept it to stay safe.
Having Junior developers on a team is not a problem
The problem with the team above has more to do with the summed experience of the team.
A good leader can run a software team if they have strong technical people around them.
If the team we mentioned had even one strong technical person and a strong leader, their chances of success go up. A balanced team would be even stronger.
We know as experienced software leaders that a bad developer is not a net zero influence on the team. A bad developer is a net negative. Stronger developers have to re-do the bad developer’s work. That takes the better developer’s time away from features, direction, time with others, mentoring, etc. It slows down the team as they are occupied with fixing all the issues with the code the bad developer creates.
Inexperienced Test Automation Teams
Often, we allow test automation to be stocked with bad developers or newbies. If we wouldn’t do this for the applications why do it with automation? Shouldn’t the test automation code be stronger and more robust than the application it runs against?
We need automation code to be perfectly credible in order to test our services.
Beware the inexperienced automation team
So many companies introduce testers with no coding experience to code, then expect them to automate. Often I see teams of test automation engineers lead by people with no software development experience.
If your org is thinking making a transition to using test automation. Don’t stock the automation team with 100% newbies. Get some guidance.
If you like the way we do things at Beaufort Fairmont – if you like automation success – contact us and use our people and experience to balance your team.
You may have noticed over the last year or so, more of the Beaufort Fairmont webinars are done by guests than by me. That’s for several reasons.
First, I’ve personally created and recorded over 20 one-hour webinars over the last 3 years. I realized early on, the pace was unsustainable. Coming up with original content takes a good deal of time and energy. I want you all to have the best content you can get, not something I felt like I had to put out there because it was a new month!
Secondly, I wanted to get more voices on the webinars so that you would hear others’ experience. Sometimes two people can say the same thing, but one resonates differently. On the other hand, sometimes people say different things. I want to share different ways of approaching test automation.
Is your team engaged with test automation? Do you wish they were?
The findings from the State of DevOps survey, as explained in Chapter 4 of Accelerate by Nicole Forsgren, Jez Humble and Gene Kim, show that having reliable automated tests, primarily created and maintained by developers, is a predictor of high IT performance. At the same time, the results show that testers are also essential for helping evolve automated tests alongside developers.
We have many excellent automated test tools available today, but also many teams that still lack this reliable regression test automation.
Lisa Crispin will share her experience using a whole-team approach to test automation to help the team achieve high performance, especially in today’s continuous delivery environment. In this webinar, she will explain why getting developers as well as people in other roles engaged in automation is a key success factor, and ways to get that collaboration going.
Lisa Crispin is the co-author, with Janet Gregory, of More Agile Testing: Learning Journeys for the Whole Team (2014), Agile Testing: A Practical Guide for Testers and Agile Teams (2009), the LiveLessons “Agile Testing Essentials” video course, and “Agile Testing for the Whole Team” 3-day training course offered through the Agile Testing Fellowship. Lisa was voted by her peers as the Most Influential Agile Testing Professional Person at Agile Testing Days in 2012. She is a testing advocate working at mabl to explore leading practices in testing in the software community. Please visit www.lisacrispin.com and www.agiletester.ca for more.
Ever hear your developers talking about Refactoring as if it’s a magical spell that solves all problems? Ever wonder if they’d loan you that potion for your test automation scripts?
Join us to learn the magic of Refactoring. We’ll discuss the proper definition of refactoring, what it is, and how to do it. We’ll use test automation scripts to walk through several key refactoring techniques as they can be used in test driver scripts like those of cucumber and robotframework.
Join Paul in this interactive session and experience refactoring firsthand. Practice the techniques like: “Extract Method”, “Introduce Explaining Variable”, “Pull up Method”, “Extract Superclass” with available demo/code.
No coding experience required. Join us and refactor human-readable test scripts. Simply your life as a test case creator with refactoring.
Is your company interested in DevOps? Are you struggling to figure out how testing fits in?
DevOps is making companies want to move faster, but few know how. Agile and CI/CD are the buzzwords we encounter while trying to implement DevOps. But what is the role of QA in this faster world? How can QA help in become Agile and implementing CI/CD?
Carlos Kidman is the QA Manager at Jane.com, but who would have thought that Magic the Gathering would introduce him to QA in the first place? Now QA is an integral part of his life. He started in QA Engineering, but quickly moved into Test Automation and grew to appreciate each player and role in the development game. He wants to share the love and joy he’s found with QA and believes that a rising tide raises all ships.
Carlos specializes in creating Test Automation Frameworks for UI, Integration, and Service tests, scaling tests and empowering developers and testers with CI/CD tools like Jenkins, Docker, and Kubernetes, and works closely with Infrastructure and DevOps organizations.
He is currently a QA Manager at Jane.com and is very active in the local testing community. He is the founder of QA at the Point and QA Utah, a board member of DevOpsDays, and an instructor on TestAutomationU.com
**The winner must be registered for TriAgile, registered with the form below, and at the giveaway during lunch to win!
TriAgile 2019 - Bag Giveaway
Address Line 2
State / Province / Region
ZIP / Postal Code
AfghanistanAlbaniaAlgeriaAmerican SamoaAndorraAngolaAntigua and BarbudaArgentinaArmeniaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBosnia and HerzegovinaBotswanaBrazilBruneiBulgariaBurkina FasoBurundiCambodiaCameroonCanadaCape VerdeCayman IslandsCentral African RepublicChadChileChinaColombiaComorosCongo, Democratic Republic of theCongo, Republic of theCosta RicaCôte d'IvoireCroatiaCubaCuraçaoCyprusCzech RepublicDenmarkDjiboutiDominicaDominican RepublicEast TimorEcuadorEgyptEl SalvadorEquatorial GuineaEritreaEstoniaEthiopiaFaroe IslandsFijiFinlandFranceFrench PolynesiaGabonGambiaGeorgiaGermanyGhanaGreeceGreenlandGrenadaGuamGuatemalaGuineaGuinea-BissauGuyanaHaitiHondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsraelItalyJamaicaJapanJordanKazakhstanKenyaKiribatiNorth KoreaSouth KoreaKosovoKuwaitKyrgyzstanLaosLatviaLebanonLesothoLiberiaLibyaLiechtensteinLithuaniaLuxembourgMacedoniaMadagascarMalawiMalaysiaMaldivesMaliMaltaMarshall IslandsMauritaniaMauritiusMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMoroccoMozambiqueMyanmarNamibiaNauruNepalNetherlandsNew ZealandNicaraguaNigerNigeriaNorthern Mariana IslandsNorwayOmanPakistanPalauPalestine, State ofPanamaPapua New GuineaParaguayPeruPhilippinesPolandPortugalPuerto RicoQatarRomaniaRussiaRwandaSaint Kitts and NevisSaint LuciaSaint Vincent and the GrenadinesSaint MartinSamoaSan MarinoSao Tome and PrincipeSaudi ArabiaSenegalSerbiaSeychellesSierra LeoneSingaporeSint MaartenSlovakiaSloveniaSolomon IslandsSomaliaSouth AfricaSpainSri LankaSudanSudan, SouthSurinameSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTogoTongaTrinidad and TobagoTunisiaTurkeyTurkmenistanTuvaluUgandaUkraineUnited Arab EmiratesUnited KingdomUnited StatesUruguayUzbekistanVanuatuVatican CityVenezuelaVietnamVirgin Islands, BritishVirgin Islands, U.S.YemenZambiaZimbabwe
By submitting this form, you agree to receive occasional emails from Beaufort Fairmont for events like webinars and offers for our services in test automation consulting, training, and dedicated experts.
Monday, guest Andy Knight did a wonderful webinar for us on Behavior Driven Development (BDD) and how we practice it. If you missed it, check out the recording here (register and the video will start).
Several people had questions during the webinar that we didn’t have time to answer. Andy has answered all of them in a blog post here. Make sure to check it out!
Keep a look out for the second part in this series on BDD, we’ll be hosting Andy again soon!
We recently had the opportunity to work with a client on a very short engagement. Here is what our dedicated expert accomplished in the first 13 days.
First defects detected with automation
Reviewed existing automated test suites
Enabled running UI tests on any browser
Created a source of truth for automation
Began testing continuously
Outlined milestones for continued success with automation
The client’s test automation code base was stale. The build hadn’t been run properly, with one button-press in a long time (if ever). We identified issues within the build on day one (Maven, Nexus Sonatype, & Java) and fixed them quickly. Our dedicated expert ramped up on the code base in a couple days. He was running tests in the first week. His ramp-up’s impact on the rest of the team was nominal.
In less than 13 days the team had working build profiles in the pom files that would build the automation code base and run the tests from any system.
First Defects Detected
Detecting the first issue with automation is always a milestone for us with clients.
This client had existing test cases in Selenium Webdriver. The status and reliability of many tests were unknown. Beaufort Fairmont’s dedicated expert worked through many of these tests and realized that some of them were actually pointing out legitimate defects. These were logged and development was able to run the tests to expose the issue and debug through it saving time and money.
Reviewed Existing Test Suites
Test cases must be continuously reviewed in order for the team to rely on them to detect change. The client asked us to review their tests. We had them running in days and were able to comment on a significant portion of those tests’ soundness and reliability in less than 13 days.
Running Against Any Browser
This client’s automation framework had lacked attention for a while. One key element for the client was being able to run any browser for the tests. Our dedicated expert found the bug buried deep in the framework that was forcing all tests to be run with the chrome driver. Others on the team had tried to find the issue, but couldn’t. This is where extensive experience with different automation code bases and many different tools comes in handy. We found the issue in a one-hour pair-programming session.
Because we were able to fix the build earlier, now the client can run any browser from any client using a simple maven command.
Source of Truth
How do you know your test executions are trustworthy? You have to run them in more than one place. But, how do you know which is reliable? Create a source of truth.
In this short engagement, our dedicated expert was able to create a test agent in the CI system to run the tests. This system became the source of truth for testing.
So many companies struggle to get continuous testing started. The client trusted us with permission to create build jobs in their CI system. Because of this, and because we know CI systems well, we were able to set up jobs to run specific test suites many times a day. Previously, the client was running these tests by hand, once per release (about once a month). When this is the case, we don’t catch changes to the system under test fast. Development slows down. And feedback is stale.
The CI pipeline jobs we introduced are already providing developers with what they need to move forward more quickly. Issues will be triaged daily and there will be no surprises at the end of a one month release cycle.
Our success is when our clients are successful. We wanted to make sure the client had a path forward whether we were helping them or not. So we created a high-level plan with attainable objectives that they can use for the months and years ahead.
When You’re Ready
This is one of the many success stories our clients have experienced over the last 10 years. When you’re ready for an experience like this, contact us.