Using Mind Maps in Testing

Mind maps are an excellent tool and can be used in a variety of testing activities like requirements analysis, test design, test planning, session reports, measuring test coverage etc. Testing relies heavily on communicating stories about what should be tested, how it should be tested, what are the risky areas and so on. Making this process visual can help testing teams articulate their thoughts & ideas better. Drawing mind maps also makes generating new ideas much easier.

Take a look at the simple “Replace” dialogue box below

Dialogue Box

We can easily create a mind map for testing this functionality using the following steps:

  1. Draw the main theme in the centre.
  2. Draw the module name/features of the application branching out from the main theme.
  3. Draw the sub module/feature branching out from each module/feature.
  4. Add colors to your mind map to make it easier for your brain to group things together.
  5. Write test cases for each feature and sub feature.
  6. Include only testable items in your mind map
  7. Try not to use full sentences in your mind map

Mind Map 1

Some examples for creating exclusive mind maps or creating branches in existing mind maps are:

  • Mind maps for field level validation of all fields on the screen
  • Identify fields that are common to all screens and create a ‘Common Fields’ mind map. Eg. Date Field- this field is the same in all screens
  • Mind maps that include business rules
  • Mind maps for events like Mouse Over, Click etc
  • Mind maps based on Screen Names
  • Mind maps based on Functionality

An example Mind Map for validating a subscription form

Subscription Form Mind Map

Ideas for using mind maps in testing:

  • Mind Map Jamming: All the testing team members read /analyze a particular requirement/feature and create a mind map for it together.
  • Using Mind Maps for Defect/ Execution Summary: Create a mind map of test cases. After execution, you can mark (tick or cross) the mind map as per the Actual Result, thus using it to provide Defect/Execution Summary.
  •  Smoke/Sanity Testing: Create a mind map for all the flows that are to be Smoke tested or Sanity tested.
  • Scope: Create a mind map to show what is in Scope and what is not in Scope.

You can use mind maps anywhere and everywhere! Mind maps exist to make your life easy, so if a mind map is getting too big or complicated try splitting it.  The great thing about mind maps is that all test cases are visible in one view; you don’t need to scroll up and down. This also makes it simpler to add new points whenever you want. Mind maps provide more coverage and the likelihood of missing important points is lesser. You cannot use long detailed sentences in mind maps. Using one word per line improves clarity and understanding. It makes recollection easier. Using single keywords will make your mind maps more powerful and flexible.

 Mindmap testing-final

Mind mapping skills improve over time and with practice your mind maps will become more extensive & wide-ranging. Although, mind maps help you simplify information and make it easily understandable, you must not forget that they are ultimately models and therefore, they may leave out important aspects. So make sure that you question what might be missing from the map and add those things. This is quite simple as all you have to do is add another node to the map!

Satish Tilokchandani | Lead Consultant | Zen Test Labs

The chronicles of a new tester

The general mentality in the software testing industry is ‘Negative thinking is one of the most desired attributes of a software tester’. Ever since my sophomore days I aspired to be a software tester. I wondered if being an optimist would hamper my chances of success in the testing field. Many questions stormed my mind. Some of them were:

1. Does this field belong only to negative thinkers?

2. Is negativity the first criteria to become a software tester?

3. What will be the nature of the teams I work with?

4. Is this profession going to change my attitude?

5. If yes, then what kind of a life am I going to lead?

A lot of times I felt like I was passionate about a profession that did not suit me. Keeping all my apprehensions aside, I continued working towards my goal and left no stone unturned in becoming the tester I dreamt to be.

When I practiced test case writing I would come up with at least 10 negative test cases against 1 or 2 positive test cases. For example, I wrote 30 negative test cases and just 2 positive test cases for a simple ‘Change Password’ scenario. This ratio of 1:15 further increased my ‘positive – negative approach’ dilemma. Eventually, I started to believe that I needed to be more of a negative thinker than a positive thinker.

Determination got me into this field.  I have completed 6 months in an independent testing firm and this period has changed my approach towards testing. Working with vastly experienced people in a positive work environment has answered all my queries.

My new approach is

