ALM Query: Test cases and steps in a folder

I didn’t quite expect to be using ALM. But anyways, putting my notes here just in case I ever have to revisit this again.

  1. Download and install the connectivity tool from ALM Tools.
  2. In Dashboard > Analysis view, add a New Excel Report.
  3. Using the Query Builder, figure out the query you can use.
  4. Generate the report.

Query: Test cases and test steps under a folder

You’ll need to search ALL_LISTS for the corresponding folder so that you can specify the correct one in the WHERE condition. It doesn’t preserve the folder tree structure though.

SELECT
  TEST.TS_SUBJECT,
  ALL_LISTS.AL_DESCRIPTION as "Folder Name",
  TEST.TS_TEST_ID as "Test ID",
  TEST.TS_NAME as "Test Name",
  TEST.TS_DESCRIPTION as "Test Description",
  DESSTEPS.DS_STEP_ORDER as "Step Order",
  DESSTEPS.DS_STEP_NAME as "Step Name",
  DESSTEPS.DS_DESCRIPTION as "Step Description",
  DESSTEPS.DS_EXPECTED as "Expected Results",
  TEST.TS_RESPONSIBLE as "Designer"
FROM TEST
  JOIN ALL_LISTS on TEST.TS_SUBJECT = ALL_LISTS.AL_ITEM_ID
  JOIN DESSTEPS on TEST.TS_TEST_ID=DESSTEPS.DS_TEST_ID
WHERE All_LISTS.AL_ABSOLUTE_PATH like'AAAAAPAAGBCIAAAAAAAAAAAC%'
ORDER BY TEST.TS_SUBJECT, TEST.TS_TEST_ID, DESSTEPS.DS_STEP_ORDER

Read: War and Peace and IT

I got this book, War and Peace and IT by Mark Schwartz for $0 at Amazon.com. I think IT Revolution was holding some promotions which is how I got it for free back then so I was spared from shelling out $12.99. I bought it last May, but didn’t come around to actually opening it until this June.

We had a rocky start. The author pretending to be Napoleon Bonaparte in the Foreword section was something I found a bit too corny for my taste. So that made me put off reading it for a few more days or so. When I eventually reopened the book, I reached the section in the introduction sharing who the book is for.

Not me:

  • CEO
  • CFO
  • non-IT CXO
  • CIO or IT leader
  • Any category of business leader

And finally me: “For others in the business and IT community”

So mmmkay, I’m definitely not the main audience for this. I read it anyways. And it actually wasn’t so bad after I got over those hurdles. What I particularly like is that there’s a chapter summarizing suggested actions. So if you’re looking for one chapter to read in the whole book, go for Chapter 10: “Action Plan”.


I’ve listed out some bullet points from Chapter 10 below. For the full context though, you’ll still need to read the book. But at least this can give a starting point on whether you find the suggestions interesting enough to push through with checking out the $12.99 book.

Tie IT initiatives to business outcomes.

  • Choose a few objectives for trial.
  • Assign each to a cross-functional business/IT team that is fully empowered to execute.
  • Use impact mapping to brainstorm with the team.
  • Remove impediments.
  • Review progress often and make adjustments.
  • Celebrate success.

Shorten lead times.

  • Emphasize urgency and fast delivery.
  • Your goal is not to make people work faster or harder, but to improve workflow. Make that clear.
  • Take advantage of the cloud.
  • Ask IT to speed up the portion of delivery that is technical. This will probably involve implementing DevOps, creating reusable components, and designing secure “landing zones” in which new work can safely be done.
  • Find bureaucracy that isn’t adding value or that could be made leaner with Occam’s turkey carver. Often this includes sign-offs required from people who have no good basis for making the sign-off decision, forms that ask for unnecessary information, or controls that could be automated.
  • Becoming lean means reducing calendar time. Wait time, for example, should be eliminated, even though no effort is being spent.
  • Task switching is a source of waste and defects. Organize work so that everyone can focus. You can make this easier by keeping tasks small so they can be finished quickly.

Emphasize delivery and results.

  • Ensure that work is organized into very small units, work toward minimum viable products, and experiment to learn and test ideas.
  • Monitor results starting immediately.
  • Remove organizational impediments that resist quick shipping.
  • It may be easier to begin “working small” by modifying an existing system.
  • “Shipping” means that people start using the product. Prototypes and demos aren’t shipping (although they might be valuable steps on the way).
  • Don’t be afraid of disruption from shipping quickly. The idea is that by shipping quickly and frequently, each shipment is very small, and is consequently low-risk.

