Tag: testing

CheckType parameters for processing XUnit test results

A Jenkins pipeline can publish XUnit test results as a step in a Jenkinsfile. Being unable to find any online documentation for the XUnitBuilder CheckType parameters, I dug into the code myself to find the answers.

Here’s a full XUnitBuilder stanza like that generated from the Jenkins Pipeline Snippet Generator (with the lines wrapped):

step([$class: 'XUnitBuilder',
     testTimeMargin: '3000',
     thresholdMode: 1,
     thresholds: [
       [$class: 'FailedThreshold',
         failureNewThreshold: '',
         failureThreshold: '',
         unstableNewThreshold: '',
         unstableThreshold: ''],
       [$class: 'SkippedThreshold',
         failureNewThreshold: '',
         failureThreshold: '',
         unstableNewThreshold: '',
         unstableThreshold: '']
     ],
     tools: [
       [$class: 'CheckType',
         deleteOutputFiles: false,
         failIfNotNew: false,
         pattern: '**/unittests.xml',
         skipNoTestFiles: false,
         stopProcessingIfError: true]
     ]
])

Here are the CheckType parameters and what they mean:

  • deleteOutputFiles – If true, the output files are deleted after being processed. If false they are left in-place. Default: false.
  • failIfNotNew – If true and files match the pattern but were not updated in the last build, the check fails. This helps ensure that all tests were run. Default: false.
  • pattern – File pattern that identifies XUnit-formatted output.
  • skipNoTestFiles – If true and no test files matching pattern are found, the check is skipped. If false and no tests are found the check fails. Default: false.
  • stopProcessingIfError – If true, any error (such as an empty result file) will stop any further processing. If false, errors will be reported but processing will continue. Default: true.

Note that you can get by with a much smaller step stanza by just including values that differ from the defaults, eg:

step([$class: 'XUnitBuilder',
     tools: [
       [$class: 'CheckType',
         pattern: '**/unittests.xml',
         skipNoTestFiles: true]
     ]
])

 

SDETs in Space!

I’m having a heck of a time finding, much less hiring, SDETs to fill my open Ground Systems and Platforms SDET positions. My gut tells me that the job descriptions just aren’t exciting enough to get people’s attention. What does a “Ground Systems SDET” do? What “Platform”?

Lets see if I can’t explain them a bit better.

Talk-To-A-Satellite SDET

Ground systems refer to all of the hardware and software components here on the ground that work together to talk to a satellite in orbit. That’s everything from the software the satellite operators use to issue high-level commands, to the systems that relay that information to our ground stations around the world, to the services on the ground station that control and task the radio chain, to the services that move the antennas, to the entire telemetry pipeline back to the missions operations center allowing the operators to know the health of the satellite and ground system components.

Everything that goes to the satellite or comes from it goes through our ground systems. These systems have to work reliably to support our growing constellation.

Making sure they all work together is where the Ground Systems SDET comes in. You’re the first line of defense in making sure that all the awesome code our devs are slinging actually cling together and make a functional system. You get to play with our satellite-on-the-table (aka: Flatsat) in our staging environment to make sure what is being built works, and then see that be deployed to our production systems and task Pathfinder-1 (and soon Pathfinder-2!) in space.

If that sounds interesting and you either live or are willing to relocate to Seattle, WA, take a look at the Ground Systems SDET position and toss me your resume!

Satellite-Picture-Selling SDET

We’ve taken all of these pictures of the Earth from space, how do we sell them to people? Well, you need an intuitive interface for customers to see all of the images you have in your catalog, buy them, and task new pictures to be taken. That’s our Platform that ends up tasking the satellites in space through our ground systems.

There are a lot of factors in play when you start talking about satellite imagery. How cloudy was it when the picture was taken? What angle was the picture taken at? Where, exactly, was the picture and how does it map onto the earth? When was it taken? Is the customer allowed to see an image over this country?

And you can’t just show them a grid view of the images. You need to place those images onto an interface that makes sense, such as a map of the Earth, and oriented such that they align up correctly.

