What are some of the tools that make your job easier?

Hi all,

I am always curious what kind of tools everyone uses and couldn’t live without to do their job.

  1. Lens k8s IDE - most of my job at Cycle Labs is working with Kubernetes, and most of Kubernetes is command line (kubectl). Lens is a really, really, really great graphical representation of your k8s clusters with the ability to quickly connect to pods, edit manifests, and more. I have only been using this tool for about a month and it’s made my job way more enjoyable.
  2. Helm - Helm has been a game changer for us to be able to package not only Cycle Cloud microservices, but also external tools that we use (Grafana, Prometheus, etc) and then deploy + manage them on our k8s environment(s). I love the revision control, and the ability to work on the Helm charts out of a source code repository. Helm has really allowed us to leverage pipeline based deployments using Azure DevOps, and really focus in on those iterative changes.
  3. Snag-It - I am a huge fan of documenting my work with screen shots and videos, and being able to easily copy + paste those into Az DevOps issues, Slack, etc. Snag-It saves me a ton of time and has all of these features built into it. It’s one of the few paid applications I require for my job!
  4. GitHub Desktop - I won’t lie. I do not know Git command line, and I have no desire to learn it. There, I said it. I have enough CLI knowledge in my head, so I choose to use GitHub Desktop. This integrates nicely with native Github.com, as well as Azure DevOps. I use this to manage all of my repositories and love the integration with VS Code.
  5. VS Code - Without a doubt, my favorite IDE. I love the portability of VS Code and the giant pool of extensions for it. VS Code just simply works
  6. Homebrew - I love developing on Mac OS X - but a lacking package manager can be sort of a bummer. I’ve gotten used to Homebrew and use it for my tools like Kubectl, Azure CLI, PowerShell, etc.
2 Likes

Lately I dig Postman, Macpass, the Azure Cloud Shell, and my best friends are a set of old school command line utils… cat, grep, cut, awk, wc, etc.

Postman - Doesn’t need an explanation these days. In reality, I prefer a set of shell/curl scripts, but Postman is a great way to organize and share that same sort of thing.

Macpass - I’m not ever going to share my passwords with a giant corporation no matter how “secure” they are. The Keypass project is my go to for a password manager. For OSX, Macpass is my favorite port.

Miro - Very flexible. Could be used for about anything, but for capturing flows, maps, etc for business requirements this is a great tool. It fits nicely upstream from a Feature File. I’ve been contemplating how this fits in to Cycle Cloud!

Figma - I know all designers have their own preferences, but this thing rocks! There seems to be a Cycle Cloud integration opportunity here too?

Docsend - Send you people a trackable document. Get some analytics on it. Real easy. Does a pile of other things too.

Canva - So much easier to make a presentation that’s not ugly. I just can’t anymore with PowerPoint (sry, MS, I just can’t)

DBeaver - @brian converted me. I use to have a commercial product and I tried out a few others, but this one is pretty great.

Much of what has already been listed, like VS Code, DBeaver, and Postman are all excellent tools.

One great tool the company I work for has built up is an internal cli interface for working with common infrastructure things. It allows me to easily authenticate with the Vault, effortlessly deploy branches to the staging environment with a unique url, and easily using local containerized versions of some of the projects.

I was introduced to a tool yesterday that was cool. Keybase allows you to send things with E2E encryption. I used it yesterday for someone from our DevOps team to send me some login credentials. What made it especially interesting was he was able to set a 5 min timeout on that message and after that it was destroyed.

1 Like

I am coming from the business side - gathering user requirements and acceptance criteria for developers. A tester would take my documented acceptance criteria and use it to create an acceptance test.

I admittedly have trouble sticking to one tool for gathering requirements! I find that ideas, potential solutions, and work requiring development come in all shapes, sizes, and flavors. Often, I’m considering acceptance criteria around a new feature. Some new features are pretty obvious - there’s a convention for it. An example would be if I need to add the ability to move a file, and I want the option available in a context menu. I can get pretty specific fairly early in the process. At those times, I can just type up a Scenario of Given/When/Thens right off the bat.

Other times, I have a user challenge that requires a lot of brainstorming, both to understand the core need, and also to understand and explore all the different ways it could be tackled. It is really hard for me to jump right into Feature File format in those moments. We just aren’t quite there yet, if that makes sense. But we are still definitely working through acceptance criteria, just at a different level. Depending on the context, in these cases I tend to use:

  • Miro or a Google slide for whiteboarding where I want to map a process visually with boxes and arrows
  • A Google doc for just jotting notes as the discussion progresses organically. Being able to have headers, bolding, etc is helpful. It is also helpful to be able to toss a table in there if we randomly need to map things like words, concepts, systems, etc.

And then I work toward specificity so I can get it into Given/When/Then format in Cycle Cloud.

For me, it would be so nice to be able to map an executable test in Cycle Cloud to these other source documents in Miro or Google Docs. It would eliminate a step for me, in many cases. And it would “meet me where I am” as a user.

As a business user, I am only part of the equation, though. I’m curious how a true testing professional would feel about acceptance criteria being represented in all these different ways. I’m also curious how that testing professional would feel about mapping their executable tests to criteria represented in these various ways.