Getting started with Ansible

Whether you are a sysadmin looking for a better way to automate deployment of a software or a tester looking to automate installation tests, a configuration management tool such as Ansible is worth exploring!

I have been recently exploring whether to use Ansible Playbooks or Docker containers or both for installation testing. In this blog post, I will give an overview on installing and configuring Ansible on CentOS 7.

Before getting started let me acquaint you with some terminology and concepts that I will use in the later sections of this blog post:

Term	Meaning
Playbook	The configuration management scripts of Ansible are called playbooks. It uses YAML syntax, a simple data serialization language and hence easy to read and write.
Controller machine	The machine where Ansible is installed

I found the setup required for managing a server with Ansible to be quite simple and there is detailed documentation available too.

Installing Ansible

Make sure that the CentOS 7 EPEL repository is installed:

sudo yum install epel-release

Once the repository is installed, install Ansible with yum:

sudo yum install ansible

Configuring Ansible Hosts

Before the controller machine starts communicating to other machines, “hosts” file needs to be made aware of which servers the Ansible needs to keep track of.

Open the file as root:

sudo vi /etc/ansible/hosts

The syntax looks something like this:

[group_name]
alias ansible_ssh_host=your_server_ip

Where,

• group_name = one word tag to refer to any servers listed under it
• alias = name to refer to the server that the controller machine would talk to

Example hosts file

[servers]
Centos7VM ansible_ssh_host=10.255.255.255

Create a file with the same name as group_name in /etc/ansible/group_vars/ to tell Ansible as which user it should connect to the “servers” group.

sudo mkdir /etc/ansible/group_vars

sudo vi /etc/ansible/group_vars/servers

In “servers” file add the following lines

– – –
ansible_ssh_user: root

If you do not already have an SSH key pair (which consists of a public and private key) for the user used by Ansible to connect to the “servers” group, you need to generate one.

On the controller machine as the user, generate a new key pair, by entering the following command:

ssh-keygen

Assuming you are root, you will see output that looks like the following:

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):

You can either accept the file name and path or enter a new name. Next, you will be prompted for a passphrase to secure the key with and you can either enter a passphrase or leave the passphrase blank.

After generating an SSH key pair, copy your public key to your host server by running the ssh-copy-id script and providing your password when prompted

ssh-copy-id <ansible_ssh_user>@<ansible_ssh_host>

Your public key would be now added to the remote user’s .ssh/authorized_keys file.

Tip:

Make sure that the user used by the Ansible on the controller machine to connect to remote hosts exists on the remote system. Otherwise a connection attempt will result in a connection error.

Check whether Ansible has connection to its hosts

You can issue a command of the following syntax

ansible -m ping X

Where, X = single host, group_name or all

Example:

• ansible -m ping Centos7VM
• ansible -m ping servers
• ansible -m ping all

Further reading

For creating a basic Ansible playbook and explore further, see the official intro to Playbooks.

Have fun with Ansible!

Advertisements

Overview of tox

I wanted to run Python unit tests using different Python versions on both Linux and Windows. The unit tests had a lot of dependencies. While looking into quick wins for getting the unit tests running via Buildbot, a continuous integration system, I found the pot of gold – Tox.

What does Tox do?

• Creates a virtual environment for the Python versions you want to run your tests against by using virtualenv.
• In the virtualenv, all the dependencies and packages required for the tests are installed.
• Then the sequence of tests is run in the virtual environments created.

Setup

Setting up tox is very simple. You can install tox with pip install tox or easy_install tox. A config file ‘tox.ini‘ with the information about your project and environments should be created. If you have setup.py, the tox.ini file should reside next to it.

An example tox.ini looks like this:

By running the following command, test.py is run on both Python 2.7 and 2.6.

tox

Learn more about tox configuration and usage examples from the official tox documentation.

Good luck!

Recommended reading:

• Tox tricks and patterns
• Tox documentation

Cambridge Lean Coffee 01/17

Thanks to @redgate for hosting another amazing #leancoffee with @qahiccupps @karostol @chrisg0911 pic.twitter.com/urWEz6fY6g

— sneha bhat (@snehasbhat) January 25, 2017

A couple of days ago, @redgate hosted Cambridge Lean Coffee. Notes from the group I was in are below.