The interface needs to scale with the ever-growing number of users as well as the ever-growing number of images in the catalog. It also needs to have good access time to our customers around the globe while maintaining security restrictions on what geographies have access to what images.

Making sure all of this works is the role of the Platform SDET. As the devs craft javascript and RESTful backend code at a break-neck speed, you’re the one that ensures cohesion and functionality. Oh sure, their new gee-whiz feature looks great in demos, but how does it scale? What did they break adding that new feature? You’re one of the first to see new images from the satellite as they make their way into our catalog and enable customers to fully realize the power of our satellite constellation.

Interested? If you live in the Herndon, VA area or are willing to relocate, take a look at our Platform SDET position and apply!

Resume tips when applying for an SDET job

I’ve been a Software Development Engineer in Test (SDET) for 15 years. I’ve interviewed many people and seen many resumes. Now, as a manager with 3 open SDET positions1, I see a lot of resumes every day. Here are some tips when applying for an SDET job.

Be a tester; have test experience

I can’t tell you how many resumes I’ve seen for developers applying for an SDET position. Pretty much by definition, developers aren’t testers. That isn’t to say that developers can’t test, or testers can’t develop, but the skill set and approach of the two are very different. If you are applying for an SDET position and the words ‘test’ or ‘validate’ do not appear prominently in your resume, you’re probably applying for the wrong job.

Demonstrate test methodologies

Your resume should communicate that you understand test methodologies and that you come from a culture of test. What type of testing have you done (unit, functional, system, integration, regression, performance)? Do you understand the software development process? Call out automation that you’ve done and the bugs exposed or time saved. Tell me how much you love breaking things and representing the customer.

Have development skills

The ‘D’ in SDET is for development — you need to have some development experience. If a company is hiring SDETs it’s because they are looking at people to write and develop automated tests and tools for automated tests to use. SDETs are not hired to be manual testers or push buttons, they’re hired to write automated tests to break the heck out of things. I want to see some software development experience on a resume and know what languages you are familiar with.

Write tests or tools/frameworks?

If you are an SDET that likes to write test automation frameworks, call that out on your resume as some SDET jobs are looking for more tools- and framework- oriented people. If you like to write automated tests and actively break things, call that out on your resume.

Most of the time I’m hiring for an SDET, I’m looking for them to write automated tests, not frameworks. Both are perfectly valid skills, but make sure it’s clear where your skill set lies and be upfront with how that matches with the position.

Make your platform experience clear

Just because you are a rockstar SDET on Windows doesn’t mean you necessarily have the skills needed to be a rockstar SDET for an embedded-Linux device. Similarly, if you have extensive experience writing system integration tests for Linux distros doesn’t mean you know a hill of beans about the same for Windows 10.

Your resume should be very clear about which platforms you have experience with and which ones you’ve simply used.

Overall resume tips

These tips aren’t specific to SDET positions, but they’re worth calling out:

  • Any link you put on your resume is fair game to be viewed.
  • If you have a LinkedIn profile, assume I will search for it and look at it. I will not find you on Facebook or do a Google search for your name, but I assume your LinkedIn profile is there to present your professional image to the world and it should not contradict your resume.
  • If at all possible, provide your resume in PDF format. That’s the only way to guarantee that the way it looks on your screen is the same as it looks on mine. There can be huge differences when I open up your .docx resume on my Fedora desktop in LibreOffice with no Microsoft fonts compared to how you meant for it to be viewed on your Windows machine in Office.
  • If you’re not already friends with a technical writer, make friends with one and ask them to look over your resume in exchange for buying them lunch; their feedback will make your resume stand out from the crowd. Tech writers are amazing people and knowing them will enrich your career and your life.
  • Spell check your resume. The number of resumes with horrendously misspelled words is, frankly, sad. I don’t expect it to be perfect, but misspelling ‘validation’ is not going to impress me (and yes, that’s happened).

More?

Fellow SDETs and test managers, what do you look for on a resume? What do you like to call out on yours?

1 This post contains my own opinions and does not reflect those of my employer, because everyone is paranoid around lawyers.