Author: Ajay Balamurugadas

Are you someone who has heard of mind maps and always wondered what it is? You tried your hand at one and couldn’t figure out how to apply it to your context. You have arrived at the right spot. This article intends to dive deep into mind maps and demonstrate how to use them for software testing. So, free your mind and enjoy the ride.

Let us start with the fundamentals: “What is a mind map”. A mind map is a visual representation of an idea. It has a central node called the parent and all the other nodes are called child nodes. What is the fun of learning about mind maps without a mind map? Here you go.

What is a mind map?

Mind maps have been in existence for many years still they are not as popular as they should be, among the software testing community. The mind maps can be used in almost every stage of a software testing release:

• Requirement Analysis
• Modeling
• Test Design
• Test Execution
• Bug Hunting, Investigation, Analysis
• Test Reporting
• Documentation

Before we dive deep into why one should use mind maps extensively, let us understand the current scenario and why they are ineffective. We, humans, don’t think in lists or a linear manner, yet we linearly document most of our understanding. While brainstorming, not everyone thinks about the same topic at the same time with similar intensity. Our brains are wired to think non-linear and make connections in an instant. Instead of using a format to capture the explosion of ideas, we force our brains to adapt to the format.

For example, if I ask everyone to write down their first three thoughts when they hear the phrase – “Reduce production issues”, I bet that each one will come up with totally different ideas.

As a notetaker, trying to capture all of these ideas in a format like lists or docs will be counterproductive for at least two reasons:

1. It is highly time-consuming to switch sections, edit, think which point will fall under which topic, and also worry about the formatting
   
2. It is limiting for the thinker as well as they need to wait till the notetaker has completed capturing the points conveyed so far.

Compare this with a mind map and as and when the topics are highlighted, it is a matter of just one keypress to create a node and add the point. The notetaker doesn’t slow down the thinker. Formatting, and arranging the nodes is easy, especially with shortcuts.

XMind 8 shortcuts:

Enter – To create a new node

Tab – To create a subnode

Ctrl + C / V – Copy / Paste

Ctrl + S – Save

Ctrl + B – To create a boundary around a node (green rectangle effect)

A Tester’s New Year Resolutions

Mind Map.mov We need to show this as a movie within the article. It is 7 mins long. It could be 1.25x the speed too. 

Let us now focus on how to use mind maps at every phase of software testing with an example from OrangeHRM – Requirements Module.

Requirement Analysis

Analysis of the “Recruitment” Module

As you can observe, a simple paragraph has been dissected and multiple chains of thoughts are captured. We can also link similar thoughts.

Modeling an Application

Modeling Swiggy App

You can learn more about Systematic Product Modeling through this Worqference video – https://www.thetesttribe.com/courses/worqference-2022-15-workshops-recording-bundle/ 

We can use mind maps to model any application, note down its visible features, mark the interdependencies, chart out the data flow, and highlight the interfaces. 

Test Design

We could duplicate the feature map and add test ideas as nodes for the specific feature.

Test Execution

For the same map, we could use it for execution and update the results as shown below

Similarly, mind maps can be used for multiple tasks in testing. 

If you want to analyze all the existing bugs in a project, you could note all the bugs in a mind map, group them and also connect similar bugs.

Common mistakes

Though there are no rules for mind maps, there are a few common mistakes that you can avoid:

• Many nodes
  Instead of having many nodes, group nodes logically.

• Long sentences like this stretch the map and make the map look small
  Ensure that the sentences are divided into two lines.
  
• Add more details than necessary
  Remember that maps are not detailed documents. These are used to help connect the dots quickly. So, use phrases.
  
• Make it bland – no colors, no icons, no images
  Avoid that. It is boring. One can also use colors/icons to differentiate states, status, or any other parameter.
  
• Unbalanced maps – More nodes on one side compared to other
  Move the nodes so that the overall map is not skewed to one side and it looks balanced.
  
• Export in mind map format and not in png/pdf
  This is a classic mind map 101 mistake. People start assuming that the whole world uses mind maps and expects them to open the mind map in the right application. Instead, export the mind map to an image/pdf and share it with others.
  
• No conventions used
  Start using the legend and keep all nodes consistent with the overall conventions.
  

Useful Tips and Tricks

• Create a central node, Press Insert & Enter
• Create outline on paper first
• Learn shortcuts
• Save regularly or switch ‘Autosave’ on
• Try to fit the map on a single page
• Use Multi-line sentences
• Use themes and maintain consistency
• Keep practicing