Treat requirements as hypotheses.

  • Read the Side Glance on humility! [this is another chapter in the book]
  • Question assumptions by asking how they can be tested.
  • It’s better to put effort into testing an idea than to risk not testing it.
  • A/B testing (where some users are shown version A, some version B, then the results are compared) is very effective and might be easy to set up.
  • Be sure that the test subjects are the same people who will be using the product—not, for example, managers or people within the product team.

A culture can’t turn ideas into innovations

I was skimming through some of my old notes when I came across this line:

Without reciprocity, in both deeds and resourcing, a culture can’t turn ideas into innovations.

And I thought of how there’s always a call to innovate at work. There’s always an invitation for new ideas. There’s always a call for change.

But it’s one thing to ask, and another to deliver. I’m a firm believer that you can’t just say something and that alone will will it to happen. There’s got to be some intentionality. If you want something done, you have to create space for it, you have to make time for it, you have to allow for it to happen. Because, physics, I guess. I don’t know how else to explain that going from A to B requires actually going from A to B. Hmmm… maybe logic.

Anyways, I’m putting in here some of my other notes relating to that quote and to creating the space for work or change to happen.


From “Innovation for the Fatigued (2019)”

The core tenet is if you want more innovation, give people what they need in order to innovate.

  • Make responses mandatory
  • Promote givers — In order to build a culture of reciprocity, leaders need to look for the givers of the organization, the people who are always ready to help with comments or support for ideas, and look to promote for generosity. The more givers you have in top management, the easier it will be to build respect and reflection.
  • Twin demands with support — You cannot develop innovation in an organization by simply demanding more and more of it. … make sure that demands are always reciprocated with support – be this allotted time, material resources and/or encouragement.
  • Punish indifference

Without reciprocity, in both deeds and resourcing, a culture can’t turn ideas into innovations.

From “It Doesn’t Have to Be Crazy at Work (2018)”

Reasonable expectations are out the window with whatever it takes. So you know you’re going to grossly underestimate the difficulty and complexity required to make it happen.

…Rather than demand whatever it takes, we ask, What will it take? That’s an invitation to a conversation. One where we can discuss strategy, make tradeoffs, make cuts, come up with a simpler approach all together, or even decide it’s not worth it after all.

From “Fast Times (2020)”

Having bold aspirations matters, but only when also matched by corresponding commitment. Without allocating funds and resources at sufficient scale over enough time, the value of digital will remain a mirage—promising but forever out of reach.

From “Brave New Work (2019)”

Creating space also means making time for change. Because most teams simply don’t have it.

One of the most self-destructive tendencies within teams is to get so busy that we believe there’s no time to get better at how we work

Continuous improvement is not magic; it is a discipline. It is a thing we do. And like all valuable things, it takes time. The average team doesn’t spend even thirty minutes a week reflecting on how they work together. They are going to need your help to stop this pattern and clear a path. Because we can’t learn if there’s no time to think. Teams need time for retrospection. They need time for personal reflection. They need time for deep work. They need time to run experiments and find a better way.

From “Full Metal Alchemist” (Anime)

Humankind cannot gain anything without first giving something in return. To obtain, something of equal value must be lost. That is Alchemy’s first law of Equivalent Exchange. In those days, we really believed that to be the world’s one and only truth.


There’s not going to be a shortage of material that supports the idea that it takes action to make change happen. Magic would be cool but most of us are muggles.

Things that make me go “Ooooh”

One is how it got decided that “ooh” should have two O’s. I haven’t even started yet and I’ve already digressed.

I decided to add a new category for things that make me go “Ooooh” — just stuff that I find interesting wherein I actually reacted with a long ooh. I’m not sure if I’ll post enough stuff under this category since even if I find something that fits here, it might not coincide with my availability to write about it. But I’ll see how it goes. No harm if I do or if I don’t anyways.

So, first post in this category is this one: A culture can’t turn ideas into innovations.

Read: Team Topologies