1. Testing doesn’t belong to negative thinkers at all. It belongs to people who can think along multiple directions.

2. Only people with a positive approach can survive in this field. There is no space for negativity.

3. This profession definitely impacts your behaviour outside office; it enables you to think in a 100 different ways about any situation. You can predict 100 different outcomes of an action or incident. You can come up with a wide range of solutions to any problem. So even if there are changes, they are all good.

When I look back, I wonder, where I went wrong. What made me think that? What caught me off guard?

The answer is -wrong terminology-I got stuck in a game of words!

It is not about 2 positive and 30 negative test cases; it is about 2 valid and 30 invalid test cases I brainstormed in 32 creative ways.

I believe, that the terminology ‘positive’ and ‘negative’ test cases should be refrained since they have a tendency to affect the psychology of testing in a negative way.

For me, in the battle of positive and negative thinking, the winner will always be positive thinking, creative thinking!

Mayank Raj | Trainee Test Analyst | Zen Test Labs

Testing the Mobile Apps explosion

It won’t be long before it becomes A-android, B-Blackberry, C-Cupcake, D-Donut,-E-Éclair, F-Froyo, G-Gingerbread, if anything, they are words that probably half the planets population (approx. 3.2 billion people) is well versed with. Not only that another 700 million would be over the next 3 years! If you haven’t guessed it by now…I am referring to the explosion of mobile devices into our lives.

At the core of this explosion in mobile devices and here I mean smartphones and tablets; is the innovation in the field of processors. With processing speeds of these mobile devices increasing dramatically, the demand from users to run complex applications has also gone up. Business users want to have the ability to manage their personal and professional lives through a single interface and have apps that allow them to do this. Add the speed at which innovation in devices, processors and OS takes place and it is not a pretty picture for app. manufacturers.

So, what does all of this mean to you if you are an App. manufacturer or an enterprise trying to create mobile apps for your workforce or customer base?

Some of the areas of impact include:

  • A constant need to keep your app. updated with the latest OS upgrades/ devices in the market
  • Build high secure applications that lend peace of mind to users/ administrators
  • Build apps. that are not very heavy on the device resources (for optimum performance)
  • Constantly upgrade/ enhance your application to keep users engaged

Roll out apps at a speed which would put Formula 1 drivers to shame! Well, just joking on that last one there but for the ones that work in this space, you know what I mean!

Over the years of managing the Quality Assurance programs of multiple Fortune 500 companies and having setup a Mobile Testing Lab fairly early on within this space, I want to share the basic methodology that can be used to mitigate risks for you when developing/ deploying your mobile apps.

Mobile Configuration Optimization
Choose an optimum no. of configurations to test your app on using statistical techniques like Classification tree, Orthogonal Arrays, etc.
Mobile Test Automation
Automate as much of the core testing as possible right from the get go. We have experienced a reduction between 50-70% in the testing effort while ensuring complete coverage across devices. Automation built in on the right design principles also leads to high reusablity of scripts.
Mobile Performance Testing
A holistic approach to performance testing should cover areas such as volume testing, endurance testing, performance monitoring, soak testing and testing under real time scenarios.

An in depth whitepaper has also been written on Mobile is changing the face of Software Testing.I would love to hear from readers on their learning’s when developing or testing mobile apps. Please feel free to write to me

Amol Akotkar | Test Consultant | Zen test Labs

Reducing dependence on automation engineers to manage test automation!

I have always wondered what would it be to separate test automation and automation engineers. Considering that Test Automation has always been treated as the holy grail of testing! Enterprises that have managed to achieve high levels of automation in the testing process have enhanced productivity exponentially while improving coverage and thus reducing risk. This has translated into automation engineers holding  design approaches close to their heart and controlling scripting tightly. Given this dynamic, the adoptions of test automation have remained low over the years.

Test Automation today has transitioned from a “Record and Playback” mode to a virtually “Scriptless” mode thus enabling rapid on the go Test Automation

