Five People and Their Thoughts (Part 6)

Some engaging articles I’d like to share today:

  • The Failures of ‘Intro to TDD’ (by Justin Searls, about classic test-driven development, code katas, what TDD’s primary benefit actually is, mocks, and discovery testing)
  • Branching is Easy. So? Git-flow Is Not Agile (by Camille Fournier, on Git, tooling, teams, developing software with agility, how easy it is to create feature branches with Git, and some reasons why you don’t need it)
  • What’s Wrong With Estimates? (by Yorgos Saslis, about estimates, why we are being asked to provide estimates, and the pitfalls of the ways we are using them)
  • A New Social Contract for Open Source (by Eran Hammer, on open-source, free code but paid time, sponsorship, making clear rules and specifying benefits, and sustainability)
  • Introducing Example Mapping (by Matt Wynne, about conversations to clarify and confirm acceptance criteria, feedback, colored index cards, and the benefits of writing examples when exploring a problem domain)
Advertisements

Exposing Local Apps Publicly with Ngrok

Here’s a screenshot of something we’ve currently been working on:

It’s not available publicly yet, because it’s still in the early stages of development. The app, hosted locally on http://aspen.reservations.com/#/stay-dates, will redirect to a 404 page unless you have the app installed in your machine. As a programmer, the changes I’m making on the app is only accessible on my local computer. Other programmers will only be able to view the changes I’ve made if I push said changes and they download those updates on their machines.

Similarly, I’ll be redirected to an error page if I view the said app on my phone:

What if a tester or a product owner requests an impromptu demo of the app? What if they want to test it as is? Early constructive feedback is always nice. We can set up the app on their machine, but what if they’re working remotely? I’m pretty sure it would be a pain for them to install the development environment on their own. And what if they want to test it on their mobile phone? Having the environment installed on their computer doesn’t mean they can test the app on an actual phone.

Apparently there’s Ngrok. It’s a quick solution to publicly sharing local apps over the internet.

Here’s a screenshot of me trying out the free version:

And now I can test the app on my phone!

No installations needed on the tester / product owner / client side, just a single bash command from the programmer instead. So cool!

 

Bumping Into Discovery Testing

Until recently, what I mostly knew about test-driven development was the concept of red-green-refactor, unit testing application code while building them from the bottom-up. Likewise, I also thought that mocking was only all about mocks, fakes, stubs, and spies, tools that assist us in faking integrations so we can focus on what we really need to test. Apparently there is so much more to TDD and mocks that many programmers do not put into use.

Justin Searls calls it discovery testing. It’s a practice that’s attempts to help us build carefully-designed features with focus, confidence, and mindfulness, in a top-down approach. It breaks feature stories down into smaller problems right from the very beginning and forces programmers to slow down a little bit, enough for them to be more thoughtful about the high-level design. It uses test doubles to guide the design, which shapes up a source tree of collaborators and logical leaf nodes as development go. It favors rewrites over refactors, and helps us become aware of nasty redundant coverage with our tests.

And it categorizes TDD as a soft skill, rather than a technical skill.

He talks about it in more depth in a series of videos, building Conway’s Game of Life (in Java) as a coding exercise. He’s also talked about how we are often using mocks the wrong way, and shared insight on how we can write programs better.

Discover testing is fascinating, and has a lot of great points going for it. I feel that it takes the concept of red-green-refactor further and drives long-term maintainable software right from the start. I want to be good at it eventually, and I know I’d initially have to practice it long enough to see how much actual impact it has.

Favorite Talks from Agile Testing Days 2017

There are two things that’s wonderful from last year’s Agile Testing Days conference talks: content focusing on other valuable stuff for testers and teams (not automation), and having as many women speakers as there are men. I hope they continue on with that trend.