How much is too much testing?

• The discussion started with a suggestion to Michael Bolton’s blog post ‘When Do We Stop a Test?‘
• One of them in the group raised that we should avoid measuring our testing in test cases.
• Many of us stop testing when the allocated budget is over.
• Depends …
  • on the product – medical software may require more testing compared to testing a simple website.
  • on risk, subject, impact, context etc.
• When we run out of ideas or have all the answers to the questions we had in mind before we started exploring.
• Questions such as ‘Can I finish testing?’, ‘Am I expected to finish testing?’ come up when someone asks ‘How much more testing remains?’
• Some people have code coverage as the yardstick.

Lessons learned in software testing

• We have to work with people
• Efficient communication is very important to bridge gap between Dev and Test
• Avoid blame games
• One of them in the group felt that occasionally Testers have to be gatekeepers of the product since the stakeholders are too keen to release.
• Looking at the product for a long time can make one blind to some of the bugs. So it may be wise to talk to the experts once in a while.
• Moving teams within the company can be useful. The way we see and interact with the product can vary. Fresh pair of eyes is always useful.

What strategies do you use to learn when you start at a new company?

• User guide/manual as a map to start exploring
• Request to shadow or pair with others
• Ask for induction meetings if they are not setup to know about different teams
• Find out about the proprietary tools used in the company
• Look at testcases if they exist
• Bug management system can be useful to find which are the risky areas of the product
• Ask a lot of questions
  • maybe in the wiki and request people to contribute answers
  • maybe in scheduled time slots
  • to the domain experts
• Draw architecture diagram of the software, explain what you have understood and ask others to correct your understanding or fill in any gaps
• Mindmaps can surface any inconsistencies in the perceptions of different people which itself is interesting to explore

Legacy test automation framework

• The person who raised this
  • was part of a Scrum team
  • wanted to know how to best deal with improving legacy test automation framework where the team members were not fond of it.
• Discussion revolved around
  • exporting a few tests at a time from the legacy framework to a new framework rather than a bulk move
  • don’t be afraid to delete tests that haven’t been delivering value
  • slow down now to speed up later
    • migrate the tests related to stories worked on in a sprint as part of that sprint itself
    • this can be part of Definition of Done
  • new test framework should be a by-product from the various sprints if the time to work full time on the new test framework is unavailable.
  • in the questioner’s Scrum team if there isn’t an improvements backlog, they could create one and add stories for working on the migration of tests from legacy to a new test framework. They can work towards reducing technical debt.

Communicating your data effectively

Don’t simply show all the data. Instead show the most useful data to make an informed decision.

Image src: http://www.extremeparanormal.org/tag/data-analysis-tool/

As testers we explore. From our explorations we may end up with a lot of data of which only some of them are interesting to be shared. When we are at the point of communicating about our exploration to our audience, we need to figure out

• … what might be noteworthy or interesting to highlight
• … what is that specific thing that needs to be conveyed
• … what context would be essential

Once we figure these out, we need to consider how to

• … show our data in a way that will be easy for our audience to understand.
• … turn our data into useful information that can be used to make a decision

This requires iterating and looking at our data in a number of different ways and choosing an appropriate visual.

I recently read the book Storytelling with Data by Cole Nussbaumer Knaflic (@storywithdata) which is a must read for anyone who wants to get better in communicating about their data. In this blog post, I would like to share the top 3 lessons I took away from the book to apply in my job as a tester.

Lesson 1: Choose an appropriate visual

By considering the tools or resources you have at your disposal create a visual that is easy for the audience to read and take back the key message.

Cole explains with examples about when to use simple text, tables, heat maps or charts since it is very important to choose the right way to display your data.

If your data has only a few interesting numbers to be conveyed a table or graph is not needed. Simple text can be a great way to convey the message. With a few supporting words, the numbers should be made prominent to clearly make your point.

However, when you have more data that you want to show, a table or graph is a better option.

Tables interact with our verbal system which is why we read tables. Therefore,

• tables can be a good option if multiple different units of measure needs to be communicated
• tables can be a bad option to be used in a live presentation

To reduce reader’s cognitive load, color saturation can be used to provide visual cues via a heat map. This would help in finding the potential points of interest quickly.