It has resulted in enterprises automating testing to be oblivious to tool specific coding thus making automation suites maintainable and resource independent. However, scriptless automation frameworks still have many missing links. For example, most scriptless automation frameworks  demand extensive Business User involvement particularly to test the technology enablement. There is a possibility it takes longer than acceptable time to market. Among many causes for greater time to market, one cause is extensive manual testing of the solution. It hamstrings the time taken to market since there is heavy dependence on business analysts (from business or IT) in QA (test design and execution). There is a strong dependence on skilled & expensive technical resources for automation. There is a need to manage spikes in demand for QA resources which results in increase of QA costs.

Considering these dynamics, the next stage in the evolution of test automation is driving in the direction of Business Process Model based test automation that aims at synchronizing Operations, Product Management and Quality functions.

At Zen Test Labs we are innovating with multiple products in this space. Our flagship test automation framework, ZenFRAME is one such example. ZenFRAME improves BA and business testers productivity while reducing dependence on technology teams by up to 40%. The GUI enables most non-technical users to create automated test cases faster  thus resulting in close to 33% lesser creation time, read our whitepaper to know how you can implement a business Process model for you QA environment. Would love to hear thoughts from everyone…

Ravikiran Indore |Sr Consultant |Zen Test Labs




Top 6 solutions for software testing failures

The cost of software testing is still not valued by its worth. Although it is a critical investment companies avoid spending on testing because they don’t realize the ROI on testing and/or a quantifiable cost of quality. The most common complaints against testing that we repeatedly hear are:

  • It is a necessary evil that stalls a project the closer it gets to a release
  • It is too costly, time consuming without any guaranteed outcome
  • Many a times regression testing is not effective to identify new defects

Having worked on a number of testing projects over the past 12 years, I realize why there is a high tendency to look at testing with such a skeptical eye. I would like to share what we have learnt over time.The top six points in our view to improve the effectiveness of manual testing are:

6. Reducing effort and time in Test Documentation

A lot of teams spend unnecessary time detailing test scenarios during the planning phase which are rarely referred to after 2-3 rounds of testing. This increases maintenance overheads and reduces flexibility and coverage in the long run thus resulting in inefficient testing. Post the initial 6-8 months a large % of test scenarios are outdated and require the same effort in updating. Instead of detailing each and every step for every test scenario, one can cover it with test conditions and the expected results.

5. Focusing on breadth and depth of testing

Many a times when execution is not prioritized the depth of testing takes lead over breadth. By aiming at covering more breadth, we align testing with the business objectives. By doing this the teams aim at being effective first and then efficient. Breadth referring to covering positive  critical cases (across the application) that are frequently used by end user.Depth referring to covering all the test cases for a module.

4. Testing, a continuous activity

Many companies look at testing as a one-time investment. They outsource/ execute in-house once during the start of the development of the product and then rarely test it during the maintenance phases. The primary reason is invariably budget driven and goes onto harm the quality of the product when not tested after newer versions. For every minor release one should ensure all the regression test cases are executed and for every major release all the high and medium priority test cases are executed at least once.

3Remembering the objective of testing

The key objective of testing is to break the system and not to prove that the system works as per the requirements.This has a direct impact and can improve testing effectiveness and the number of defects one will find. It is often observed that many senior testers habitually start proving that system is working as per the requirements which is against the primary objective of testing.

2Strategize Test optimization

Coverage is important but not at cost of redundant test cases. Test optimization is an intelligent way to ensure test coverage in less time. That’s why testing teams need to collaborate more with the development teams. Understanding the high level design and structure of the application makes testing more effective. In development, one of the main principles followed is reuse. So, we can use the same principle while testing the same code which is reused. Why not optimize and test the class/object once and just test the implementation of the class/object on other screens/modules. If the test cases are reusable maintainable and scalable it is an additional advantage to roll out in time and under budget.

1. Focusing on the Business for which you are testing

Testing cannot be done in isolation. Business priorities and challenges are equally and in most of the cases more important than testing needs. One thing I have learnt is that testing cannot drive business decisions, business drives testing most of the times. Aligning testing to the business requirements results in a disciplined and ready to market high quality product.

These are some of the solutions with which I could overcome testing failures. Do share yours if you have new solutions or methods

Mukesh Mulchandani | CTO | ZenTest Labs

Developer + Tester = 1?