The book Team Topologies: Organizing Business and Technology Teams for Fast Flow by Matthew Skelton and Manuel Pais (2019) has been in my reading backlog for some time. It’s just a title I see frequently in the Guilds (CoP), and also in Twitter since I follow IT Revolution (its publisher).

Lately though I’ve been hearing a lot of terms like cognitive load, enabling teams, DevEx, etc. to the point that I didn’t want to misinterpret and, more so, I didn’t want to misuse them. So I figured I might as well go to the source, and get the book out of my backlog.

It’s essentially an organizational design book, and conveniently at the concluding chapter they have steps on how to get started with team topologies. They also have this illustration which tries to wrap up the core ideas and it’s literally captioned “Core Ideas of Team Topologies”.

I feel like a whole lot of it is centered around reducing the team cognitive load. Which seems to make sense: too many things to do, too many things to focus on, too many people to talk too, too many things to juggle — these can all slow teams down. But at the same time, you just can’t drop stuff arbitrarily, your team has commitments to meet and there’d be gaps. The book provides a sort of model for (re)organizing teams to help narrow things down in the hopes of making teams go faster.

There are examples in the book that I’ve confirmed through experience. Like how teams can go much faster when they’re smaller or when you break down the silos to form a cross-functional team. I see how it works to have certain teams focus on project work, while some teams are there to support those project teams. I see the challenge (or maybe the conflict) of having teams meant to support project teams also be expected to deliver in their own projects.

There are ideas that are dangerous to take at face value. Like if you just read “restrict unnecessary communication” or “limit cognitive load.” There’s so much context given in the book about it that if you only take it at face value, then you risk limiting communications (the wrong ones) that are essential for the teams to accomplish their goals.

There’s a lot to sift through. I feel my actual notes have gotten quite lengthy (this blog post is a far cry from my notes) and I definitely want to go over them again. Overall, I think I’d still put Brave New Work above this. Both have a lot of ideas to draw suggestions from, but what Team Topologies has over BNW is that it’s very specific to IT teams which is right up my alley.

Cognitive Load

You might have recently come across the term “cognitive load” (or if not, now you have) being thrown around lately. While I haven’t really read about it, I have a sort of guess of what it is but initially in the context of usability. Ages ago, I read this book entitled Don’t Make Me Think and what I got from it is the idea that the design or the implementation of a certain functionality has to be made in such a way that it is as intuitive as possible. When the design is incoherent with its purpose, that makes you think — and unnecessarily so — somewhere along the lines of “why?” or worse “WTH?” and that contributes to why a certain screen is not so usable.

Beyond usability, the idea sort of still applies.

When something feels like it lacks clarity, it’s incoherent, it doesn’t seem to make sense, it doesn’t seem to add up… those things make us think. Instead of being able to focus on moving forward or on the thing that we have to do, a part of our brain is stuck at trying to make sense out of things. So that to me is the sort of “cognitive load” that we need less of. It’s like brain activity that doesn’t get us to where we want to go any faster.

Now I can’t just be throwing around the term without at least trying to learn more about it. Just sharing this quick 20-minute YouTube video (around 12 minutes if you skip the Q&A) that gives a short and easy-to-understand explanation on it in the context of managing information overload.

A quick summary that they provide:

“We constantly need to learn. But there are limits on our ability to learn. Cognitive load theory can help us work within those limits giving us a set of guiding principles. If we manage intrinsic load by breaking large tasks into smaller ones, reduce extraneous (irrelevant) load by eliminating irrelevant tasks and distractions, and increase relevant (germane) load with appropriate repetition and varied learning context, we promote efficient learning, improve productivity and escape the horrors of info overload.”

A simple story of Nobody

This was something I picked up from high school (or maybe even grade school). I think it stuck because I was fascinated with the wordplay and its having a strong message contained in it even though it was so short and simple. The story goes (just that one paragraph that follows):

This is a story about four people named Everybody, Somebody, Anybody and Nobody. There was an important job to be done and Everybody was asked to do it. Nobody knew Everybody wouldn’t do it. Everybody was sure Somebody would do it. Anybody could have done it, but Nobody did it. In the end, Everybody blamed Somebody when Nobody did what Anybody could have done.

I find that you can take it in different contexts — at work, for some chore at home, in society — and it still works. And it’s a sad story when nobody does what somebody or everybody should be doing.