Graphs interact with our visual system. Therefore, it is faster to process the information from a graph than from a table.

Lesson 2: Keep it simple

To make the important message from your exploration data stand out in your report, any data that isn’t adding enough informative value needs to be removed. Eliminating the unnecessary reduces the cognitive load on the audience. This makes the transmission of the important message to your audience easier.

In the book, Cole introduces the Gestalt Principles of Visual Perception and provides practical examples of how these principles can be leveraged in data visualizations.

Lesson 3: Focus your audience’s attention

Cole demonstrates how to leverage preattentive attributes such as size, colour, added marks, and spacial position

• as visual clues to the audience about what’s important.
• to provide a visual information hierarchy to make it clear to the audience how they should interact with the provided information.

Some of her tips for highlighting the important items are:

• eliminate distractions
• use labelling well
• leverage white space.

 

The above 3 lessons are some of my favorites which I could implement in my workplace straight away. Lessons in the book Storytelling with Data by Cole Nussbaumer Knaflic are very helpful in turning our data into useful information for decision-making. I would highly recommend reading the book for learning about the various creative ways to walk your audience through any specific data message for them to take an informed decision.

References

• Storytelling with Data: A Data Visualization Guide for Business Professionals by Cole Nussbaumer Knaflic

Writing well for quicker and better results

Our ability to write well matters. We write to communicate. And communication is one of the important skills for a software tester. As testers, we write a lot – reporting bugs, interesting stuff about our exploration, summary emails to stakeholders etc.  Effective writing has better chances of achieving results by conveying what we want to say and doing its job clearly and quickly. But writing well can be difficult! It requires skill, understanding and a good deal of creativity. Our writing acts as our ambassador in our absence. And we’re judged on its quality.

Reading requires effort to be invested by the readers. And everyone is busy. Readers may consume only part of the information provided which can cause a lot of confusion and we may not be there to clear the misunderstanding. Reading is hard work! But the effort can be reduced when the writers put some effort towards writing well.

Image courtesy: Microsoft Images

Write for others, not for yourself.

So we may want to consider the following principles to make reading easier:

• Make your point and then support it.
• Make sure your important message is clear and in the right place.
• Construct straightforward sentences.
• Provide structure to the writing.
• Avoid technical jargon where readers may not know it.

So how can we make effective and efficient writing easier?

Writing at workplace can get easier if you think about your goals, put some thought about who your audience is, gather and organize information before constructing an outline.

Think about your goals

All of us may have a temptation to do several things at once: working on what to say, how to say it and in what order. If we reign this temptation, we can avoid following a recipe for disaster. Writing is best tackled systematically similar to cooking.

Make the purpose of the document as specific as possible. From your standpoint consider:

• why is the report being written?
• what is it for?
• what do you want the end result to be after the report is delivered and read?

From the standpoint of readers consider:

• who is the report for?
• is the group homogeneous or are there multiple needs to be met?
• the reasons these people want the report
• what they want (or do not want) in it, and in what detail?
• the result they look for (what they want to understand, what action they want to take, or what decision they want to be able to make).

You know why you are writing the document when you have thought about your goals from both yours and readers standpoint.

Know your audience

Your document could be read by many. Write for the primary readers since you cannot satisfy all the readers. Different readers have different levels of experience, priorities, and expectations. Understand who your primary audience is. By pre-empting questions from them, you can attempt to provide the specifics they would be interested in and save their time by not mixing “nice-to-haves” with the important points to be conveyed in your writing.

Gathering and organizing the information

In order to remember the ideas in your document, the readers naturally begin to group and summarize the ideas when they start reading the document. If we as writers group it ourselves, it makes it easier for the readers. See more about gathering and organizing the information in my blog post “Structuring information as a pyramid”.

Final words ….

Writing well might seem like a lot of effort at first, but it gets better with practice. Well-written documents can save a lot of time down the road since there would be less confusion. Not only will misunderstandings reduce from such a document, there is a higher chance of getting what you wanted from your document done faster. So write what you mean clearly to get what you want quickly.

 

References:

• How to Write Reports and Proposals by Patrick Forsyth
• Improve Your Communication Skills by Alan Barker

The Secrets Behind Great One-on-One Meetings