Recently I attended a software testing conference where the main focus of discussion revolved around future of testing and how innovation can be ingrained more in testing!

The speakers included Randy Rice, Michael Bolton and Lee Copeland. When asked about the future of testing, and each one said that it was a too dangerous to predict. They realized that when they were asked this question ten years back, their predictions failed thoroughly J  Quoting Neils Bohr “Prediction is very difficult, especially if it’s about the future”.
A common point said by each was that it would be more complex and besides functional testing, security testing would be a major game.

One of the intriguing points I found was in order to enhance creativity,asking the developer to also play tester. I think it is a recipe for disaster to expect a developer to test his baby.

The reasons why the developer and the tester should be different are:

–          The developer works  on building a particular module but the tester has to think of the integrating that part as well, thus varying  the scope and efficiency expected from the tester and the developer

–          The creative process of a developer works on a structured constructing process, where as a tester proves his creativity by breaking the barriers and rules

–          A developer is entitled only to the code and does not work with the mindset of looking for failures, where as a tester whether access to code or no code works towards digging failures

–          However, when a new Functional Specification Document or a Business Specification Document is acquired, the tester and the developer can start working simultaneously, by adopting Agile more productivity and efficiency is attained over a limited period of time.

If I must combine the role of a tester and a developer, then

A developer can enhance his productivity by unit testing, if there is an error in the code it is easier found by the developer rather than a separate tester who might or might not have the knowledge of that technology/language.He can also build by thinking of end to end business flows.

A tester can wear the developer’s shoes by building automated scripts and applying Oops concepts in his test cases.

I believe this would also add in enhancing the innovation in testing! These are my views acquired over dedicating a period of time in testing, Would be great to know yours?

Poonam Rathi |Test Consultant | ZenTest Labs

Software Testing in 2020

As a CEO of a testing company, a question that plays on my mind constantly is ‘what is the future of Testing?’ In the early 2000s, Ron Radice spoke at a QAI conference in India, where he had predicted that testing will die. His call was that automatic code generators will do the job so efficiently that testing will become obsolete. When he looked at the crystal ball then, he could see that prevention will be the creed and not detection.

Well, when I look at 2020, I believe Ron was right as well as wrong. Yes, code generators are arriving. Yes, there will be automated test case generators. Yes, model based testing will replace rudimentary testing activities. But, the whole boom of software especially in ubiquitous mobile devices means only more testing.

If the future includes automated cars like the Google driverless cars, I cannot imagine such a car with a technology that has not been fully and manually validated. If the future is the “Internet of Things”, I can only imagine that the amount of embedded testing will only explode. If the future is, business operations being handled through apps and app stores that have millions of applications pervading every step of our business and personal life then imagine the amount of mobile testing that will be required. If not anything, as everything gets more interconnected, the consequences of a critical failure will only be catastrophic. Wherever the nexus of cloud, social, mobile and big data takes us, I am thoroughly convinced that the need for testing will only grow.

While there a dime a dozen predictions on how things will look in 2020, my two bits around where testing will find itself as follows:

• Huge business opportunities arising from testing for app stores directly than app manufactures
• Test automation would have evolved from script less automation to automatic test case generators and execution
• The pressure to deploy rapidly in the Mobility and embedded devices space will mean that test automation tools will evolve to provide near and real time support to these areas
• Testing and testers will evolve to become super specialized with domain testers at one end and niche technical testers at the other end.

These are some things that come to mind and as the decade continues to evolve. Would be great to know what the rest of the testing world thinks.

Krishna Iyer|CEO|Zen Test Labs

Mobile apps, crash nightmares and testing!

While browsing through a few applications on Google Play market, I came across some interesting apps. However, one app caught my attention over others and on an impulse I purchased it for my brand new phone.

Guess what…the moment I installed the app it crashed! Being a tester, I immediately started analyzing why this happened. My first doubt was whether the testing team performed installation testing. Now while most teams would do some basic installation testing not everyone would have tested it on my device model or different OS versions. Anyway, I somehow got the app to start after resorting to the rudimentary turning on and off the phone.