Common Tools

There are many tools available on Desktops, the web, mobile, and tablets. Here are some of them:

1. XMind
   My favorite is XMind 8 even though there are the latest versions like XMind 2020 with features like Pitch, and Zen Mode.
   
2. MindMup
   
3. Novamind
   
4. MindMeister
   

Conclusion

Once you start using mind maps, you will love them and enjoy the freedom of thinking and note-taking simultaneously. You will save a lot of time, and effort and collaborate effectively. There are multiple resources created by the community. Get inspired and inspire the community.

This post is a guest blog by Ajay Balamurugadas. We’d like to thank him for contributing yet another informative piece for The Test Tribe. You can connect with Ajay at :

• LinkedIn
• Twitter
• Link

As much as we don’t want to split software testing into manual and automation testing, it makes sense to start with those terms, explain why testing is testing and then discuss the benefits of combining manual and automation testing. In other words, how to balance testing with and without tools.

What is Manual Testing?

Typical definitions are on the lines of – A type of testing usually done without any tools for executing the test scripts. The test design, execution and reporting is all done manually – without any tools. If we look at the dictionary for the meaning of manual: it means relating to, or involving the hands.

Activities of Software Testing

Any software tester knows that software testing is not a hands-only or physical activity. It is more mental, thinking than physical tasks. Before we talk about use or lack of tools in manual testing, let us consider some of the key activities in software testing.

Tools and Manual Testing

Communication, analysis, collaboration, modeling, test design, test data generation, test execution, bug hunting, reporting, investigation, test reporting, documentation and note taking and more. Now think about how many of these activities are manual or hands-only work. If you think we don’t use any tools for these activities, we need to dig deep into what we classify as a tool. 

• Is Google Doc a tool? 
• Is Find > Replace All an automated or manual activity? 
• Using a formula to calculate the sum in Excel automation? 
• Removing duplicates using ‘Remove Duplicates’ in Excel a manual or automated activity?

The way we have classified automation seems to be on the basis of how the scripts are executed. Even then the test scripts don’t get written automatically, configured automatically, evaluated automatically, and the reports analyzed automatically.

Automation in Testing

Instead of differentiating testing as manual and automated testing, it makes more sense to let “testing” be the superset and highlight those activities which are heavily tool dependent as “tool-assisted testing” or use “automation in testing”.

Combining Automation and Manual Testing

The industry is at a strange stage right now. The majority of the testing industry still believes in manual and automated testing. You would appear to have landed from a different planet when you go ahead and explain the real meaning of testing and automation in testing. Nevertheless, there are multiple camps of testers who call themselves manual testers and ready to move to automation testing. There is the other camp which prides itself in automating most of its testing. 

Here are some actionable tips to find a sweet spot and combine the best of both the worlds.

Test Data Generation

Once you identify the type of tests to be conducted, you can use automation to help generate different sets of test data. Let us consider an example of testing a form with multiple fields.

We have username and password fields as text fields. 

Username and Password:

• Valid
  • Minimum characters
  • Maximum characters
  • R2L characters
  • Existing username
  • With Diacritics
• Invalid
  • Not satisfying the conditions (Ex: no space between characters)
  • Less than minimum or more than maximum

One could generate the users one by one without using any tool or use automation/test data generators to create the data.

Sample output from a test data generator is as follows:

Mockaroo – Test data generator

Partial output from Mockaroo

If you observe the data carefully, the variety is missing. This is where the tester has to step in and strengthen the test data.

Another example is when there are multiple conditions to be tested and you apply the pairwise testing technique to see if there are any bugs caused by a combination of two variables.

Pairwise Online Tool

Output of Pairwise Online Tool

Automation doesn’t understand that ‘Coupon, Address, Gift Wrap’ don’t make sense when you are adding a product to a wishlist. This is how you combine the power of automation and human skills to save time and avoid waste.

Long Duration Test Execution

There are certain bugs that might appear on prolonged usage of the software. During the short release cycles and execution across builds, it is difficult to execute such tests. Using automation, one could dedicate a certain environment and machine for this long duration test – which would help simulate a user behavior and act as a net for such bugs.

Automate the exhaustive tests

In one of the contests, James Bach demonstrated how he used automation (tiny script) to go through all the products and download the details to a file. There were 500+ products and doing the same exercise without any tools could be highly time consuming and error prone. 

Automate the mocks

