TestingAR - The coming of the first MeetUp for Testers in Argentina

Testing Meetup

Hello! How is it going? Today I’d like sharing some awesome news.

As you can see by the post’s title as well as the picture, we have begun working collaboratively with other like-minded professionals towards the making of TestingAR Meetup. It all comes about as the initiative of a group of passionate people who are keen on making a difference, as well as on promoting the creation of a solid community with a meeting place.

Its purpose will rely upon bringing together the community more regularly so that we can share our experiences, success stories, lessons learned, tools employed, methodologies and good practices, among other topics. Furthermore, having a place where we can meet, discuss topics, and grow together will also help in building confidence, as well as strengthening bonds among participants.

Nowadays, we are aiming at holding our very first meetup on February 2016, the date has not been set yet, though it will be available soon. It will be a moment for exchange, so stay tuned for more information.

Last, yet not least!! It will also be the perfect excuse to get together and meet in the flesh with other colleagues, and share some good talks in a relaxed environment.

Information about the event found here: http://www.meetup.com/es/testingAR/

Follow us on Twitter here: https://twitter.com/testingARMeetup

Happy Testers’ Day!

Hello to everyone!

Wow, once again it sure has been quite a long time since we last shared something with the community, and what better day to make a comeback than today?

For those of you who may not know, today it is September, Tuesday the 9th, and that means we are celebrating the International Day of the Software Tester, so if you are engaged in this awesome craft… cheers for you!

Without further ado, and because knowing a little history helps us know and understand where we are, and also, helps us plan where we should head to, we’d like sharing a little history

Happy Testers Day

It dates back to 1947, whilst the team in charge of working on the Mark II computer, which would come as the successor to the ASCC Mark I, shared their discovery of what would become the first report of an error caused by a bug, and in that case, an actual bug. Apparently, the supercomputer had a problem in an electromagnetic relay, and when the problem was investigated, the team came across that the problem was being caused by a moth, its presence in the supercomputer was causing the relay to stay open.

One of the team members, Grace Murray Hopper, Degree in Physics and Mathematics, came across with the moth, and thereafter “reported it” (so to speak) by sticking it with tape on a log referring to it as “bug” to describe the cause of the problem.

On the other hand, if we go to another time in history, we can find that Thomas Alva Edison had used the term “bug” in some of his notes on interference and malfunction. However, it is Grace Murray Hopper who is known as having associated the term for the first time with computers, and having written in the log “First actual case of bug being found”.

Whatever the case, it was our intent wishing all of our colleagues a very happy day!

Planning using mind maps

Hello to everyone! Today we’ll continue with the series of post related to Mind Maps in Testing. Last time we did a kick off describing some areas where the mind maps can be useful. Today it’s time to go deeper in the area of planning using mind maps.

Test Plan

Before we start, what is a test plan? There are tons of definitions on the subject, there are lots of template if you take the time to google it, but our thinking of what should be a test plan is close to The 10 minutes test plan than an ISTQB definition of what should be a test plan.

Some “features” I would like to have in a test plan:

  • Meaning to the team: the test plan should be a living doc, the team should use it, questioning about the approaches we are doing and understand our main goals. If the plan will be stored and will never be used, what’s the purpose of having it in the first place? We don’t like documents or artefacts that we’ll never use; if that is the case, why did we invest time in it instead of learning or doing something more interesting?
  • Dynamic: don’t be afraid to change the scope or approach of testing throughout time. It’s a fact that the product will evolve, the features will undoubtedly evolve, so if we don’t adapt our Test Plan to that reality, what is the objective of having it?
  • A source of understanding for our product goals & strategy: I always tend to talk about the product and not only QA or Testing b/c what we are delivering is a product and the quality is a responsibility of the whole team.
  • It would be nice if our test plan reflects the performed activities not only what we’ll be doing, this approach enforces the goal of “meaning to the team”

How to use Mind Maps to Plan

