When it comes to websites, before it is launched, it must undergo a usability testing. Nobody wants to introduce a website with too many flaws which will not satisfy its users in the end. It could be your loss in the end too. Thus, it is best to have a website undergo testing to see if it can satisfy the user and will not provide any problem.

The term used in knowing if a thing is easy for the users to utilize is called Usability Testing. This is a method that almost all companies are performing in order to identify the user experience which can be a basis for improving something to meet the user experience.

What is Usability Testing?

Usability testing is utilized as a method for assessing to know if a website is easy to use or not. Testing the usage of a website can be a big factor whether it will bring a good experience to the users or will not bring satisfaction. The usability testing is done by researchers who will monitor real users. With this, real users will be able to experience the website and will provide what could be the possible problems that they have encountered during the testing.

Usability testing may be compared to the typical testing done for a website such as acceptance testing and bug testing. However, usability is fairly different from other tests because, in this kind of testing, real users are the one who will experience the website and accurate information will be provided since it came from people who have experienced the product.

When to use it?

Usability testing can be used when you want to compare your website to another. Comparative usability testing is the term for this. This testing is being done if you want to compare your website with another website. Also, comparative usability testing is also done if you want to match the designs of two websites in order for you determine which one will work on the experience of the users.

In addition, usability testing is also used in order to know what should be included on the website, product, or service in order to achieve the needs and satisfaction of the users.

Concrete Example of Usability Testing

In order to know how a usability testing is done, here is an example.

A researcher will be the one who will lead the testing. This will know if the usability is good or needs to be improved.

A researcher will read a task on the participant like how a technical support is contacted. After the task was delivered, the researcher will let the participant perform the task on its own. For the researcher not to be biased, it will just go with the provided script and the script will be read to all participants.

Once the participant is done with the task, the researcher will read the next task until the testing is done.

Usability testing can be the key for developers and business owners to improve their user experience in order to meet the needs and satisfaction of their customers.

— Slimane Zouggari

What Is It?

MoSCoW method is known to be an efficient prioritization technique often used in business analysis, management, project management and software development. This method is used to reach a common and detailed understanding with some stakeholders. This is especially true with regard to the significance of placing a delivery basing from all necessary requirements. This is also known as MoSCoW analysis or MoSCoW prioritization.

MoSCoW is an acronym that is derived from the first letter of each prioritization categories with the interstitial addition of Os to make the complete word even more pronounceable. While Os are found in the lower cases that indicate that they do not stand for something, they are all capitalized.

How to Use It?  

As far as MoSCoW method is concerned, you could just make use of it when you will prioritize all the needed requirements. Developers who use this kind of method must deliver all necessary requirements that include the following:

1. Must Have

These are really essential to the timebox’s current delivery to acquire success. If one of the must have requirements is not presented, the delivery of the project will be considered as a failure.

1. Should Have

These are the requirements which are essential but not as essential as the must have requirements. But, despite the same significance that it covers as the must have requirements, these pieces do not need to be time-critical. You can choose some other ways to completely satisfy these requirements.

1. Could Have

These are the requirements which only aim to enhance the satisfaction of the customer and experience of users with little cost on the development. This will be required if resources and time permits are required.

1. Won’ Have

These are the requirements which have been agreed on by some stakeholders as the least critical ones, not appropriate and the lowest payback. These are not planned requirements which can be either reconsidered or dropped for inclusion.

When you already have these requirements, you’re already sure to make use of the MoSCoW method.

When to Use It?

MoSCoW is primarily used in timeboxing wherein you are given fixed deadline with a strong focus on the most essential requirements you need. With such idea in mind, this method is usually used in some agile kind of approaches in software development such as DSDM, RAD or rapid application development and Scrum.

Concrete Examples

For instance, a team who has a lot of potential epics can make use of MoSCoW method for the next release of their product. They would only need to select which of the epics belong to the Should Have and Must Have requirements. Oftentimes, any team can find that to help them identify the minimum viable product.