Swamped by meetings? Cancelling or shortening one-on-ones is not a good idea, as Elizabeth Grace Saunders writes in the Harvard Business Review.

With my recent responsibility of being a line manager, I had started to think about

• How to make the most out of one-on-ones with my direct report?
• How to judge the success of one-on-ones?

One of the books I enjoyed reading is “The Secrets Behind Great One-on-One Meetings” by Esther Schindler. It is only 37 pages long and is packed with useful hints and tips for new line managers.

In chess, all the pieces are not uniform. You need to know how each piece needs to be moved, carefully plan their current and future moves to win. This is contrary to playing checkers where all pieces are uniform, interchangeable and share similar moves. Similarly, each direct report is different. To understand their unique eccentricities and abilities in order to bring the best out of them, personal time with direct reports in a safe setting is crucial. Having one-on-ones provide such an opportunity.

Though, one-to-one is the team member’s meeting, many-a-times the team members

• … may not have anything to discuss
• … may give a quick update of what they have been up to and remain quiet
• … may be overloaded with work and hence unprepared to talk to you during the meeting

If the manager does not facilitate well, the meetings can turn out to be terrible and directionless.

The book has some great suggestions about how to make the most out of one-on-ones by setting up an agenda.  Best one-on-ones help in building an ongoing and fruitful relationship between the manager and direct reports. So I am thinking, why not give this suggestion a try?

Assuming, I try the suggestions from the book, other online articles and valuable advice from other line-managers, it obvious to think – ‘How can I measure my success in one-on-ones?’ The book has a section on that too. If you are eager to get your hands on this book, get it for free from here.

Recommended reading about one-to-one meetings:

• Manager tools
• HBR article – https://hbr.org/2015/03/cancelling-one-on-one-meetings-destroys-your-productivity
• Rob Lambert’s  http://cultivatedmanagement.com/one-to-ones-the-form/

Cambridge Lean Coffee 09/16

Cambridge #leancoffee great discussions again, so worth the time! @snehasbhat @chrisg0911 @markjconstable #testing pic.twitter.com/ZLpS6Np6vR

— Andrew Fraser (@tuxt3r) September 21, 2016

Due to various reasons, it had been a long time that I had attended the Lean Coffee mornings at Cambridge. I was so glad I could make it this time! Lean Coffee was hosted by @DisplayLink this time.

As usual, there were thought provoking discussions some of which I would like to share in this post.

How much pairing/swarming is efficient?

There are several studies that state that it is efficient to pair/swarm to get a story completed in an Agile team. The discussion was about how much pairing is efficient.

In the Scrum team I work, we have found pairing to be helpful during the second iteration of development i.e. bug fixes rather than working on a story together right from the start. Note that Sprint planning is done together as a team.

In our Lean Coffee group we discussed about

• efficiency depending on the kind of people involved in pairing.
• the need to find out what works for your team – some people don’t like to pair during development, introverts don’t like swarming.
• involving testers early on in the development.
• creating your own metrics for measuring efficiency keeping into consideration how to measure over short and long periods.

Strategy documentation in an agile era

Detailed documentation is still created by Companies for their partners and the discussion about its requirement has been a controversial topic to many!

The discussion by the group was around the following areas:

• Is it really a waste of time or is it useful since you get feedback on areas not tested/considered to be tested by partners?
• Documentation can get out of date as soon as its published.
• Possibility of having a wiki doc which can be constantly updated.

Improving tester/personal efficiency

There were 2 different topics in this area which I am combining into one since the discussions weren’t clearly differentiated. The topics were about the themes – how can I as a tester get more efficient? How can I personally get more efficient at work?

• How to measure efficiency – we need a metric of our own
• End of the day we should not have a feeling of ‘didn’t get anything done’
• Are there ways of saying no or taking lesser tasks?
• Reading emails at different points of the day
• Planning next day’s work the day before
• Personal Kanban
• Self retrospectives
• block tasks in the calendar
• Get fresh pair of eyes to check test strategy – mind map sharing
• invite POs – usability
• get help from developers

Performance testing tools for video testing

• No one in the team had experience with this but it was suggested that people in the industry could offer help.

If any of you reading this post have suggestions about good tools to use, please do drop a comment.