There are certain applications and use cases which are heavily reliant on state transitions. Everytime you need to test a certain scenario, the prerequisites need to be in place. You cannot refund an order unless it is placed. So, if you need to test a refund, it is not ideal to start from scratch, place the order and then go test the refund. Think if automation can be used to set up the application’s state ready for your tests. It should not just have the products in the respective states but also update the DB so that the next actions have a realistic effect overall. 

Automate the sanity or regression test suite

Based on the product maturity and release feasibility, can automation complete the other tests? If yes, pick the right set of cases to automate – be it the sanity suite or the stable features. If the value gained by automation results helps the testers focus on other critical tests, it is a win-win situation. The key is to use automation to maximize the power of machines to assist humans in testing.

The teams that don’t leverage automation fall behind others. At the same time, the teams that blindly treat automation to be auto-magic also suffer. The trick is to conduct a quick automation feasibility and automate the activities (and not just tests) that will free up the testers for more productive activities. 

Summing Up

To summarize, list out all the activities the teams are involved in. For each activity, see if automation can help. If needed, divide the main task into sub-tasks. Once the tasks, sub-tasks are identified, automate them. Continuously evaluate the costs-benefits and see the value add for the testing team.

This post is a guest blog by Ajay Balamurugadas. We’d like to thank him for contributing yet another informative piece for The Test Tribe. You can connect with Ajay at :

• LinkedIn
• Twitter
• Link

We are fortunate that no one can decide the right career path for us. Picking the right career path is as contextual as picking the next offer letter. Let us explore why it is such a personal decision. To understand more, we will have to dive deep into the history of software testing. 

Don’t worry, we will start with the 21st century, i.e., 2001. Most of the teams were still following the waterfall model of testing; releases were a few months long, and there were specific teams for development and testing. Fast forward to 2023, and we have a wide range of projects; some finish within weeks; there are no testing teams in some projects; and most of the teams are following their own version of agile methodology.

In these 20+ years, we saw a few new roles in software testing as career paths emerge, like SDET. It was never as popular as it is now in the 2010s. While there were testers performing the kind of testing required for the project, we had very few dedicated roles like performance testers, security testers, and accessibility testers. Time has evolved, and the job market is now flooded with unique roles. 

At the end of the day, while the decision is to be made by the tester, we can touch upon a few software testing skills and questions that might assist you in picking the right role and the right career path in testing.

Different Software Testing Career Roles 

Talking about the different roles, here are some with a brief explanation:

• Individual Contributor

Mostly a full time position, this person is expected to be hands-on and fulfilling the daily responsibilities. It could be on any quality criteria – functionality, automation, security, usability, performance, accessibility, usability and so on. You could be working on only web, mobile, API, desktop or all of them depending on the team size and the company expectations. 

• Lead or Manager

You might be expected to lead the project, provide guidance to the team, and be hands-on as necessary. You will be dedicated to one big project or 2-3 small or medium projects.

• Architect

Your specialization is in system design, design patterns, architecture patterns, assisting multiple projects and helping build frameworks from scratch. You will be the go-to person for any technical challenges in the projects.

• Consultant

Mostly a contract role, you will be hired for specific skills for a limited duration. It could be to fill the domain gap within the team or to strengthen the existing teams. You might be paid higher than a full time employee but without the benefits of a full-time employment like PF, leaves, insurance and so on.

Now talking about the company’s career path, each company has its own set of designations for its employees. The following are some broad designations:

• Associate Test Engineer
• Test Engineer
• Senior Test Engineer
• Test Lead
• Senior Test Lead
• Manager
• Senior Manager
• Management

Remember that startups might hand over your desired designation much quicker than an enterprise. 

Testing Roles Based on Skills

There are some roles specific to the skills one possesses:

• Functional Testers: 

These testers are strong in functional testing skills, participate in the testing cycles from the beginning, spend time understanding the requirements, designing test ideas as cases, scenarios or checklists, executing them, filing bugs, investigating them and finally submitting the test reports highlighting the tests done, test coverage and their view of the overall product quality.

• Automation Engineers: 

These testers are skilled in programming languages, tools used to automate the products (Web, Mobile) through different layers (UI, API, Data) using open source or commercial tools. They either help in regression testing or end-to-end testing. Sometimes, the automation can be used for generating test data and for quick validation as well. 

• Product Owner (or Business Analyst):

With some experience in testing or development, we have seen multiple folks move towards the product development side. They are good at understanding the user and business and arriving at features for user delight and business growth.