After that, they can already make use of the MoSCoW method to determine what kinds of features belong to Should Have, Must Have and so on to meet the needs of the users. If there are also some sufficient capacities in selecting minimum viable product, then the team can also plan of associating the Could Have and Should Have items.

— Slimane Zouggari

What Is It?

KISS is an abbreviation which means to say, “Keep It Simple, Stupid or Keep it Stupid, Simple”.  This is a kind of principle which was really essential to the success of software engineering industries. One of the common problems of software developers and engineers these days is the fact that they over complicate problems. And thus, KISS is the answer to such things.

This principle states that a system works best if things will be kept very simple than making it very complicated. This only means to say that simplicity should always be one of the key goals in the designs and in avoiding the unnecessary complexities.

When to Use It?

This KISS can be used to solve problems a lot faster, produce codes to solve some complex problems in line with codes, build larger and simpler to maintain systems and large development projects and groups. This is during the times when you experience great problem dealing with complex problems in your area of expertise.

Concrete Examples

There are lots of concrete examples as far as KISS principles are concerned. But, this thought will definitely drive you to the best examples of this principle.

“Some of the greatest algorithms all over the world are always those with fewest code lines. When you go through such lines, you can easily and immediately understand all of them. Algorithm innovators broke down this kind of problem and it was already been understand. Huge numbers of problem solvers are not considered to be great coders yet they are still producing great kind of codes.”

Variants

This KISS principle find its origin in the same concept of minimalist such as Leonardo da Vinci and Occam’s Razor that puts emphasis to the idea that simplicity is really an ultimate sophistication. According to Mies Van Der Roche’s, less is considered to be more. Make some simple task very simple is the idea that Bjrane Stroustrups wants to emphasize.

The founder of the Lotus Cars, Collin Champan also follows the KISS principle. He assures to inform all of his designers to simplify and add lightness to the features of their product. Machines of Rube Goldberg and Heath Robinsons also make those overly complex solutions to be at the simple approach. Apart from that, Shakespeare also emphasizes the idea of brevity as the best soul of the wit.

Another alternative view in relation to KISS principle is more about the attribute of Albert Einstein which emphasizes that making things simple is possible. A variant is utilized in marketing in making everything straightforward and simple.

The KISS principle has been seen in different variants. There are still companies and people who make things difficult. But, with this principle, you would be able to make things easy and simple. Hence, you will no longer have to worry or be stressed out with the use of this KISS principle. This was also proven to be really effective and that you must follow it all the more for the common good of all!

— Slimane Zouggari

Worse is better is actually known as New Jersey Style. Introduced by none other than Richard P. Gabriel, it also basically aimed to describe the software acceptance and its dynamics. It is just that it has its broader and even wider application.

Apart from it, its main concept emphasized is that quality does not actually increase along with functionality. And, there really comes in when less functionality is an even likeable option when it comes to usability and practicality. The software might be limited but still easy and convenient to use. This is even more attractive to the market and users as compared to the reverse.

Prior to the so-called oxymoronic title, it was actually called by Gabriel as caricature. This declares the style bad than the “Right Thing”. Nevertheless, he further stated that it has even more survival characteristics as compared to the right-thing development style. This is even more superior than the MIT Approach.

History

In the formulation of the concept, Gabriel was working as a Lisp programmer in the year of 1989. He even presented it in the essay entitled “Lisp: Good News, Bad News, How to Win Big”. In a particular section of the article “The Rise of “Worse is Better”, it was actually disseminated during the start of the year of 1991. This was especially right after Jamie Zawinski found it in the files of Gabriel at Lucid Inc. And then, it was emailed to colleagues and friends.

Description

The Worse is Better is actually claimed as a model of software implementation and design consisting of the following characteristics. This is in approximately descending order of significance.

Simplicity

As per the design, it must really be made simple, particularly in interface and implementation. Thus, the implementation must be made simple as compared to the interface.  In a design, it will always be essential to have simplicity.

Correctness

In almost all aspects, the design must always be correct. Nevertheless, it is better to just stay simple than right.

Consistency