Once I started using the app, I realized that it was very easy to understanding which told me that the development and design team had a good understanding about user level interfaces such as color scheme, menu style interaction, UI, navigation, etc. The app also had a comprehensive help and support center that was easy to navigate. On accessing the help center I could easily find a solution to my issue and fix it once and for all.

This is where my testing instinct kicked in fully. I started accessing the app using a GPRS connection and observed that the application performance was outstanding. I then ran it on my 3G network and the WiFi at office and found that the performance was consistent. I then started playing with the app to see if it transitioned seamlessly across portrait and landscape modes. I tested the app for a prolonged period of time with interruptions from calls, SMS and music.

However, to my utter dismay the battery consumption of the app was extremely high and I had to run to a charge point! I was pleasantly surprised to see that the app very smoothly transitioned from an active mode to a suspended state and back when I was receiving calls and the phone under charge. My past experiences with some apps in this area were abysmal to say the least!

However, having done such a good job with handling interruptions when calls come the development team completely missed the ads part. Every time I clicked on an ad the app stopped working. Anyway, I got busy with my work in office for the remainder of the week and did not even look at the phone or app (with the app in idle state). I was pleasantly surprised to find that it had been working perfectly in the background provided my phone had enough charge.

How many of you have paid and downloaded apps for your phones but found similar issues with them? Having worked as a tester for some time now, I have found that when app development companies ensure that their testing teams follow a process of this kind to make sure that the end user gets what is expected they win customers!

I continue to apply this approach in my day to day testing of mobile apps and look for ways to improve. Have you recently tested a mobile app and found a process that works for you? Please feel free to share your experiences.

Anuradha Gaidhani

Consultant, Zen Test Labs

Agile testing uncovered…

I have been a part of agile testing for quite some time now and have experienced its edge over the traditional style of testing. Over the years I have seen that most companies shy away from this form of testing for one or a combination of these reasons; i.e., implementation issues, lack of awareness, risk involved or simply just a resistance and hesitance to change. Through my post below I am attempting at assuring readers that agile testing is not only simple and extremely effective but also goes a long way in achieving delight in your testing strategy.

What is Agile testing?

Agile testing likes its development counterpart refers to a concept of breaking down the entire process into small pieces in a bid to achieve results as quickly as possible. Thus, agile testing is nothing but validating requirements in the shortest time possible. Product Owner’s, Scrum Master’s, Agile BA’s, Agile Tester’s, Agile Developer’s, Agile Architect’s, and Agile Resource Managers can all implement this methodology of testing.

Some advantages of Agile Testing

• Ensures time and budget optimization as all phases of SDLC need to be completed quickly.
• Ensures all change requests or enhancements are implemented without budget constraints with minimum impact on time to market
• Ensures good coordination due to daily nature of activities thus determining issues & gaps in requirements in advance with countermeasures deployed rapidly
• Ensures comprehensive testing in situations where business requirements documentation is hard to quantify.
• Ensures that the product delivered is in line with business needs and timeframes.

Some learning’s

• When Agile testing is weaved into a project early in the product development cycle, it ensures that time/ work estimates are accurate thus ensuring that deadlines are met. This is primarily due to the fact that testers are exceptionally good at clarifying requirements and identifying alternative scenarios.
• Deploying Agile testing right at the beginning of projects also ensures that developers write their code to pass tests as the test approach is known well in advance.
• Early stage Agile testing also is an opportunity to bring in automated acceptance testing into the process. This is especially relevant when the development is also in the Agile mode.
• Testers are always one step ahead as they design the cases for upcoming release also, thus enabling developers to pick up at the start of the iteration.

Things to watch out for

• Project quality management is hard to implement and quantify unless the test team are able to conduct regression testing after each release.
• Attrition as always in the development cycle can have an adverse effect on project development.
• In the case that Agile Scrum is being used, it can be the leading cause of scope creep, when not managed properly.

All in all when managed properly, Agile Testing can give most projects the edge in ensuring that ROI on products can be seen much earlier than expected while keeping costs down to a minimum. I would love to write more about my experiences with agile testing but before I do, I would like to hear the views of readers in order to make this a more interactive exchange. How do you view Agile Testing?

Vikram Deshmukh |Senior Manager | Zen Test Labs