• DevOps Engineers

Testers who have the skill sets with pipelines and tools useful in deployment slowly seem to transition towards DevOps roles and help both the testing and development teams.

As highlighted in the diagram above, there can be a number of possible combinations.

While we have discussed the designations, roles, and skills, a number of software testing career paths are based on quality criteria.

Apart from functionality and automation, many testers have carved out their careers as specialists in security testing, usability testing, accessibility testing, and performance testing. 

Each of the quality criteria has a lot of potential for anyone to dive deep and become a specialist. You can always start with the fundamentals, gain experience, move on to the intermediate levels, and later work on the advanced stuff. 

One could also become a scrum master and facilitate releases across teams. There are a few other software testing career opportunities for those who have the PMP certification which creates opportunities for project managers. You could also be a delivery manager without any certification and be accountable for project releases.

There are some interesting paths to discover as well. You can be an evangelist for a product, a trainer on multiple topics, conduct workshops, and, in some cases, go ahead and start your own communities and companies. You could provide testing services, be a freelancer, or gain money by being a content producer through articles, blogs, videos, books, and so on.

The possibilities are ample. It is up to each one of us to decide which path will suit us. The fundamentals remain the same: get very good at the skills and keep progressing. No path is easier than another. 

Some paths may pay more, but there will be thousands of others competing with you on the same path. Some paths are so niche that they don’t pay you much, but the opportunities might be more secure. Also, remember that none of the paths prevents you from choosing another path in your software testing career. The trends are changing rapidly. As long as you are able to add value to your role, demonstrate continuous learning abilities, and get work done, your future will be bright. With every choice, remember the trade-offs too. 

So, here is a concluding list of guide words to help you decide your career path

• Learning opportunity
• Industry trends
• Longevity of the skill
• Financial aspirations
• Work pressure
• Interests
• Skills
• Experience
• Competition

This post is a guest blog by Ajay Balamurugadas. We’d like to thank him for contributing yet another informative piece for The Test Tribe. You can connect with Ajay at :

• LinkedIn
• Twitter
• Link

Products are getting complex with time and release times are getting equally shorter. The tolerance for bugs and poor quality has decreased significantly, largely due to the abundance of software products. You name a category, and there are at least 50 companies working towards it, however niche you might think of it being. The competition forces everyone to optimize their time, effort, and resources even more than before. People don’t want to rework; they want the best quality from the start. So, before we dive deep into testing a product, a comprehensive sanity testing strategy acts as a much needed checkpoint in the release cycle.

In this blog:

• What is a Sanity Test?
• Objective of A Sanity Test
• Sanity Testing Checklist
  • Systematic Product Modeling
  • Understanding The Users
  • Take Help of Heuristics
  • Keep It Up-to-Date
  • Lean Documentation to the Rescue
  • Complement with the Regression Strategy
• Building a Sanity and Regression Test Suite Together
• Common Mistakes to Avoid in Your Sanity Testing Strategy
• Conclusion

What is a Sanity Test?

It is a subset of the exhaustive list of tests that you could perform on your application. This is the set usually executed first most of the time. Based on the results, the exhaustive list of tests could be picked up for execution or the build be rejected. Does it sound similar to a smoke test? In some cases, yes. Every company and team has its own definition. So, work with what your context demands and justifies a test to be a sanity test.

Objective of a Sanity Test

A strong sanity test suite helps everyone understand the health of a product, and based on the results, we can then decide whether to spend more time testing it or reject it. The objective of a sanity test should be to confirm that the following types of functions are working fine:

• The main use case of the product
• Customer facing features
• Most critical features
• Most used features
• Features promised in the specific release
• No blockers in overall application (tricky ask)

We have seen multiple testers spend a lot of time testing multiple features and reporting many bugs; they forget to test for sanity. That is a risky approach. You never know if those bugs are a consequence of the few failing smoke tests.

Sanity Testing Checklist

Let us look at the checklist for creating a comprehensive sanity testing strategy:

1. Systematic Product Modeling

As soon as you receive a product to test, spend a few hours playing with the product. Go through every feature systematically to understand how the feature behaves. Figure out how the feature is interacting with other features. Pay attention to the defaults and the error information. Any information about the product now is worth its weight in gold. This helps create a mental model of the entire product under test. If you are wondering how this is related to a sanity testing strategy, let me explain. The more we know about the product, the stronger our tests will be. If our knowledge of the product is shallow or limited, we would be scratching the surface. We would be getting a false hope that we have tested the sanity but we would have left many features unexplored. There cannot be a bigger risk than that.