Here’s a list of my favourite talks from said conference (enjoy!):

  • How To Tell People They Failed and Make Them Feel Great (by Liz Keogh, about Cynefin, our innate dislike of uncertainty and love of making things predictable, putting safety nets and allowing for failure, learning reviews, letting people change themselves, building robust probes, and making it a habit to come from a place of care)
  • Pivotal Moments (by Janet Gregory, on living in a dairy farm, volunteering, traveling, toastmasters, Lisa Crispin, Mary Poppindieck and going on adventures, sharing failures and taking help, and reflecting on pivotal moments)
  • Owning Our Narrative (by Angie Jones, on the history of the music industry so far, the changes in environment, tools, and business models musicians have had to go through so survive, and embracing changes and finding ways to fulfil our roles as software testers)
  • Learning Through Osmosis (by Maaret Pyhäjärvi, on mob programming and osmosis,  creating safe spaces to facilitate learning, and the power of changing some of our beliefs and behaviour)
  • There and Back Again: A Hobbit’s/Developer’s/Tester’s Journey (by Pete Walen, on how software was built in the old days, how testing and programming broke up into silos, and a challenge for both parties to go back at excelling at each other’s skills and teaming up
  • 10 Behaviours of Effective Agile Teams (by Rob Lambert, about shipping software and customer service, becoming a more effective employee, behaviours, and communicating well)

Takeaways from Dale Carnegie’s “How To Win Friends and Influence People”

Dale Carnegie’s “How to Win Friends and Influence People” is a classic, and I did not understand what that meant until now, after reading the book. It has survived the test of time, and the lessons in it still applies to all of us today. It really is a treasure trove of actionable advice about forging friendships and leading people, and I’ve come to see why some of my way of doing things have worked for me all this time. Better, I’ve found places where I could use more practice and improve.

Here are some favourite lines from the book:

  • Let’s realise that criticisms are like homing pigeons. They always return home. Let’s realise that the person we are going to correct and condemn will probably justify himself or herself, and condemn us in return.
  • There is only one way under high heaven to get anybody to do anything. And that us by making the other person want to do it. The only way I can get you to do anything is giving you what you want.
  • We nourish the bodies of our children and friends and employees, but how seldom do we nourish their self-esteem? We provide them with roast beef and tomatoes to build energy, but we neglect to give them kind words of appreciation that would sing in their memories for years like the music of the morning stars.
  • If there is any secret to success, it likes in the ability to get the other person’s point of view and see things from that person’s angle as well as your own.
  • Keep in your mind on the great and splendid things you would like to do, and then, as the days go gliding away, you will find yourself unconsciously seizing upon the opportunities that are required for the fulfilment of your desire. Picture in your mind the able, earnest, useful person you desire to be, and the thought you hold is hourly transforming you into that particular individual.
  • He had wanted merely a friendly, sympathetic listener to whom he could unburden himself. That’s what we all want when we are in trouble. That is frequently all the irritated customer wants, and the dissatisfied employee or the hurt friend.
  • So if you aspire to be a good conversationalist, be an attentive listener. To be interesting, be interested. Ask questions that other persons will enjoy answering. Encourage them to talk about themselves and their accomplishments. Remember that the people you are talking to are a hundred times more interested in themselves and their wants and problems than they are in you and your problems.
  • Anyone who takes the time to disagree with you is interested in the same things you are. Think of them as people who really want to help you, and you may turn your opponents to friends.
  • You can tell people they are wrong by a look or an intonation or a gesture just as eloquently as you can in words – and if you tell them they are wrong, do you make them want to agree with you? Never! For you have struck a direct blow at their intelligence, judgment, pride, and self-respect. That will make them want to strike back. But it will never make them want to change their minds. You may then hurl at them all the logic of a Plato or an Immanuel Kant, but you will not alter their opinions, for you have hurt their feelings.
  • If you are going to prove anything, don’t let anybody know it. Do it so subtly, so adroitly, that no one will feel that you are doing it. You cannot teach a man anything; you can only help him to find it within himself.
  • I am convinced now that nothing good is accomplished and a lot of damage can be done if you tell a person straight out that he or she is wrong. You only succeed in stripping that person of self-dignity and making yourself an unwelcome part of any discussion.
  • If a man’s heart is rankling with discord and ill feeling toward you, you can’t win him to your way of thinking with all the logic in Christendom. Scolding parents and domineering bosses and husbands and nagging wives ought to realize that people don’t want to change their minds. They can’t be forced or driven to agree with you or me. But they may be possibly led to, if we are gentle and friendly, ever so gentle and ever so friendly.
  • No one likes to feel that he or she is being sold something or told to do a thing. We much prefer to feel that we are buying of our own accord or acting on our own ideas. We like to be consulted about our wishes, our wants, our thoughts.
  • What do you think he found to be the most motivating factor – the one facet of the jobs that was most stimulating? Money? Good working conditions? Fringe benefits? No – not any of those. The one major factor that motivated people was the work itself. If the work was exciting and interesting, the worker looked forward to doing it and was motivated to do a good job.
  • This is what every successful person loves: the game. The chance for self-expression. The chance to prove his or her worth, to excel, to win. That is what makes foot-races, and hog-calling, and pie-eating contests. The desire to excel. The desire for a feeling of importance.
  • He always gave people the opportunity to do things themselves; he never told his assistants to do things; he let them do them, let them learn from their mistakes. A technique like that makes it easy for a person to correct errors. A technique like that saves a person’s pride and gives him or her a feeling of importance. It encourages cooperation instead of rebellion.
  • If you want to improve a person in a certain aspect, act as though that particular trait were already one of his or her outstanding characteristics. Assume a virtue, if you have it not. Assume and state openly that other people have the virtue you want them to develop. Give them a fine reputation to live up to, and they will make prodigious efforts rather than see you disillusioned.
  • Tell your child, your spouse, or your employee that he or she is stupid or dumb at a certain thing, has no gift for it, and is doing it all wrong, and you have destroyed almost every incentive to try to improve. But use the opposite technique – be liberal with your encouragement, make the thing seem easy to do, let the other person know that you have faith in his ability to do it, that he has an undeveloped flair for it – and he will practice until the dawn comes in the window in order to excel.
  • It isn’t what you have or who you are or where you are or what you are doing that makes you happy or unhappy. It is what you think about it. There is nothing either good or bad, but thinking makes it so.

Five People and Their Thoughts (Part 5)

It’s been a while since I’ve shared interesting articles and recordings about topics surrounding software development and testing.

Here are a few videos, for the curious:

  • Continuous Delivery – Sound’s Great But It Won’t Work Here (by Jez Humble, about continuous delivery, the excuses organizations tell people when they fail to implement it, and what those excuses actually mean)
  • There and Back Again – A Hobbit / Developer / Tester’s Journey (by Pete Walen, on how software was built in the old days, how testing and programming broke up into silos, and a challenge for both parties to go back at excelling at each other’s skills and teaming up)
  • Feature Injection (by Chris Matts, about business analysts and tea bags, understanding that requirements are just dependencies, and finding out where the value is in requested features by asking for examples)
  • A Day of Mob Programming (by Woody Zuill, on mob programming, and how taking a whole team approach to coding can help us align and build better software together)
  • Testability vs Automatability (by Alan Richardson, about the differences between testability and automatability, what each term actually mean, and recognizing how specific words can help people tell stories better or not)

6 Curious New Tools to Try for Writing Automated Checks for Browser Apps

While I don’t find myself writing a lot of browser-based automated checks these days, I still am on the look out for interesting new tools in that space. The reason: the new tool solves an existing problem I have with setting up such a testing suite from scratch or provides a solution for certain curious use cases I’ve never experienced before. While using Ruby and Watir together in writing tests running through the browser for me is sufficient for common tasks, such a new tool could be a better fit for another project.

Here’s a list of such tools that popped up in my feed in recent months:

  • Cypress. What I like about Cypress, aside from the standalone package installation option and the built-in pretty test report page, is that the pre-defined browser tests that the actual team runs on its own site is included out-of-the-box. This way they made it easy for me to write custom tests; I just had to search for an example of what I wanted to do, copy-pasted it to my own test, and updated the parts that needed changing. Tests are written in Javascript. I have yet to try running the tests via the terminal though, which is important when running tests on a CI server. Using their test runner is free for all projects, however there is a pricing plan for using their dashboard service which helps keep test recordings private.
  • Katalon Studio. This is a full-blown automation solution that is completely free. There’s a pricing plan for business support services. The record-and-playback feature built-in to the tool failed to impress me when I ran it through our legacy apps, but perhaps writing the actual test code through their GUI fares better (using which there will be a high learning curve for people like me who like to use the CLI and personally-configured IDEs).
  • PuppeteerBuild to control Google’s headless Chrome or Chromium browser, running over the DevTools protocol. Tests are written in Javascript. Easy to try and get into using their web playground. Alister Scott has tried it running with Mocha and Circle CI on a demo project.
  • Chromeless. Similar to Puppeteer, but built to automate an army of Chrome browsers running in parallel. It gives us the option to run tests on AWS Lamba too. Again, tests are written in Javascript, which we can try on their demo playground.
  • Laravel Dusk. This gives PHP developers familiar with Laravel the ability to write and run their own browser app tests, using a programming language they’re much accustomed to.
  • Appraise. Similar to BackstopJS, a tool for visually validating browsers apps. Tests are written in Markdown.