The only thing necessary for the triumph of evil is for good men to do nothing.

Lessons from Leadership is Language on Feedback

That title couldn’t be any more explicit. I spoke with a colleague who shared a challenging situation she’s in. After our talk, I couldn’t help myself from thinking what if I were in that situation and had to be the one to make that difficult conversation. I also took it as an opportunity to revisit what I read about from Leadership is Language by L. David Marquet, and relate aspects or lessons from the book on to the context of giving feedback. Of course, I can’t share the exact examples here, but I tried to give close enough explanations.


Give information, Not instructions

  • Instead of saying “You should do this or that,” try to provide the information that would reasonably lead to that suggestion (or maybe even better suggestions from them).

Focus on behavior, Not characteristics

People will have better control over their behaviors, than on characteristics they have.

  • Instead of saying “You’re an ineffective ______________,” try citing the specific behaviors that led to the idea that they’re an ineffective whatever.
  • Same when it’s positive. Instead of saying “You’re a great team member,” say the behaviors that you’d like to be repeated.

On the process, Not the person

While I think asking one’s self “How can I be a better <insert role here>” is good for introspection, asking that to another person might not always be taken positively. I think we are naturally defensive and we can’t expect everyone to be consciously going against that natural tendency. Asking “How can you be a better leader?” might somehow be misinterpreted as “You’re not a good leader, you suck, you really need to improve…”

  • Instead of asking that, shift focus on certain processes. Say that person’s responsibility includes owning say the peer review process, then instead of asking “How can you be a better peer reviewer,” ask “How can we improve on the peer review process,” “What do you think can we try to better track the peer review comments,” etc.

Observe, Not judge

I think this ties up with the previous items on focusing on behaviors and giving information. By trying to take a non-judgmental stance, ideally we get to show that we are not condemning the person, that we are open to working with the person to address the objective information provided.

  • Instead of (judging the person) “You wrote that report poorly,” or (judging the work) “That report is poorly written,” provide the observations instead “I noticed three spelling errors in the report”.

I just reused the example from the book here. With that example, it feels easier, clearer or more achievable to address the “three spelling errors” compared to a poorly written report.

On achieving excellence, Not avoiding errors

I think asking how to avoid errors is a fair question to ask because that is something you want to achieve. This also works well for me for introspection. But related to what I mentioned previously, asking that can be taken negatively even if you don’t mean it to be. “How can you avoid so-and-so” might come across as rubbing salt to the wound or might feel like the focus is on what the other person is doing wrong.

  • Instead of asking “Why do you keep on missing those bugs” (which also feels accusatory and it’s often not the case that people intentionally try to miss bugs), ask “What do you think can we try to find those bugs sooner?”
  • Instead of asking “How can your outputs be less buggy,” ask “What do you think are we missing in our process so that we can get things right in fewer reviews as possible?”

In writing about this, I have had a little more time to think about it. But the challenge I guess is making these conscious word choices on-the-fly or when the situation unexpectedly calls for it.

Read: Think Like a Rocket Scientist

I could see why this book has nearly a five-star rating in Amazon. I pretty much enjoyed it and I finished it sooner than I was planning to (which means trouble for me if I end up buying another book this month). Maybe I’m also a bit hung over from watching Star Trek (Picard and Enterprise) so I enjoyed the mention of “interplanetary” in a nonfiction book far more than what might be normal. Overall, I liked the anecdotes and the tips that didn’t feel too abstract (i.e., another way of saying they didn’t make me do a lot of head tilts with an accompanying “Whut?!”).

As usual, I’m posting my notes for my future self, and for whoever is interested enough to check this out. The book is by Ozan Varol, and the title is Think Like a Rocket Scientist: Simple Strategies You Can Use to Make Giant Leaps in Work and Life.