Following figure illustrates an example of partial understanding of the product. The functionality marked red might not be discovered till we dive deep into the product. If the sanity test suite is not updated frequently, it might be on the regression suite but never get on the sanity suite. The overlapping circles denote interacting features. So, by performing a systematic product modeling, we understand the scope of the product first. With this understanding, we will now be able to find the right tests for the sanity suite. Check out this course to learn more about systematic product modeling: Link

2. Understanding The Users

While every user is unique, you can group them by behavior or personas. Once we understand the types of users and their typical usage patterns, we can design our testing strategy accordingly. If your users hardly use the website and are mostly on the app, it makes more sense to test the app more than the web. Taking help of the analytics, we can also focus on the most critical flows in our sanity suite. Some teams dive too deep into certain features and as the sanity suite is too large now, they ignore the other features. If you want to have comprehensive coverage, pay attention to all the features equally. Spending some time with the support team also helps in understanding the calls made by the users and which flows are trending. 

3. Take Help of Heuristics 

A heuristic is a fallible way of solving a problem. When we don’t know how to solve a problem, heuristics can help us, though they are not guaranteed to solve the problem. There are multiple heuristics like SFDIPOT, RCRCRC and FEW HICCUPS to assist in testing software. These can help in creating a robust sanity suite.
For example, RCRCRC stands for
R: Recent
C: Core
R: Risk
C: Configuration
R: Repaired
C: Chronic
Using this heuristic, one can design both the sanity and regression suites.

4. Keep It Up-to-Date

A bigger mistake than not having a sanity suite is to not update it often. When the features get updated, bug-fixes change the previous implementation, some features get deprioritized, it is time to update the tests too. Some of the features mature with time and there are not many changes to those features as well. With time, the sanity test suite might bloat and try to trim the suite as well. The purpose of every test in the suite is to find a bug. If the test doesn’t give you the confidence of finding a bug, remove or update it with a more powerful test.

5. Lean Documentation to the Rescue

In one of the projects, the sanity suite itself took 2 hours and the overall regression suite took 2 days. Teams need quick information on whether to reject or accept the build. In some contexts, 2 hours is a lot of time. Keep it lean. See if the sanity testing checklists, guidewords, mind maps work well compared to the test cases, guide words and scenarios. Having lean documentation helps in easy review, update and execution.

6. Complement with the Regression Strategy

Having a case in the sanity suite for a feature but no more cases in the regression suite doesn’t help. While there is rarely a need to repeat a case in both the sanity and regression suite, it is important to have both the suites complementary. Based on the results of the sanity suite results, the order of execution in the regression suite can be modified.

Building a Sanity and Regression Test Suite Together

Let us take an example to describe both the sanity and regression test suite for the ‘Increase font size’ feature in Google Docs.

Sanity Test:

This could be answered by the question – What is that one thing this feature is expected to do without fail in most of the cases?

The answer would be: “Increase font size” when you select some text and click on this option or use the shortcut to enable it. And that becomes the sanity test!

Regression Test:
Every test that one can think of as important in the context of the product’s release. A few examples of test ideas are as follows:

• Does the font increase for
  • A single letter
  • A symbol
  • A word
  • Multiple words
  • Multiple sentences
  • Multiple paragraphs
  • The whole multi-page document
• Can we have different font sizes for the different sections of the document
• Will undo, redo work with the font size changes
• What is the max limit till which the font size can be increased
• What is the increment in which increase/decrease font size work
• Is the increment consistent for all kinds of text
• Will the setting be preserved during printing

and so on.

Common Mistakes to Avoid in Your Sanity Testing Strategy 

Also, beware of the following mistakes in creating a sanity suite

• Not covering all the features
• Either being too shallow or too deep, both not helping the purpose of a sanity suite
• Not using automation if there is a possibility to automate the suite
• Ignoring the analytics and keeping the suite static
• Not taking the sanity results seriously

Summing Up:

Once we have a comprehensive sanity suite, we can expect key gains in productivity as teams don’t spend a lot of time testing the buggy build. The sanity suite acts as a strong gatekeeper. It is easy to implement and needs discipline to maintain it as a strong suite.

This post is a guest blog by Ajay Balamurugadas. We’d like to thank him for contributing yet another informative piece for The Test Tribe. You can connect with Ajay at :

• LinkedIn
• Twitter
• Link