Prior to the design, it must not also be overly consistent. There are times that consistency might be sacrificed. The important thing is that all those design parts are dropped. They are those that usually deal with less common situations than just to introduce inconsistency or complexity in the entire implementation.

Completeness

The design will have to cover a lot of significant situations as practical. All reasonable and expected cases must even be covered. Quality is also usually being favored than completeness. Even consistency may be sacrificed just to be able to obtain completeness. This is particularly true if simplicity is retained.

Concrete Examples, Variants (MIT)

In regard with the concrete examples of Worse is Better, these mainly include the early C and UNIX, created by none other than Bell Labs. These have been introduced as examples of this particular design method or approach.

Even the windows registry is another example wherein you will notice that everything in .NET is carried out through the use of plaintext.config files. And as the registry hive is believed to be really superior, it is still subjected to a lot of issues that relate to complexity. The moment you have lost a few bytes and they have been corrupt, you will now have to say goodbye to the registry data.

— Slimane Zouggari

MLP

The MLP is introduced as a new product which brings back the highest amount of love from the tribe members with less effort. Sam Altman, Y Combinator further emphasized that it is a lot better building something that a small number of users will love as compared to a lot of users.

History

The concept of minimum lovable product originates in giving importance to the prioritization of stories of users on the story map. Due to the reason that being viable is and will never be enough, it is rather important to make the minimum product lovable. The perspective of customers is usually being taken into account.

Description

The job of building great, appealing and impressive products is really difficult. And whether you are working in an agency, startup, corporate and non-profit, it is true that product people really want it all. Now, when launching a product, there is usually a tricky balance of striking between quality of execution and speed of delivery.

The manufacture or creation of a great product requires dedication, discipline and skill. It will also mainly require making some bold choices. This is even whoever you want to hire and when you need to hire and what will you need to build. In all these, the product will be defined by all the decisions that you make.

The MLP is now the newest fit for the design-hungry users. In addition to that, it is simply about thinking big and starting small. The idea is more on validating that people really loved your cake and will then come back for more. And then, they will have to tell all their friends. Since you have started small, you still have more room to maneuver.

The MLP further allow you of gaining more followers while exploring for more opportunities. This also sticks to the belief of not only making clients happy but even more on making happy clients.

Difference with MVP (minimum viable product)

The difference that MVP has with MLP is that the former is a newer product that is consisted of necessary facets for deployment. Nevertheless, there’s no more than that. The MLP is even a lot better than MVP because it is a curse for all ambitious tech companies that aim to grow.

The transactional world usually depends much on the happiness of customers over a long-term period. Long-term happiness of customers originates from customers adoring your service or product. And, even if MVP is considered as really a strategic approach to obtaining a product out of the door, it actually produces unsatisfactory products.

In several large organizations, the usual conversation will involve the minimum viable product and some of its flawed principles. Now, with MLP, the concept is more on the things that customers will love you and will not tolerate you.

Another major difference between MVP and MLP is that the latter is more on doing something fantastic in bringing great joy for the world to become a better place. Now, you already have learned more about MLP!

— Slimane Zouggari

Often abbreviated as RERO, release early, release often is actually a philosophy on software development. The main focus is on emphasizing the significance of frequent and early releases. This is especially when it comes to creating an even tighter loop between testers and developers. This is also in contrast to the feature- oriented release strategy.

There were lots of advocates who insist that this enables the software development to progress a lot faster. This will allow a user to define the software and its outcome. This way, it will conform to the requirements of the users to the software. And thus, this will further result to even better and higher quality software. The philosophy that relates to development will attempt to eliminate the issues of creating software which no one would ever like to use.

Actually, the philosophy was introduced and popularized by none other than Eric Raymond. The strong focus is also more on listening to customers. This was also actually applied to the early development of the open-source software and Linux kernel. This was even more applied to commercial and closed source software development.

Practical Examples

The most practical example of release early, release often is that when it has been a part of the development model of Linux. Even this belief had been completely reinforced to a cathedral-building style of development. If the objective was that users will be able to see some bugs as possible, why would still release a version every 6 months and then work possibly as a dog when debugging between releases. This was also when Emacs C core was founded and established this way.

