Code assistants helping your team write more features, but you’re also shipping more surprises?

Time to pin down your product behavior by finally getting that UI and e2e test suite.

100% Human is a six-week program to get a sustainable UI and e2e test suite in place for your product, so that increased feature velocity from coding assistants doesn’t result in release surprises sneaking past your preflight checks.

The idea is that a 100% Human can use her extensive experience with other human engineers, and with writing software, and with large language models, and with infrastructure and automation, to make it safer for you to integrate code assistant code into your production flow, whether the arrival of code assistant code into your codebase is planned, or not.

Get Started

Not at all! This is helpful past a certain level of application complexity, regardless. I just think a lot of teams have code assistants in the mix now, and I think testing products containing AI code using human skills, experience, communication, and systems thinking, and not by using more AI code to test the AI code, is a good idea.

Get Started

You’re ready for 100% Human when you have a list of interactions you know you need to test (maybe they are your preflight checks, or your QA list, or your aspirational UI and e2e test list, or a list of things in plain language that have gone wrong in the past) and you have a working CI system.

You know better than anyone what needs testing in your app, and this varies from app to app, but I am happy to help with additional suggestions if I notice that adding a new test would add security or other benefits to your users or your production flow.

If you aren’t there yet, you can also book the 3-week add-on to help you figure out your test plan, and/or the 3-week add-on to help you set up CI/CD.

Get Started

It isn’t cheap, but it’s no more expensive than six weeks of senior engineer attention at good US salaries to the same concerns, or their attention to something those tests could catch, but didn’t. And while it’s happening, that senior engineer you just thought of when you read that will still be there working on your product feature deliverables instead of on this. Bargain!

Get in touch for a quote

As you can guess, there is no way of knowing whether all of your test suite can be written in six weeks. Maybe, maybe not. The reason 100% Human UI Tests is only six weeks is because I think the Pareto Principle will help us focus in on the tests with the highest impact to your releases and to find the outer limits of your test complexity, after which you will have your gnarliest tests working, and you’ll have a testbed with roadsigns and documentation about how to add your future tests and maintain your current ones. I actually think this is more valuable than being “done with writing tests”, which is probably not a preferable goal compared to being less hesitant to add new UI or e2e tests or alter old ones.

Get Started

Maybe? But I’d find it much cooler if you didn’t even feel like you needed to once the six weeks were done.

Get Started

The choke points are:

• initial onboarding and project integration,
• assistance with code changes outside the tests,
• answers to codebase questions,
• and acceptance code review/testing.

The faster these are, the more tests can be finished.

It is a very good idea for there to be a DRI (directly responsible individual) for me to liaise with. They can primarily be doing other things, though!

Get Started

Yes indeed! There are a few reasons that a test might not really be do-able even when it’s a great idea. Some of the reasons:

• It gets into an area of bugginess and unreliability for test support in either the IDE, the SDK, the hardware, or your CI service.
• It involves privilege escalation or code exposure concerns inside of your CI or similar services.
• Your CI doesn’t support it.
• Tricking your CI into supporting it would create sustainability risks for your future testing.

Part of the service is saying “we should think about whether there is a different way to get confidence about that” and making some suggestions, or, occasionally, just saying “we can’t do that”.

Get Started

I talk to you and your team, listen to some things which have happened and what you manually check before a release, I tell you some things I think could happen based on my Apple platform software development history, devops, and security experience, and we give potential tests a criticality rank and difficulty level based on qualitative and quantitative factors.

That will direct the effort to what will help you the best, in the order that will shake out integration issues in the way that is fastest to address. This would not give the same results for the same feature in different products or companies, because the purpose and history of the product are factors in the ranking.

Get Started

You should definitely have other tests! We can even discuss that if it is a need. It is also possible that some things that look like potential UI or e2e tests would be a better unit or snapshot test, and I will tell you if so. However, I think a good suite of UI and/or e2e tests is a great last defense against product-level surprises that arrive due to code assistants adding features much faster, but with less reasoning and less systematic/historical knowledge about your product.

Get Started

Same answer to both: writing sustainable UI tests that help reduce release fears requires experience, and understanding more than one software and human system.

Get Started

Of course! Your CI system should be where we do acceptance testing for the tests. If you don’t have one, I can help you set one up for the first time, as an add-on.

Get Started

Github, Gitlab, Xcode Cloud, or self-hosted runners if you have in-house security engineers (self-hosted runners are cool, but they need someone around to worry about them a little bit 😂)

Get Started

Yes! That is an add-on that can happen before we start writing your tests.

Get Started

Smash this button and ask for a quote 😂

Get Started

Go ahead and send it over!

Ask a question