Test design with different points of view-six thinking caps

Patrick Prill has more than 10 years of experience in software testing. After 4.5 of the testers, he became a Test manager, and for the next five years he took 50 people to do a large-scale test project. A new job at a software and automation consulting company's Test lead allows him to return to a small test team and gain hands-on experience. This experience, along with discussions and projects on the context-driven test community, rekindled his passion for testing and bug tracking. Patrick lives outside Munich, Germany, a proud husband and father, and his daughter is excellent. He was still a carpenter in his spare time.

There is not a single point of view

As a tester, the most important thing is a point of view, one of your own. This view is based on a lot of experience and the knowledge gained from your recent projects and experiences. It is also based on your recent constant mood and your personal attitude towards software, developers, teams, clients, etc. Your recent views have also determined your ability and creativity in test design. But a tester needs to do more than evaluate the software in their own personal opinion. I don't think this is enough for a good tester to objectively check the software test specifications and/or a set of pre-defined test sets. You may miss a lot of important project information about the software. It is more important to evaluate the quality of a product than to calculate a bug that has been found and fixed, or a test set that has been executed and passed. There are many ways to improve your test design skills for collecting additional information in different points of view, far more than just "pass" or "fail". You don't have to re-use them, you just need to add them to your daily work while executing your current test set or charter. There are many ways to help you do it. Today I would like to introduce two approaches, both of which a good tester should have or should be added to his or her work in order to gather additional information and insights into simple node-time methods, and to identify issues, bugs and opinions, and discuss them with architects, analysts and stakeholders.

Six Think cap
Edward de Bono's six thought caps were originally an innovative technology discussed as a group structure. The aim was to introduce at least six different views in one discussion. Mind Mapping Software Xmind 2013 introduces six thought caps into its template (see Figure 1).
This method is also very suitable for software testing. You can assign these six hats to some of the people on your team or you can wear them on your own. Using color-coded elements helps focus attention, such as a colored base cap or colored card that lists the most important features of each hat (color). This will help you to enter and maintain the best state of mind when you bring different hats.
Let's talk about different colors now. The blue hat is objective and should be able to help the hooded person to focus on the discussion. If you use this method alone, you'll have to wear a blue hat so you don't get confused. If you want to assign six hats to team members, you may give the Test manager and the test leader.
The white Hat represents objective information and analytical thinking. The focus of this hat is on demand and how to implement them. In the test design, the white hat helps create the model of the app. Wearing a white hat you should execute a test set as expected and focus on the facts. This person's task is to gather facts to inform the ongoing discussion of value neutrality.
Red Hat represents emotional thinking, both positive and negative. This hat should help you to observe your own emotions. When testing, you build feelings about the software under test. In my opinion, to a large extent this also contains the hard-to-measure "charm" characteristics. Do I like to use this software? Is it troublesome to use? Or is it difficult? Such information is often difficult to put into a bug report, but at least inform stakeholders so they have a chance to react. Software that uses seasonal headaches may be both functional and technically correct, but users don't think it's as good.
The yellow Hat represents an optimistic response. Everything revolves around the best use cases. This hat only sees the good aspects and benefits of the software, so it is a good hat for a happy path test. Yellow Hat is to experience a bright day, but if the yellow hat has no other information, you should be careful, because this is a bad sign!
The Black Hat is a critique of the ability to recognize and pessimistic thinking. This hat is a little demon on your shoulder, it is good at identifying defects and risks. The Black Hat is doubtful, critical. Listen to what the Black Hat says, because it can find many new false scenarios or unknown risks.
Green hat, last but not least, it represents creative thinking. This hat creates new ideas and thinks in different ways. In the test, the green hat can find new ways to test or use the function. Green hats can be creative to help optimize the software, and you can use it to find solutions. I suggest trying to think like a child. Children use things that many adults cannot imagine, because adults are constrained by their fixed thinking. Try using a green hat to get rid of your deep-rooted thinking habits. This is difficult, especially at the beginning, but you will meet a lot of interesting ideas.

Some of these ideas you'll try to put aside at first, but it's best to write them down and review them. With six thinking hats, you create countless possibilities for collecting information. Your project environment should be prepared to accept not only information about bugs, but a waste of creativity and feedback. You can use several hats at the same time for test execution. For example, a red hat can be used in combination with yellow and green hats when actively typing. If the Red Hat's output is negative, it should be used in combination with the black cap to find more risks and problems. It's always important to combine them with a blue hat for separating information resources and having some structure in your process.
You can collect your information in the mind map (see XMIND) to help improve the structure and present all the information together.

Personas
"Quality is important to the people who value it." "-Chosen from Jerry Weinberg, expanded by James Bach. "Personas" is a way to define several sets of software users by creating fictitious representatives. This approach is more than just character testing or using user stories. Your focus is not on work or task but as a person, and create a profile that can crawl users as many faces as possible. This is similar to describing and creating a movie character to an actor. This method is especially good for testers who test software that will be used by many different users. In business software, users were trained or at least briefed on the system. This is impossible for many kinds of software, so the software must be intuitive and provide simple help text or self-explanatory forms and processes. As a tester, you've spent a few weeks on that product, and you know every detail. You have found many methods, hints and tricks. It's easy for you to test the software. But how do you get rid of everything you know? Alcohol and drugs do not help, because you should not completely lose what you know, you only need to put it aside in one or two scenes. That's where personas trying to help. You play a role, you try to put as much knowledge aside as possible, and you try to completely change your usual attitude so that you can see and learn new aspects of the software. The first things you might find are the basics you want your users to have.
It is important to stop or return the role of each link during your test. For example, entering Frank's role, 67 years old, a retired mechanic, he is a bit short-sighted. He used to use the computer when he was working, but it was a few years ago and now he doesn't have one at home. Think about it: on a display, the next thing you want to do is not obvious or any description. Don't press the button below, because you know it's a button to the next page. What would Frank do? Is it missing something that shows where the button is? It's not easy to classify your users, and it's impossible to handle all of your users ' problems. You have to find the right combination of characters and try the necessary depth of your personas definition. Commercial software here has a series of requirements that are different from the software used on the ticketing machines used for commuting.
Especially the last example, it's a good chance to see why you should use personas. Go to the station and watch the users of the ticket machine. What are those people? What's their background? Do they see where it's going to be easy? Does anyone look at the large amount of text displayed on the screen? With the right personas, you'll find that the timeout setting may be too short because you don't have enough time to read all the Help text on the page. The timeout setting scenario may be described in the description and in some test cases. But that is usually a second-minute clock, and it is not always possible to read every single message on the screen in a slow and complete way. When DHL was introduced to Germany, you can send your parcel and accept parcels at any time in those rhubarb boxes, and I personally think that the user menu is one of the best I have ever seen. But when you wait in line and look at other system problems, you think about what you have to improve to create a better user experience so that everyone will like to use that box.

　　Summarize

It is important not to test it only from your own point of view. Whether the approach I've just described can help you design your tests and collect new and important information depends on your project background. But knowing those methods and using them in the right context should be part of each tester's toolkit. Project How to use the information you find, of course, except for bugs. But collecting and presenting information is one of the testers ' tasks.

Copyright notice: This article from SPASVO Software Testing network :http://www.spasvo.com/news/html/201514151919.html

Original works, reproduced when you must be in the form of hyperlinks to the original source, author information and this statement, or will be held liable.

Test design with different points of view-six thought caps