You may have heard the expression, “Take a walk in your customer’s shoes.” In reality, this is not an easy thing to do. As a developer working at Provengo, my role extends to coding, addressing bugs, and working with clients. While I use our platform all the time for our own needs, recently, I had the opportunity to use the tool for a client project.
I saw, first hand, how the tool produces remarkable results for its users, helps them overcome development challenges, create digital specifications and requirements, and transform these requirements into a dynamic blueprint for me as a software developer:
- Seeing the tedious Spec phase in a new way
Like many of us have experienced, I was provided with a (very long, boring, and not so clear) spec document describing a system’s behavior in many different cases and needed to come up with a test plan for it. To get the value out of the Provengo tool, we need to feed it with some requirements/business logic rules. This part is usually the core of the process and also the more interesting part of working with the tool. It requires analytical thinking skills to model the desired SUT behavior in such a way that requirements interweave with one another and then a map is created accordingly.
- Warning: Addictive! Like any new tool, after I got over the first hump of the learning curve, things started to make sense and even became addictively efficient! When running the analyze command with new requirements, Provengo can visualize it on a detailed map, making the process very addictive. With every update we make to the model, we immediately get a new map—very effective when there are many changes or a large set of requirements. It works great for a sole developer, and even more so for teams. For teams who have non-technical members, this can become a key communication tool.
- Boosting the process: At this point, the process became more exciting. I found myself enjoying using the tool from the user angle, going through the tool docs and the project spec, and finding exactly what I had in mind. For example, after logically dividing the SUT behavior into layers, I knew I wanted to use the State Machines library to describe the high-level flow. This layer had a specification that divides the flow into two major cases, so I needed a way to constrain the states. Looking through the docs, I found the methods `sm.next.cannotBe()` and `sm.next.mustBe()` that provide this exactly, as the names suggest. This is one major advantage of Provengo: it has a variety of DSLs and libraries that one can use to describe the system he’s testing in a way that suits his way of thinking about it, and still be aligned with the requirements.
We all learned that the software development process, including testing, takes time, involves a lot of “back and forth” with the business/product. We all wish for improvement in our day-to-day tasks, and we all love to see good results faster. When introduced to a platform that challenges the “normal” processes, work becomes exciting, and the focus shifts to documenting progress rather than problem-solving. So, what started as a boring task became interesting and mind-opening And…I learned how our customers feel. A new and exciting perspective for me to think like them for once.
>> To continue the discussion, join our Discord Community- HERE
(Feature photo by Markus Spiske on Unsplash)