The significant thing of all these is that the archive of Ohio State Emacs expected the many features of the archives of big Linux. But, only a few of them was able to think hard about what they were actually doing or of the archive and its suggestion about the issues in the cathedral-building development model.

How to make it

If you are interested to incorporate the philosophy, you first need to the jobs that must be done. It is also through conventional and traditional marketing techniques that teach you to frame and segment customers by attributes such as race, age, demographics and more.

Thus, you need to seek for answers to some questions that include; What will be the job of the product? What are the problems that the product is solving? And then, ask clients about the new features. Their feedbacks will help you a lot along the way.

More importantly, you must start establishing a relationship via emails. Emails will be an essential way of building a relationship. This will provide you and all of your users the freedom of choosing those whom you would want to interact.

Monitor all the feedbacks of your customers. And, release early to be able to make your customers happy. It is the happy customers that will always be the most valuable things that you should strive for when you make it.

Now, you have already learned more about the philosophy called release early, release often!

— Slimane Zouggari

What Is It?

Over-engineering is the process of designing a certain product to make it more complicated or robust than is necessary for the applications, either to assure sufficient factor safety, adequate functionality or design errors. This process is desirable when performance or safety on a specific criterion is very critical or extreme functionalities are required.

But, this thought is criticized as something wasteful from the value engineering points of view. When it comes to design philosophy, this is really opposite of what less is more. This is also considered to be a violation by other people.

Over-engineering occurs in some specialized criteria in the market or in high-end products. This also takes various forms and scopes.  This thought is somewhat beneficial in some ways but for some, this is a violation that provides problem. And, these problems must be addressed as early as possible.

Why Is It A Problem?

Over-engineering is a problem by some people since it is opposite to the scope of the value-engineering.  Here are some of the reasons why over-engineering is a problem:

• Overbuilt

In one form or another, over-engineering products are really overbuilt and provide performances which are far in excess of your needs. This is the reason why it is really bulkier, heavier and more expensive than necessary. For instance, a family who uses SEDAN can drive at exactly about 300 kilometer per hour or even a home cassette video recorder with a lifespan of more than a hundred year.

• Overcomplicated

Apart from the fact that over-engineering products are a problem in terms of built quality, they are also considered to be really overcomplicated. The designs are really far more difficult than the necessary ones.

For instance, a modern editor of text asking where to save some files are given a chance to choose from different formats either in EBCDIC, ASCII or in different multi-byte formats. Over complexity of over-engineering products reduces the products’ usability. This may also decrease the productivity level of the products design team due to the huge need of maintaining and building all these features.

• Market Segmentation

Another related problem with over-engineering is more on market segmentation – creating or building different products agile to different market segments. In this kind of context, particular kind of product may be less or more suited to a particular marketing segment and is over-engineered to any applications.

How to Solve It?

The best way of solving over-engineering problems is to assure of forcing the functionality and features of a certain product as necessary. You don’t need to create it less or more than necessary to assure that this can meet the needs or requirements of users.

In short, try to make it in a well-balanced manner basing from the build quality, features and performance. The purpose of which is to assure that it does not over value the necessary things that it supposed to have.

Now, you already have learned more about over-engineering and all its significances that you must not miss out on!

— Slimane Zouggari

The key for having an exploratory testing is that it’s not a test technique or the items were tested or being reviewed, but the cognitive commitment of a tester, as well as its responsibility to manage the time.

What is Exploratory Testing?

Exploratory testing is considered as the approach to testing the software, which is described concisely as the test execution, test design, and simultaneous learning. In 1984, Cem Kaner coined the terminology as the style of the software testing, which emphasizing not only the personal freedom but also the responsibility of the individual tester in order to optimize the quality of the work in a continuous way by treating the test-related learning, text execution, text design, as well as the interpretation of the test results as a supportive mutual activity running in the project.

How and When to Use the Exploratory Testing?