Stage One: Launch

  • Chapter 1: Flying in the Face of Uncertainty
    • “Our ability to make the most out of uncertainty is what creates the most potential value.” In uncertainty lies opportunities. Also it’s inevitable. One way to safeguard ourselves is through backups and buffers (redundancies and margins of safety). It’s important to just get started–even with unknowns–you’ll figure it out as you go along.
  • Chapter 2: Reasoning from First Principles
    • First-principles thinking is “systematically doubting everything you can possibly doubt, until you’re left with unquestionable truths.” This involves challenging assumptions and invisible rules. How it always has been done doesn’t mean it’s the only way it should continue.
  • Chapter 3: A Mind at Play
    • This is about curiosity, allowing our minds to explore, and applying combinatory play–“exposing yourself to a motley coalition of ideas, seeing the similar in the dissimilar, and combining and recombining apples and oranges into a brand-new fruit.” Allowing your mind to be exposed, together with exposure to diverse things and people–these lead to diverse and more creative ideas.
  • Chapter 4: Moonshot Thinking
    • Dare to have moonshot ideas. Exercise your mind through divergent thinking, imagining what a science-fiction solution would look like. The other half of it though is convergence, pragmatism, and backcasting to realize that moonshot idea.

Stage Two: Accelerate

  • Chapter 5: What If We Sent Two Rovers Instead of One?
    • Important to differentiate between strategy and tactics. Maybe the problem you’re trying to solve is tactical rather than strategic, or you’re trying to solve the wrong problem.
      • “A strategy is a plan for achieving an objective. Tactics, in contrast, are the actions you take to implement the strategy.”
    • Some tactics to try when solving a problem:
      • Against the Einstellung effect, look beyond the default answer
      • Think beyond the question to ask what’s the real problem
      • Against functional fixedness, look beyond the default uses of the thing or tool, separate function from the form
      • Try the reverse or a different angle or approach
  • Chapter 6: The Power of Flip-Flopping
    • Be open to being wrong. You can change your mind. Ask what am I missing? Challenge your own working hypotheses. “Our goal should be to find what’s right—not to be right.”
  • Chapter 7: Test as You Fly, Fly as You Test

Stage Three: Achieve

  • Chapter 8: Nothing Succeeds Like Failure
    • “It’s as dangerous to celebrate failure as it is to demonize it… A moratorium on failure is a moratorium on progress.” Instead of fail fast, it should be learn fast. Instead of sweeping them under the rug, document failures (or the lessons) so you can use that as a reference.
  • Chapter 9: Nothing Fails Like Success
    • The danger in success is that it can cause people to feel too complacent. When we succeed, there’s a tendency to overlook the near misses, bad decisions, failures that we went through along the way. Without addressing them, “The bad decisions and the dangers will continue into the future, and the success we once experienced will someday elude us. Foster a never-complacent mindset. “You have to disrupt yourself or others will do it for you.” And similarly, “If you’re not humble, life will visit humbleness upon you.” Regardless of outcomes, do a retro (or postmortem).

Epilogue

I close with a quote from the book which in turn is a nested quote of Jeff Bezos: “In every annual letter to Amazon shareholders, Jeff Bezos includes the same cryptic line: “It remains Day 1.” After repeating this mantra for a few decades, Bezos was asked what Day 2 would look like. He replied,”

“Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death. And that is why it is always Day 1.”

Unexpected section on testing

I was just at Chapter 7 of Think Like a Rocket Scientist, and that section was literally about testing. And of course, I couldn’t help but draw parallels or find links of what he said to software testing.

“The test must run forward to shed light on uncertainty, rather than run backward to confirm preconceptions.”
>>> Tests are for finding information, not just to confirm positive test cases, but also to see what happens with negative test cases.

“Experiments on Earth must mimic, to the greatest extent possible, the same conditions in flight.”
>>> This hinted at the importance of having our test environments closely resembling our prod environments.

“The best way to determine an object’s breaking point is to break it… This objective requires exposing every component, down to the screws, to the same type of shocks, vibrations, and extreme temperatures awaiting them in space.”
>>> It initially sounded like stress testing to me. And with the mention of components, down to the screws, made me think of unit tests and integration tests.

“It’s not enough to test the reliability of individual components. Without systems-level testing, you can unwittingly unleash Frankenstein’s monster.”
>>> What he said.

“When you make a last-minute change to a product and ship it out the door without retesting the whole thing, you’re risking disaster.”
>>> This just shouted impact analysis and regression testing to me.

“Instead of creating artificial testing environments disconnected from reality, we’re better off observing customer behavior in real life.”
>>> This, and one of the other anecdotes, reminded me of User Testing and A/B Testing.

“Treat your testing instruments like your investments and diversify them. If you’re building a website, test it using different browsers and different computers.”
>>> Again, what he said, nothing to add there.