Using mind maps tools give us some flexibility that are difficult to find using other approaches:

  • Simple to extend/Dynamic: when we are doing any kind of testing activities is simple to add nodes and express that information in a simple way so everyone could easy understand
  • Tree structure: as a mind map is just a tree is simply to map not only testing activities performed as a tester, is simple to convert automation results from XUnit results to a tree in the format of the tool we are using
  • State: there are lots of mind maps tools that allow us to set a state to a node, the states we want to use depends of our context and the way we want to express it but you could for example use to mark activities as: in progress, completed, pass, fail, blocked, etc.
  • Measurements: some tools allow us to attach some custom numbers to nodes, this is great to add information like complexity points to estimate time invested in some areas, number of bugs if we are interested in have a track of the amount of related issues or any other kind of information you want to attach to a node and later aggregate as a result of the testing activities. Remember that a mind map is usually stored as a tree so it’s pretty simple to build a script to get all of this information automatically for us.

We usually use Mindmup for some cases when we need measurements and states. Open Source project is here.

Some simple examples

We want to give you some samples of mind map usage, we don’t like to express as methodology or “best practices” because this depends a lot from your context, goals, testing strategy, etc.

Have a global mind map for the plan

We usually use a single mind map that link other mind maps. A good approach could be have all the related mind maps stored in github and have a script or application that load all the data and build a dashboard; following that approach there is no need to collect data manually ;) Also having all that information in github or any other repository is simple to build a snapshot of what we did in the past and analyse and learn from those experiences.

Describe risks

Mind maps can be used to describe the risks, identify possible problems which must be discussed with the whole team. Having this kind of things expressed in a mind map could be a good approach to optimise your meetings with the team and help them understand potential problems from the beginning. Remember that if we can address this kind of issues from the beginning of the iteration, then it is prone to reduce the likelihood to have problems close to the release time ;)

As a tool to work together with development

Mind maps are great to discuss with development, as soon as we can discuss our ideas and other stakeholders ideas with development the better. There is a high likelihood that the quality of the product is better if development knows what we’ll be looking before they finish the implementation. The cycles between dev & testing will be less if we all are in the same page.

Describe features & bugs addressed

Do not use mind maps only to describe testing scenarios, mind maps is a great tool to describe our ideas regarding a product. Don’t think only about which are the title of the new features, improvements or bug addressed, we can do better than that and start learning and model the reality from day 1.

Describe charters

It’s pretty simple describe charters and group them by feature, area, or whatever you think is best. Later is simple to have a big picture of which are our testing goals and discuss with the team. I found that meetings could be much more productive with a mindmap than a spreadsheet or a regular testing tool. In future posts we’ll share an approach to do exploratory testing using mind maps.

Describe scripted testing

Is pretty straightforward to build suites of scripted testing using mind maps. Also is pretty simple to build plans, add tests to plans, etc. Is much flexible than use tools like testlink that you need to create the test, create a plan, add a plan, create builds, etc. If you need to repeat a plan modified is simple, just copy, paste and modify on the fly, pretty simple right?

Describe automated checking

As we said before, it is simple to map an XUnit report to a mind map tree. If we add just one step to our automation we can have all our testing activities integrated in a single mind map. Building a dashboard with all of this information is incredible useful!

Have separate nodes for different goals

Keep it simple! Build a single testing plan and group each activity in different mind maps linked to the main one. I usually have different nodes for: Risks, Product Analysis, Testing Ideas, Testing Sessions or Threads, Scripted Checks that we usually run before go to production, Automated Scripted Checks, grouping testing sessions per product version. All of those activities/nodes depends of your context! Please share your experiences!

Learn from your practices in future iterations

Having all of this information stored in github give us the flexibility to build in a simple way a snapshot of the result from previous iteration. Using for learn! Analyze which problems did you have in the past, review testing ideas and sessions. Did you have some problem in production? try to detect a pattern of why did happen, keep learning from your practices and your product! The goal is improve our skills and practices as much as posible!

Do you think using mind maps for planning is a good approach? Have you used them before? Share you thoughts and stay tuned with our mind maps in testing series! Next topic to cover will be using mind maps to represent our testing scenarios! Stay tuned!