This is a guest posting by Jim Holmes
Continuous learning is a critical concept for your career and personal life. I’ve slacked off a bit of late, and I decided to focus on three specific things I want to get better at over the next six or so months. I have some modest exposure to all three, but I want to move far past basic proficiency and into solid experienced implementation knowledge. I doubt I’ll achieve mastery of any of the three, but at least I’ll have a great foundation for regular work in those areas.
(As a side note, if you haven’t read Andy Hunt’s terrific book Pragmatic Thinking and Learning, please go order a copy. It’s an extraordinary work on how we humans learn.)
Dive Into Postman
Postman, if you’re not familiar with it, provides extraordinary help in working with APIs. I grew familiar with it from testers who were using its Chrome plugin to do exploratory testing around web APIs–think of checking calls to REST endpoints.
Postman provides the ability to make and validate calls to endpoints while easing the tricky parts around headers, JSON packages, authentication, and any number of other troublesome issues. Postman gives you the ability to create scripts for your tests, enabling you to build up some test automation. With that in hand, it’s also a great tool for helping exploration of your APIs–think about the power of combining Postman’s slick interactions with APIs and a test data generation tool like Bug Magnet which generates all sorts of interesting (or evil, depending on your viewpoint) input data.
In the time since I first learned of it several years ago, Postman has exploded in its capabilities. There’s now a significant service offering, a desktop app, and something I find VERY intriguing: service mocking. Service mocking gives you the ability to fake out external services to the component you’re working with. For example, you could simulate calls to a shipping rate service if you’re working with a shopping cart checkout.
Which brings me to the next topic I’m interested in exploring further: Service Mocking
Service Mocking
Testing in real-world, complex environments nearly always means working with service-level dependencies. Few systems live alone–even “monolithic” applications frequently rely on external providers for security, infrastructure provisioning, etc. Service dependencies explode when you’re talking microservices or complex component systems.
How does a team perform effective testing given these dependencies? In part, by simulating or mocking those dependencies.
Service mocking (also called “service virtualization”) enables teams to build up partial services that meet the major use cases so the system can function. For example, you might create a mock for the shipping rate provider mentioned earlier. Instead of building up logic around every possible shipping combination query, you only build up responses for one or two cases–shipping by UPS to Oregon, or USPS to Anchorage, Alaska, eg.
Service mocks aren’t meant to cover all cases. They’re meant to handle just enough so you can get effective testing and coding in place for a particular environment.
This approach enables your team to effectively work with less-than-fully-provisioned environments. Imagine the power of being able to do fairly substantial testing in your lower environments without the extra hassle and overhead of pre-production deployments!
In the past, I’ve written service mocking tools and it’s been painful at the best. Hand-rolling your own service mock means having to spend way too much time on ceremonial things around authentication, HTTP communication, etc.
Thankfully, a wide number of service mocking tools have come on the scene recently. These tools, both commercial and open source, handle all that mess for you, allowing you to rapidly build service responses via recordings or otherwise simple approaches. This means your team is able to focus on the more important aspect: quickly building appropriate mock behaviors instead of writing HTTP headers and JSON by hand.
Six Thinking Hats
My final goal is to dive further into a neat mental tool for looking at problems in different ways: Six Thinking Hats. I was introduced to this concept by my friend Trish Khoo (https://trishkhoo.com) during the EuroStar testing conference some time ago. We were both hanging out at the TestLab playing around with some testing scenario or another, and Trish suggested the Six Thinking Hats as a way to approach the testing problem from new directions.
Edward de Bono came up with Six Thinking Hats to purposely force problem-solvers out of their comfort zone and come up with ideas from different directions. The idea is to metaphorically don, in turn, six different colored hats that represent different directions or ways of thinking.
Wikipedia’s page on Six Thinking Hats gives a great breakdown of the directions:
- Managing (Blue) – what is the subject? what are we thinking about? what is the goal? Can look at the big picture.
- Information (White) – considering purely what information is available, what are the facts?
- Emotions (Red) – intuitive or instinctive gut reactions or statements of emotional feeling (but not any justification)
- Discernment (Black) – logic applied to identify reasons to be cautious and conservative. Practical, realistic.
- Optimistic (Yellow) – logic applied to identify benefits, seeking harmony. Sees the brighter, sunny side of situations.
- Creativity (Green) – statements of provocation and investigation, seeing where a thought goes. Thinks creatively, outside the box,
I don’t use the Six Thinking Hats enough, but when I do I’ve found it helpful to get me out of ruts and assumptions in how I think. I’m a firm believer that the disciplined use of these hats will bring me solid benefits in helping me better look at problem-solving.
Moving Forward
So there you have it. Three things I’m already starting to work on for the next several months. Perhaps you already have some goals for self-improvement? I certainly hope so!
Jim is an Executive Consultant at Pillar Technology where he works with organizations trying to improve their software delivery process. He’s also the owner/principal of Guidepost Systems which lets him engage directly with struggling organizations. He has been in various corners of the IT world since joining the US Air Force in 1982. He’s spent time in LAN/WAN and server management roles in addition to many years helping teams and customers deliver great systems. Jim has worked with organizations ranging from startups to Fortune 10 companies to improve their delivery processes and ship better value to their customers. When not at work you might find Jim in the kitchen with a glass of wine, playing Xbox, hiking with his family, or banished to the garage while trying to practice his guitar.
