Mind maps are a wonderful way to provide a graphical, visual representation of information to organize your thoughts and testing approaches. They can be helpful in so many ways including brainstorming sessions, laying out solutions for a problem, note taking, documenting test ideas, and defining goals. I first learn about mind mapping and testing from Darren McMillan – click here for his website. I use them to help organize my testing ideas, test strategies, and research projects. As I am testing I need to know what has been tested, what larger problems remain, and what risks have not been addressed. They can be a great alternative to a written test strategy or test plan document when a lean approach is appropriate. If using a collaborate tool such as mindmeister, multiple testers can update the same mind map. When using a desk top application, a mind map can be copied and sent to several testers so they can update it for their assigned testing.
When creating a mind map, it starts from the center of the document and branches out with cascading lines forming relationships through descriptive words, symbols, and colors. It can be created using paper and pencil. However, developing a mind map using software allows it to become a living document where information can be added, removed, and updated. I often start a mind map and if it gets too large I make a copy to break it out into several maps.
Mind Mapping Software
To get started with creating a mind map, download a free version such as X-Mind, FreeMind, or FreePlane. Mindmeister is another option, which is an online service with a basic free subscription allowing up to 3 free mind maps storing the data in the cloud. For a small monthly fee you can create more than 3 maps and collaborate with other testers. It is wonderful for distributed teams where you can be in different timezones but yet updating the same map. Mindmeister provide applications for the iPad, iPhone, and Android. I use mindmeister and love being able to access my maps regardless of my location. It can be helpful to test a few of the free mind mapping tools to compare ease of use and supported features. For example, X-Mind provides different templates such as: project planning and flowcharting. Once you better understand how you will use a mind mapping tool, you can identify your requirements to review paid products. Or you might find the free tools meet your testing needs.
A Brief History of MindMapping Techniques
Some sources indicate mind mapping techniques, using pictorial methods to document information, have been used for hundreds of years. In recent history, the concept of MindMapping became popular through Dr. Alan Collins, Ross Quilian, and Tony Buzan. During the 1960’s Dr. Alan Collins, considered the Father of Modern Mapping, published extensive research on graphical thinking and learning. Many consider Dr. Collins and Ross Quilian as the ones who shaped the future of mind mapping.
During the late 1960’s Tony Buzan, British psychologist, made the modern mind mapping popular through: defining a set of ten-rules, creating a name for the approach, and registering it as a trademark. To learn more about Tony refer to his website which includes a MindMap to navigate through his website. His MindMap is created through iMindMap and there is a download to a free basic version on the website.
MindMap Example for My Research
Below is an example of a mind map I created to organize my research about learning more about the history of mind mapping and how I might use it in testing. FreeMind was used for this example providing an overview of several ways to organize information. Major topics were identified that includes: Overview of Mind Mapping; Brief History; and Applying to Testing. Additional nodes were created to further define each section. This visual representation of the research became a living document to help track progress, capture research links, and add new information.
To organize the order of these topics a numbering system is used. Other methods would be to rearrange the order of the nodes by physically moving them. The red arrows represent a link to a website. The links are usable through the actual mind map and exporting it as HTML, which presents the nodes and links in an outline format. This is a great way to link your research within your mind map providing a central location for your information. You can add notes to your nodes to provide more details.
Symbols are a quick way to measure your project’s progress. A check mark can be used to identify research that was found to be beneficial or a task that is completed. A red “X” can define articles that were not helpful and will not be used a reference tool or testing ideas that were not performed. A pencil can identify areas that require more research or work.
For purpose of this example, I provided a few more symbols to show how you might use them to visually document information. The light bulb represents “ideas”; paper with pencil represents “refine”; spaceship is “launch”; and magnifying glass is “to be discussed”. There are a lot more symbols and approaches that can be used to create and maintain the mind map. Take some time to explore the functionality provided by the various mind mapping software packages and how you can use it. When creating a map you could add a node as a symbol legend so readers will easily know how you are using each symbol.
Stay tuned as I will be adding more postings discussing mind maps providing different examples on how you might use them in your testing. If you are using mind maps I would be interested in hearing how you find them beneficial.
I am a researcher by heart and I wanted to share a few links on tools and research that may interest you.
History of Mind Mapping: click here
Who Invented Mind Mapping? click here
Mind Map: click here
Theory behind Mind Maps: click here
Tony Buzan: click here
High Five: Five Best Mind Mapping Applications: click here
11 Free Mind Mapping Applications & Web Services: click here
Photo courtesy of Amazon.
As the subtitle of this book indicates “26 Engagement Strategies for Busy Managers”. It is a great reference for any manager, supervisor, or team leader. I do not have time to read every book cover to cover. I tend to purchase books that I can use as a reference tool. This book provides engagement and retention strategies from A through Z. As an example, chapter 13 is: Mentor Be One. It is not a structured mentoring program that you might find through your HR department, but guidelines that anyone can use right now. The authors define Mentor as:
Model what you want your employees to do.
Encourage and support your people during the good times and bad.
Nurture their ideas, relationships, and them!
Teach or tell it like it is. Help them avoid those
Organizational minefields that are never written about in any policy manual
The authors spend several pages on discussing their mentoring model that you can use immediately. Many of the chapters have exercises, worksheets, examples, and to do lists to summarize each chapter. It is an easy book to read and most likely you will not read it cover to cover. I would recommend that you select one chapter and take some time to work through the material. This is a hands-on book that works best if you work through the exercises and then adapt them to your environment. The recommendations can apply to any department as employee retention is important for all businesses. The material will get you started but is not in-depth. If you were looking to introduce a structured mentoring program in your organization this book would not guide you through all the steps. But if you are looking for a few ideas and a starting point, then this is a good book. If you know someone who has recently been promoted to a managerial position, consider providing her with a copy. For those who have been in management for many years, can still find value with the tips and suggestions.
You can purchase this book through Amazon.
Picture courtesy of Amazon.
I started my career working in Human Resources as a Compensation Analyst. As part of that job I did my own programming in order to analyze wage data to make recommendations on competitive pay practices. In that role I also wrote job descriptions and worked closely with the recruiters since I needed to understand the job responsibilities in order to price a job. I did not realize how much that knowledge would be helpful as a manager when I needed to write job descriptions and recruit. From my Masters in Strategic Leadership I conducted a research project on onboarding and training new employees.
Many people will not have my background so I was happy when I read Johanna Rothman’s book “Hiring Geeks That Fit”. She does a wonderful job in laying out a recruitment strategy from the initial planning of the skills and responsibilities required of the new employee through ensuring you have an onboarding and training plan when they start. Remember the first day is critical because you want your new employee to go home happy that she joined your department!
Johanna provides a lot of templates and valuable examples to get you started. You can easily adapt them to the position you are recruiting. Even though I have a lot of experience in the areas covered in her book, whenever I am recruiting I pull out my Kindle and skim through this book. I always pick up a few ideas and it helps challenge my thinking. In particular I like the idea of providing a recruitment focus to each person on the interview team. Too many times when we recruit we send in several people to interview and they all ask similar questions. With a bit of planning we can do a better job in the questions we ask to evaluate the candidate’s fit and to provide her with more information on the job. Recruitment is a two-way road. Not only are we interviewing the candidate but she is also interviewing us to determine if our company and job is a good fit.
Regardless if you have a lot of experience in hiring employees or you are a new manager and this is your first hire – you need to get a copy of this book! For those who are new to recruitment, I recommend you read it from cover to cover and go through the exercises. They are important in helping you understand what skills you really need and to bridge that information to your interview team. If you are not the hiring manager but are part of an interview team, I do believe you will find value from this book in framing questions and evaluating the candidates. For those of us who have done a lot of hiring this a great reference book.
You can find Johanna’s book on Amazon.
Most testers have experienced the problem of needing to break testing mindsets to develop new testing ideas. Mindsets are basically traps we fall into such as testing the same keystrokes and solving problems using the same strategy. Making bad assumptions is another trap that can stop the tester from asking more questions or approaching the problem differently. Such as assuming something is not important to the client because it is a small feature. Over time, mindsets can become roadblocks to testing as we find less bugs believing the product is becoming more stable when in reality there are still bugs but we are not finding them. It is important for all testers to challenge how they approach testing.
We should learn from every mistake or lost testing opportunity by reflecting upon what we could have done differently in order to identify personalized learning buckets. Use this information to find new ways of testing in order to break those testing mindsets. Develop relationships with stakeholders to dive more deeply into the testing assignment to ask more questions and identify different ways to test. Continue to think outside the box by identifying what constrains or limits testing. Most importantly, always keep learning; challenge your skills; and never become complacent as a tester.
Identify Learning Buckets
Learn from missed bugs or new features not tested correctly to develop lessons learned to understand how the feature could have been tested and how that information might have been identified during testing. It is helpful to segment this information into personalized learning buckets. For example: training on the company’s product; knowledge on how the customer uses the product; deeper relationships with stakeholders; and problem-solving skills. Also identify the type of assumptions being made during testing. Through these learning buckets, identify strategies to improve testing skills in order to start removing testing roadblocks.
It may not be possible to learn everything about the product; therefore, identify the subject-matter experts that can review the testing strategy to determine if anything is missing. Prior to meeting with the subject-matter expert, gather and review any requirement documents, training material, or other documentation provided to outline testing ideas and questions. This can help bridge both product and customer knowledge which can be brought into testing.
Identify the assumptions being made and then challenge those assumptions to determine if the testing approach changes. Do the assumptions have a pattern? For example, assuming a feature is not important because no one indicated its importance. Assumptions can become dangerous traps and over time may be filed away and not addressed during testing. For example, not having the test data to perform specific tests may have been acceptable in the past but as the feature evolves that assumption may no longer be correct. Identify old assumptions that no longer apply because the product or customer needs have changed. Whenever making an assumption, stop to identify the facts to determine if additional information or communication is required. When in doubt have a conversation with someone (ie., subject-matter expert, a test lead, developer) to review concerns and questions.
Think Outside the Testing Box
Identify what prevents or limits testing ideas and strategies. For example, a requirement document can be helpful in understanding intended functionality; however, how does it limit testing? Is this document being used as a checklist to perform testing within the box or is it being used to foster conversations with subject-matter experts on intended functionality to generate testing ideas that go beyond the written documentation. When reviewing the learning buckets, is one of them: “I did not test that because it was not in the requirement document.” If the answer is yes, then the requirement document is becoming a roadblock in generating testing ideas.
Is the testing based upon test cases that are providing diminishing-returns? If test cases are required, how can they be changed to become more fluid to avoid retesting the same key strokes, parameters, or test data? Consider rewriting test cases into testing ideas providing guidelines but not specific steps to test a feature.
Problem Solving Skills
Play games that require identifying different approaches to solve a problem. If you can, play them with friends to share and compare strategies to identify other ways of thinking through a problem. Identify your typical thinking patterns and understand how others are addressing the same problem differently. What can be learned from these differences to start removing testing barriers?
To prepare for testing, some testers will translate the functional requirements to formal test cases defining the input and expected output in order to cover different types of tests such as: positive, negative, and boundary. Test cases can be time consuming to write and maintain plus will not always provide the flexibility to introduce different testing scenarios. Over time the test cases can provide diminishing returns since we may be retesting the same keystrokes whereas exploring different testing paths provides an opportunity to find new bugs.
Testers can perform exploratory testing to explore areas of the application they feel may be at risk. At times a more structured approach is needed to help the tester organize her testing to ensure they adequately cover the features while providing the flexibility of exploratory testing.
The goal of the test matrix is to provide organization and not become a checklist that is blindly followed. The value of creating a test matrix must outweigh the time to create and maintain if it is to be reused. A test matrix can be beneficial for regression testing and when testing a feature across multiple browsers or testing areas. In the end, how a tester organizes her tests can be a personal preference or company-driven especially in regulated environments.
What is a Test Matrix?
A testing matrix can be created for existing features to facilitate regression testing or for new features that require multiple rounds of testing. The goal is to reduce the need to gather this information each time the feature is tested allowing the focus on generating test ideas and performing testing. This approach is also helpful for features that are tested across multiple browsers or modules within the application.
A testing matrix can be created using a spreadsheet or table format to take advantage of the row and column relationship providing a way to keep track of completed testing. The rows define the feature’s options and the columns represent the testing areas or browsers to test. This approach reduces the time to create and update the testing matrix through consolidating the feature’s options across testing areas. The tester can bundle multiple tests into one test scenario or she can test them individually based upon her test ideas, experience level in testing, and knowledge of the feature. This allows her to change her approach when retesting a feature and allows other testers to take different testing paths providing better overall testing coverage.
Creating a Test Matrix
If you are testing a web-based application and you are testing the ability to print a report using different browsers, your testing matrix may look as follows:
The above matrix provides initial testing guidelines defining the browsers to test. The columns can be modified to add or change browsers. If multiple reports need to be tested, this matrix can be copied for each report or additional columns can be added. It really is up to you on the best way to organize the testing. With this information coupled with knowledge of the application and history of fixed bugs, testing ideas can be generated. This matrix can be customized to include columns to document the testing ideas and notes. A testing matrix should be created based upon the needs of the features being tested, the risk level, and how much documentation is helpful.
Variation of a Test Matrix
The above test matrix example defines specific feature options to be tested allowing the tester to generate their test ideas. Another variation would allow the tester to document their testing ideas. Your testing matrix may look as follows:
Benefits of This Approach
This approach can be helpful when there are a define set of features that must be tested such as in regression testing or when the same set of options are tested across multiple browsers or testing areas. While the tester is executing her testing ideas, this approach can help her organize tests and document what has been tested so she can review progress. Because it is not always possible to perform all test ideas across all browsers or testing areas, the tester can assess how much testing to perform. This information can be reviewed with stakeholders or other testers to discuss test coverage.
Disadvantages of this Approach
There is a cost associated with creating the test matrix by ensuring the correct information is captured and maintaining it when the features change. There is the risk that a tester will test only within the constraints of this structure and could miss important tests. Training needs to occur to ensure testers use the testing matrix as a way to organize their testing and not constrain the testing.
For photo credit click here.
This article was first published in May 2011 in Testing Circus. There are a lot of great articles that you can read in this and other editions of Testing Circus. This was my first published testing article and I thank Ajoy for allowing me the opportunity to write for his fine magazine. I have made revisions to my original article, which is based upon the acronym “PLAN”.
Imagine you have been assigned the responsibility to oversee the testing of a new module being added to the company’s flag-ship application! What a wonderful opportunity to challenge your skills and to show management you can handle the responsibility. Where do you start with this assignment? Do you dive in and start testing? Or do you take some time to lay out a testing strategy?
The test plan is a tool to develop an overall testing strategy and provides guideposts to measure progress. The key to planning is to consider the project’s scope and risk level to determine how much time to devote to the planning process. Plus considering the audience and how they will use the documentation is important. Keep the test plan light-weight by documenting information that is helpful in managing the project. Remember the test plan is a living document. As you learn from the test results your approaches will adjust accordingly. Most importantly, enjoy your testing assignment by allowing the test plan to become one of the tools you use to successfully complete your mission.
To make the process easier, translate the word “PLAN” into four actionable steps: Prepare, Layout, Analyze, and Navigate. These steps can help you plan and manage your next testing assignment.
Prepare by gathering information to form an initial understanding of what you are testing.
Understand Expectations and Deliverables
In defining a testing approach, understand the purpose of the assignment, clients’ expectations, deliverables and associated deadlines. It is helpful to understand how the client will use the module, importance to their business, and what features are more important to them. This will enable you to write better test guidelines and allocate the testing time. Sometimes a module is being created from a prototype perspective and actual business cases may not be available. In those situations, understand the intended functionality to define test cases.
Review Documentation and Identify Contacts
An important aspect of the planning process is to review available documentation to identify initial questions and to determine if critical information is missing. There may not be much or any documentation available. Conversations are always important to gather information and to gain a better understanding of the testing problem. If there is not any documentation, start a list of general questions to gather this information. At this stage, consider the optimal skill-sets required in your testing team and identify subject-matter experts to contact with questions.
Layout the test plan in a concise manner selecting a medium that closely aligns with the project’s scope and risk level.
Create the Test Plan
As you gather the information, start to create the test plan using a medium such as: word document, spreadsheet, wiki page, or other collaborative tools. The specific tool selected can be a personal preference as each has its pros and cons. When assembling the document, consider using tables and bullet points to make it easier to read and locate information. I prefer a concise one- to two-page test plan. Remember you want people to read and refer to the test plan. Think about the last time someone gave you a lengthy test plan to read. Did you really want to read it? Was there “noise” that did not provide any value?
Another avenue is the use of low-tech options such as: a white board, an easel board, or a notebook allowing you to quickly make changes and track progress. Whatever option is selected, keep the test plan concise to ensure it is used as a reference tool throughout testing.
Analyze the information to identify risks, milestones, communication, and testing approaches.
Identify Risks and Training
Review the information gathered to identify initial risks with approaches to minimize those risks and identify any training that is necessary. For example, the testers may need to be trained on a system that feeds into the module. Common risks include not having enough testers and insufficient testing time. This is not the time for panic but for creative solutions! Tap into the tester’s strengths; identify how to integrate testing approaches; and keep the approach agile by reducing heavy documentation. If there is a strong exploratory tester, consider allocating time upfront to identify the module’s weaker areas to assist in prioritizing the testing. Plus get those surface bugs to development as soon as possible. They will often block your ability to find the deeper ones.
Identify Testing Approaches and Milestones
It is important to identify testing approaches that could include functional, regression, integration, and performance testing. Balance testing approaches with testing time and available testers to plan out rough time estimates considering any overlap across approaches. From this information, identify testing milestones to help measure the testing progress against the deliverable date. Your rough plan may change as you learn more through testing but consider it your roadmap to keep you on target.
Review the Test Plan with the Stakeholders
While developing the test plan, review the test approach with the appropriate stakeholders to determine if anything important is missing and to gain buy-in. It is better to discuss differences earlier in the project than to try and bridge miscommunication at the end. This does not have to be a formal review as sometimes a meeting discussing the approach is sufficient. The key is to have communication with your stakeholders. How often and when you have conversations with the stakeholders is dependent upon the scope and complexity of the project.
Navigate through testing by referencing the test plan and adjusting approaches based upon knowledge gained through testing.
Test Plans and Approaches Evolve
A test plan will provide strategic oversight to manage your testing assignment. Refer to the test plan periodically to ensure that the objectives and deliverables are being met; review identified risks to assess likelihood; and review milestones against the team’s progress for any corrective action. When reviewing the test plan, continue to identify new risks and determine if there is a need to change testing direction.
A test plan evolves throughout testing because test approaches are refined based upon additional knowledge gained through the test results. As testing progresses, risks may change, unexpected problems are encountered, and certain phases of testing may take longer than originally anticipated. The planning process is interwoven throughout test execution as it allows you to deal with the anticipated problems and the unknowns discovered during testing.