You Must Learn To Unlearn

Hello, again my fellow readers!

Last week we took a look at the beginner pattern, Your First Language. This week we will continue along the path to the next pattern, The White Belt.

As I have said, The White Belt is the next apprentice pattern after, Your First Language. This pattern is all about what to do after you have learned your first language and can strut your stuff with it. The problem The White Belt pattern is here to solve is when learning a second language becomes tiresome and tedious. Learning one language is great but, expanding your library is a must to become a software craftsman. What can happen, however, is slowdowns and stalling in learning. The solution to this is to adopt the mindset of a white belt. To quote the book, “Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.” In other words, while you go about learning a new language, treat it as if it was brand new to you, even if you are learning something with familiar attributes. An excellent example is you have learned Java and now you are learning JavaScript. Both are fairly similar to each other and have overlapping ideas and methodology. Using the white belt philosophy, treat learning JavaScript as if it had no relation to Java. While this may seem counterintuitive (it still does to me),  the pattern claims that it will accelerate your learning. It will also allow you to discover new possibilities, as well as your mind, is open and without preconceived notions.

I understand where this pattern is coming from. I do get that an open mind can, and most likely will, lead to new possibilities. I agree with that. I suppose that my issue is that forgetting to accelerate learning is still something I find a bit backward. Looking at it, I must admit that I have not tried this method. Typically I find that making associations to things you do know is a good memory tactic and can speed up learning. It is entirely possible that the White Belt pattern will work for me. The only thing for it is to try it. I can legitimately say it doesn’t work without trying it for myself now can I?

Looks like I have some unlearning to do in my future.

Until next time readers!

The Customer Wants What The Customer Wants

Hello, again my dear readers!

It appears that this week I am very focused on the customer this week as this article I read particularly focuses on what the customer wants. The article is titled, “Figuring Out What They Expected“. When it references they, the article is referencing the customer. The person you are programming the program or application for. Anyway, let us get into the meat of this article.

The article starts out defining two things. The first is what the user model is. The user model is effectively, what the user is expecting and thinking when they use the program. It bundles everything they know about computers and all their preconceived notions about using them when they sit down and use your program. How do I use this program and what does it do for me, the user? This is the model you are aiming to nail. If no one uses a program, does the program really exist? The answer is yes but we aren’t here to talk about that. The next model is the program model. This is what the programmer programmed into the program on how it looks, works, and operates. The idea in establishing this is that the user model and program model want to be overlapping or ideally mirroring each other. Now there are two ways to do this. The first is to change the user model. Good luck with that one. People are stubborn, stuck in their ways, and how would you even accomplish that anyway? Write a manual on how to use your program? We all know no one reads manuals anymore (although to be honest people really should) and if your program is different from what the user is used to, the user is likely to just not use your program. There is almost always another way. This leaves the program model changing to match the user model. I mean, let us face it, it might suck but you can change your program to match what the user will expect. It may be a pain but if it means your program is used more and ultimately bought more, I think it is worth biting the bullet.

The next part of the article goes over how to actually find that user model. The article has a simple and elegant solution… ask them. Then after you implement them, grab a few people and ask them to test them. Not a large group of people now. Only about 5 or 6 is required; after that, any more tests are fairly repetitive and not that useful. In the end, if the user has to guess how the program works, the program model is not quite there yet.

This article has reinforced my view that in this industry, the end user or customer is the ultimate determinant for a program or application. After all, we are programming an application for someone to use. If they can’t use it, its no good to them. I will admit, I’m surprised that only 5 or 6 people for usability testing are the norm. I do have a new appreciation for the Apple way of thinking where the simplest way to do something, is the way to do it.

Until next week readers!

Sure You Can Test, But Can You Really Test?

Good day my fellow readers!

As I have been learning all about software testing in class, the career of software tester has looked more and more like a job I would like to do. In my readings, I can across a blog post titled, “10 Qualities That Can Make You A  Good Tester.” I know hat you are thinking, “Ugh! Clickbait list articles.” but this one seemed relevant so I decided to have a read anyway.

The post starts off asking the question, ” What makes you think you are good at testing? Why do you qualify as a tester?” The author was saying that anyone with enough knowledge can test a program. It falls to different qualities of the tester that truly make them a good tester.

The first quality is that the tester understands priorities. What should be tested, what should be automated, what requires manual testing, what should be done first, ect. You are given a thing(s) to test and you have a limited amount of time to test them. Prioritization is a must.

Next, the tester should ask questions. The questions go farther than just, “What is my goal?” They must deeper like what changed, what was fixed, what is the product used for, or who will use it. The more understanding a tester has, the better they can do their testing.

The tester must be able to create a number of ideas. There isn’t just one way to test one thing and one product may be used in different ways. Simply put, more ideas = better testing.

The tester must be able to analyze data. Not knowing what data you get back means you are missing a big part of your testing as much of automated testing is reading and understanding data.

The tester must be able to report negative things in a positive light and be good at reporting. These are technically two points but they are practically the same thing. Reporting something in a positive way, even if negative, is a great way to build solid communication and improve teamwork. This plays into good reporting. People want to hear straight and to the point reports that get the point across and all the important parts. No one wants to sit there and read a list of negatives for minutes on end.

A tester must be able to support the developer. This goes beyond just finding a bug for example. A developer can’t fix a bug if they are having a hard time even recreating it.

The tester can co-relate real-time scenarios to testing. This sounds like a lot but it really boils down to A.B.T. Always Be Testing. Almost like improve testing. If you constantly test thing in your life outside the office, it can give you ideas to test things inside the office.

A tester must be a constant learner. Like the rest of the programming industry, nothing stands still and you shouldn’t either. Learn new technology, new tools, and new ideas.

The last trait is the tester must be able to wear the end user’s shoes. The ultimate goal of the product is to send it to the end user. If the tester can’t understand the end user, the end user will most likely not be happy with what they get.

One big thing stands out to me after reading this list… the end user is everything. In just about every article I have read the end user will without a doubt make an appearance in one way or another. If I can’t get my head around what the end user wants, I will not last long as a tester. The co-relate real -time scenarios was an interesting one as I like most, probably leave work at the office and never take it home. This takes work and home and fuses them keeping the skill of idea generation at the forefront. What surprised me a bit was that the reporting skills were geared toward streamlined and quick reports. I had expected reports in the testing world to be longer and more technical. This may just be the writer’s individual experience but it does make sense to me. The people testers report to literally made the thing they tested. They probably don’t need a nitty-gritty teardown.

Now I have some things to work on as a programmer before I graduate. They don’t seem hard thankfully, just something that requires a lot of time.

Until next time readers, have a good day!