QA and Release Process/Management
- North America
Employer's note: Location is East Coast-ish. More in the posting below.
We're looking for a new team member to help fill the space around the development process, including both QA and driving the release management process behind our small-and-mighty engineering team. More details about us and about the things we need below, but to shorten it to a few bullet points:
1. Someone needs to test things manually. This is probably 2 days of the sprint (maybe 3 until you get familiar).
2. Someone needs to write automated tests so we don't have to test things manually as much. In other words, automate #1. Also, be the driving force behind getting everyone to write good tests.
3. Do release management. Make sure CI/CD is all set, GitHub merges are happening, merge conflicts are resolved, and probably be the one to hit the sparkly DEPLOY button. (Sorry. There is no sparkly button. Sorry. That seems like a process improvement you can make. See #4.)
4. Improve the release process. We have some Jira-GitHub automation, but it could be better. We have a love/hate (well, tolerate/hate) relationship with our CI platform. Make #3 easier on yourself and the team.
The longer description
We believe that our ability to ship software quickly is a key competitive advantage, and as-such are continually driving ourselves towards a fully realized continuous delivery process. In this role, you will be expected to be a leader towards accelerating this effort, which entails overseeing the full delivery lifecycle - planning the release process as features are being designed / developed, aiding the engineering team's build out of functional & automated testing efforts, assessing the quality criteria of what is shippable, and communicating the timeline and expectations to stakeholders. Furthermore, you’ll be responsible for driving a company culture of fast, reliable software delivery by researching the state of the space, prioritizing areas of investment, and partnering with others to move us forward. This all means that you'll be helping our with the actual testing of the code and driving improvements to how we test. Should we change how we're using our tools to make this better? Drive that discussion. Yes, we're looking for a combination of all of these things! Oh, and if you have an interest ability towards the DevOps world, or you want to wade into the world of data/data management/analysis, or if you want to actually write some application code on the side because it makes you happy, we're small and nimble and have plenty of work to do; the focus is on the getting code out the door, but there's plenty of other things too.
*** Update on 'Location' : So, while we do have the 'remote' flag on, we're *ideally* looking for someone in the Richmond, VA area-ish (think: 2 hour train ride, so DC to Raleigh to Charlottesville); however, you could live with the NE corridor-ish (think: <2 hour flight; our VP Engineering is near Boston), too. Or, put another way: are you available to be in the Richmond, VA virtual office once every month-ish (in, you know, normal times when there isn't a global pandemic)? Yeah, That'd be greaaaaaat... Don't forget the cover page on those TPS reports either.
Generally, what are we all about?
Ideally you are as eager and passionate as we are about:
Crafting thoughtful user experiences that help people (in our case doctors, nurses, and medical assistants) make the best decisions possible while removing tedious BS from their daily workflow.
reducing the large amount of time that clinicians spend on documenting what they have already done (go ahead -- ask your doctor about how much they like their EHR (electronic health record) next time you’re sick)
- re-imagining not only the traditional user experiences & workflow of EHRs, but also the medium through which the latest medical best practices can be actionably and seamlessly incorporated into delivering care.
OK, you may not be super-passionate about these things right now (let’s face it -- medical workflows and “EHRs” sound pretty boring on paper), but you will be. Why? Because you’ll be building software that fixes INCREDIBLY FRUSTRATING experiences for doctors. And it’s incredibly satisfying to modernize, replace & improve outdated, problematic software. It’s important. And you’ll be loved/adored for it. (And once you see the way this stuff is currently done, you’ll be left scratching your head or otherwise disappointed)
A little about us...
Our mission is to remove the digital roadblocks that interfere with healthcare providers’ ability to spend quality time with patients (Oh, and we try to help them make better decisions along the way as well). In particular, we work with Ob/Gyns and their staffs to ensure they can do their best jobs, and we do whatever we can do to help them.
...A Lot About You
Ideally, you are a multitalented wunderkind who runs circles around each of the below bullet points, but let’s be real : while some of these are must- have, many are wish-list. We may have gotten a bit carried away with these, so if feel your unique combination of skills is close-ish to the mark, don’t hesitate to reach out. In fact, do so enthusiastically.
- Prepare test & release plans for features in design / development.
- Do the manual work to actually test things.
- Make sure things actually get tested (while we strongly believe in developers/reviewers testing, realistically, you'll be doing some of this too)
- Automate yourself with automated testing (we have a healthy start on e2e testing using Cypress) as much as possible to free yourself up to do other things.
- Work with engineering and customer success to define and maintain quality standards.
- Lead the pre-release acceptance testing process along with the product managers.
- Oversee (i.e. be the main point of contact) during the release process.
- Work with development, Customer Success, and product to make sure release notes as features are delivered.
- Lead the organization in continually making improvements to the release process.
- Demonstrated success building sane release processes within organizations
- Strong written and oral communication skills that ensure that people are speaking the same language about expectations and responsibilities
- A demeanor that brings a calm confidence to the sometimes frenetic world of releasing software (or convince us that a frenetic demeanor is actually the right answer!)
- Experience with quality assurance processes, standards, and tools
- Enough technical understanding to discuss feature nuances with engineers
- Ability to both pay attention to the details, and also keep a bead on the broader context. Put another way, you don't let the perfect get in the way of the good.
- You've worked at startups before or have always been looking for an excuse to
- You work well in a loosely structured PM/Managerial environment (we’re agile with a “little a”)
- Have experience with e2e testing (ideally Cypress), dealing with issue tracking (Jira; sorry), and version control (merging, automation, etc.) in Github.
- Understand that manual QA is, in fact, a thing that has to be done. Actually liking it isn't a requirement, though hopefully you don't find it miserable.
Us + You?
As the newest member our engineering team, you’ll be an integral part of every aspect of our business strategy, dev roadmap, technology architecture decisions, and, undoubtedly, will wear a lot of hats.
One of the hats -- in addition to your release/process/QA hats -- will, like all of our employees, be the Customer Hat. At Dorsata, we are fervent (rabidly obsessive, really) believers in frequent, high-touch interactions with our involved, loyal customer base, who drives our roadmap. As we've grown, developers are often removed from the day-to-day, but you should be the type of person who is at least able to empathize and ask good questions of customers.
Obligatory Message to Third Party Recruiters:
If you're a third-party recruiter who is looking to send us resumes, please don't. We don't accept resumes from third-party recruiters. No, we're not interested in how Yet Another Recruiting company can help us make the world a better place, etc.; we already know good people who do that when we need to. (We're amazed at the number of random LinkedIn messages from recruiters we see, both on the hiring and job seeking side. Yes, you're great human beings, but please move along. No, really, please move along now, dear recruiter friend.)
Dorsata’s clinical workflow intelligence platform is designed to work both top of and inside of the existing electronic health records (EHRs) that our customers use. Dorsata is an AngularJS (migrating to Vue)/Rails SPA designed collaboratively with women’s health providers to support the way that they work & think -- not tell them how to work & think (or add additional clerical burdens to their already-busy day). We want practitioners of women’s health to feel like they are using a piece of software not only designed for them, but by them.
More About Us:
How We Interview & Hire
Like many of the other startups you are currently perusing on stackoverflow/angellist/hired/vettery/reddit/linkedIn/etc., our interview process begins with an intro call (and if it goes well, a second) to help you learn more about the role, for us to hear more about you, and to help the two of us decide if Dorsata is a mutual fit; one of these calls is with the VP of Engineering. If we move forward, the next step will be a more in depth call with us that dives into some problem solving about healthcare. Based on that problem solving exercise, we do a quick real-world based coding test to make sure you actually have a little AngularJS (or React or Vue or AngularX) / what a computer is, though for this interview, we make actually just build something that's a little broken and have you help figure out where.
Full disclosure: While we have a process to interview for this position, feel free to game the system by suggesting how we should interview for this role. Even just mentioning this section in your cover letter would be nice to tell us that you actually read this. You'd be surprised at how many people don't.
We're small, so we also like to have people talk to our CEO as part of our hiring process.