The Special Characters and Context

 

On creating a new password be it on a web page or mobile app or desktop application or any interface, we encounter the phrase "special characters".  And, we might see few characters represented as special characters.  Why these characters are named "special characters", here?

The Context

When one mentions "special characters" I learn and associate a context to it.  The context defines the character is special or not.  If so, why certain characters are marked as special characters for the password being created?

The context of web and HTML is a journey and evolution.  The web and HTML that existed 20 years back are not the same today.  It has evolved and so are browsers.  So the other technology i.e. desktop applications and mobile apps.

Special Characters and Context

I learn the context will make a character into a special character.  Then what's a special character?  It is a casually used phrase for the non-alphanumeric character on the keyboard.

Few of us might debate and say -- comma, colon, plus, hyphen or minus, hash, dollar, angle brackets, etc., these are all normal characters though it is non-alphanumeric.  Did people (users of the software) had special meaning for these non-alphanumeric characters in their domain of work?

But the comma, period, semicolon, hyphen, space, dollar, hash, angle brackets, etc., all have specific contextual meanings in HTML and web, and other technologies.  Do you think so?!  

The initial web technologies were not robust as today to sanitize characters and process as we do today.  Could be, for this reason, certain characters were termed as special characters and mentioned what to use and what not to use.  I'm not sure is this the reason but this could be one of the strongest reasons.

Today, the phrase "special characters" is continued to use in all major technology organization's documentation and interfaces.  Is this incorrect?  I don't know.  It helps someone to quickly relate and let her/him decide, is what I see.

Parsing and Context

Entering a password, today we assess the strength of it. There are readily available scripts and libraries that do this job.  Not sure if it was available two decades back.  Other than the security aspect of having better entropy what else is the benefit of having special characters?

Say, the special characters are those which I don't see on the keyboard layout. Then what should I think of the angle bracket (< and >) that I use in an XSS payload on the web page and behind the web page?  Note that the same angle bracket can be used in a password too.

Personally, I feel this is one of the good topics to discuss.  It can lead to learning how we term and use the word or phrase for non-alphanumeric characters.  

I don't know if this discussion is needed or not and how much it helps people who are accustomed to the phrase "Special Characters" for certain characters.  But having one does no harm and it can light up the dark areas which are unseen.

The web and desktop projects in which I worked a decade back, it had the RegEx written in different languages and scripts written in Shell, Perl, and VBScript.  These scripts and RegEx were used behind the interface to parse and validate certain characters' presence and absence.  These characters were termed as special characters in the product and it was on par with the operating system documents for consistency.  Also, there was a unique meaning and purpose for such characters here in this context.

Since these scripts and Regular Expressions were used, the characters that take a special meaning in this context were termed as Special Characters.  To keep everyone who uses the product (engineers, support, and customer) be aware of certain characters, it was termed as Special Characters in the context of product and technology.

Should Change the phrase "Special Characters"?

I don't know!

Look at the context where it is used and what characters are classified as special characters.  Changing the phrase to another phrase or word, does it solve and ease the communication with the product's users and business?  Unfortunately, not all software products might bring this change.  Having different words/phrases in the system, add additional costs?  What are those costs?

All I understand is when certain characters are classified as special characters, I look for

1. The context in which it is classified and why
2. How it is special? 
3. What differences it makes in its presence and absence?
4. Software platform terminologies on which the product runs having such classified special characters

Not fixing nor refining nor refactoring certain existence looks better in few cases!  As a technical person knowing what it is and not, is a need and helps.

Assumptions are Essentials and Necessity

 Assumptions on Assumption

I assume that after reading this post, you will use this blog post as a reference when talking about the "assumptions" in Software Testing.  We engineers, believing or hoping that the software we build will work itself is an assumption.  An assumption that is carefully thought over and evaluated.  Do you agree with that?  

When was the last time you assumed the battery charge leftover in your cell phone is enough to make a quick call or to make a banking transaction?  How did you know that the charge remaining is enough?  Anytime that assumption was broken to you?

In another way to put it out, the software and hardware we are using is an assumption that is functioning as we expected to an extent.  That also means we are testing the sets of programmed assumptions with conditions, data, states, and events when we test the software.

Did we assume when solving a problem in Math?  Did assumption help to solve?  We use theorem, hypothesis, corollary, and set of defined assumptions for the data we take in problem solving.  But some might not agree and say we do not use assumptions.  

Assumptions, Mathematics, Engineering, and Testing

I'm not sure who all will agree and disagree on saying assumptions are part of the evolution.  If there are no assumptions, probably the evolution will cease.  I buy groceries for a month assuming, I will survive this month.  Should I call this -- assumption, hope, confidence, determination, evaluation, accuracy, etc  Actually there is a very thin line of difference between the meaning of these words.  In a way, these all look alike at the certain phases in the context.

When I started testing the Machine Learning systems, this learning started to become much cognizance to me.  In fact, the AI/ML model is an assumption!  But this assumption is evaluated on the set of data that we aware of it and know what it is to an extent.

I have to come to this understanding for now on series of evaluations in my Software Testing practice:

Testing is a science of problem learning, problem solving, and deductions.  We assume certain things, and we infer conclusions from them.

If I replace the word "Testing" with Learning, Engineering, and Mathematics, I see it suits very well to my learning that I have been making as a Software Testing Practitioner.  Should I keep these assumptions I made over certain data to improvise the solution and use it as "the solution"?  That's the decision one has to take from learning out of assumptions valuing against what is expected.

Every problem solving will start, progress, and stops (not end) on the set of known assumptions made.  If one is not aware of assumptions made and being done, then is that a problem?  Or is this just as any other assumption?

Model, Assumptions, Architecture, and Testing

Do we build any engineering product without a model?  The architecture, design representation, requirement,  and strategy documentation are few models to mention here.  Then what actually is the model?

A model is a simplified version of the observations.  The simplification is for helping to focus on what has to be focused on while knowing what isn't being focused on and why.  Isn't this an assumption?  Yes, it is an assumption that is evaluated to an extent based on some (well thought?) assumption.

If we do not make absolutely no assumption about the data, then there is no reason to prefer one model over any other.  Was there any day or instance, you came to a conclusion this one test data is enough to sample the system you are testing?  Then why do people generate different payloads for XSS attacks?  Isn't that payload test data?   That payload is a model; it works or might not work.  If worked till what extent and what did it uncover?   

That payload when built by a Test Engineer (an Engineer) wasn't it an assumption? An assumption that will help her or him to discover information and help to learn about the system in a given context?

Every test data we identify, build, use or ignore is a model -- a modeled data on thought over assumptions.

Testing, Models, and Assumption

We cannot test without an assumption.  Then we cannot build an engineering system without assumptions.  At a layer, a working system is a model and in turn which is an assumption.

Rather than saying, do not assume, saying list out what you have assumed and why so.  There is no model that is prior guaranteed it works.  So the name model.  The only to know for sure which model is best in a given context is to evaluate them all.  Is it possible to evaluate all models?  In other words, is it possible to test all the models?

Since this is not possible, in practice we make assumptions that look reasonable about the system, data, state, event, user, technology, and ourselves i.e. engineers.  On making these assumptions we evaluate a few reasonable models.

Having models in the testing and automation will help in understanding and approaching the testing in the layer appropriate to the context.

Assumptions

It is not bad.  It is needed.  We use them every day in learning, problem identifying, problem solving, and decision making.  Watch out for the coverage of the assumptions made and being made.  Testing nor coding nor debugging cannot proceed further if we do use sampled and evaluated assumptions.  Question the assumption.  Questions the assumptions you are making.