Using the exploratory testing, you don’t have to wait for a long period of time and it only focuses more on intellectual approach, thus agile test is guaranteed. Also, it can easily and seamlessly detect the bugs if there’s any and it doesn’t require any documentation.

You can use the exploratory testing if you have to learn and understand the product in an agile way and then provide a quick feedback to it. It can also be applicable if you are having a hard time understanding what to do next. Also, you can use it to diversify the process of the testing after doing the scripts. Lastly, it is used to make a brief check of the work of other tests.

Criticisms

Using the exploratory testing, you have to remember that it will require you to have a certain mindset. And because of its unstructured nature, you should give much of your attention as you may more likely lose your focus into it. And because of its performing ‘on-the-fly’, you may find it hard to define in which the tests are running, and you may encounter difficulty in repeating the cases if you have to.

Also, it is viewed that exploratory testing will not be great without the help of scripted testing. These two are known to be two kinds of partnering approaches that may not be mutually exclusive yet fully compatible, as well as can be used to test in the same projects. Also, it is criticized that most of the problems in the software testing cannot be solved using only one approach, meaning exploratory and scripted testing should always come together at different stages of the process.

Concrete Example

We are becoming more and more exploratory once we didn’t understand what kind of test needs to be done in an advanced cycle of the test or once we are in a circumstance of not creating those tests. When we are running a scripted test and when new data comes that suggesting a better technique, we may more likely have to switch to the exploratory mode. The result on the exploratory test is not radically different compared to the scripted test results, yet they are still compatible with each other. The companies such as Microsoft and Nortel are using both these approaches on similar projects.

— Slimane Zouggari

Class-responsibility-collaboration Cards (CRC) cards is a tool that is used in creating software that is object-oriented. As a teaching tool, it was originally developed by Ward Cunningham and Kent Beck. The CRC cards are also highly-recommended by many programmers and supporters. This card is said to be the alternative for sequence program and is used for object collaboration.

CRC Cards are usually made from index cards and each of the members will write on the CRC Cards for any relevant class of their design. The card is divided into 3 major areas: the class name, the responsibilities of each class and the collaborators of other classes. CRC cards also help to avoid too many responsibilities for the class. Since these cards are portable, they can be easily seen and be easily re-arranged.

When to Use

CRC cards were originally created to teach object-oriented concepts. But they are also used to as a modeling technique. They can be used as an effective tool for conceptualizing models and also for detailed design. Many people find the CRC very wonderful, but some find it very cold. They can be used perfectly if the team is with so many details and the team is getting bogged. They can also be used when identifying the class seems so cluttered and there are no clear definitions. It is not good to have a long list of responsibilities. It may not fit your index card. CRC cards can also be used for any interactive designs. Many agile teams are making use of the CRC cards as a requirement and often use for designing an important set of objects.

Since this card represents the collection of similar objects they can be used in many ways. For example, in a university system, the classes there are represented by seminars, professors, and students. At the top of the CRC, the names of the classes will appear. And this is usually written in a singular noun phrase or a singular noun only. Singular names are used because of the fact that each class generally represents the version of an object.

Creating CRC Models

How you do you create models of CRC? These are the following steps on how to do it:

• Find Classes. This is the first step in making your model. This identifies the building blocks for the application. It is also good to look for 3-5 classes.
• Find Responsibilities. After finding the classes, it is now the time to look for the responsibilities. But, it must interact with the other classes to make the job well-done.
• Define the Collaborators. The class must collaborate with other classes. Collaboration comes in two forms: request to perform the task and a request for information.
• Move the cards. Understanding the system is letting everyone understands it. It is easier to understand if there are two cards that collaborate. And it is also easy to know the relationship between these classes.

There are also responsibilities that every class knows and does. For example, every student has their own name, phone numbers, and address. These are the information that the student knows. And when the student enrolls in a seminar or requests a transcript, these are the students does. Responsibility refers to the things that the class knows and the responsibility they do. There are times that the class needs to fulfill a responsibility but doesn’t have enough information to do it. What they need to do is to collaborate or interact with the card.

— Slimane Zouggari