Tag Archives: Software

Bulletin Board Systems: The Birth of Social Networking

One of the fastest growing segments of the modern internet is the use of social networking sites and software.  With users numbering in the millions, applications such as Facebook, Twitter, LinkedIn, and Google+ are helping to keep people connected despite distance between them. While all of these websites are recent creations and are considered to be new concepts, the fundamental ideas behind this type of computer use began to surface in the 1970s with the introduction of the bulletin board system (BBS).

The Humble Beginnings

A BBS is a “[c]omputerized system used to exchange public messages or files” (Encyclopædia Britannica, 2011). Bulletin board systems were originally restricted to companies and educational institutions until early 1978 when Ward Christensen launched CBBS in Chicago, IL (BBS Corner, 2009). From this point, BBSs began to spread as hobbyists and computer enthusiasts created their own systems. Most bulletin boards served small areas because they required users to connect via telephone lines and few people wishes to incur long distance charges.

As the boards became more sophisticated, their services expanded from simple file sharing and public message forums to include games, private messaging, and chat rooms. For the computer-savvy, these services became the equivalent of the barbershops, ice cream parlors, and coffee shops of previous years. The influence, acceptance, and use of bulletin board systems continued to grow until the 1990s when the internet became readily available to the public and World Wide Web blossomed.

Evolution and Revolution

Beginning in the 90s, the nature of the internet began to change drastically. Local bulletin board systems were being replaced by national services (CompuServe and AOL) and a new type of company, the internet service provider. These new companies hosted large modem banks to allow their client to dial in and connect to the internet. They typically provided email access as well.

As ISPs became dominant and the internet more accessible, BBSs began to fade away. In their place, email, internet forums, and internet relay chat (IRC) gained popularity. Some websites included all of these methods of communication. While users now only needed to connect to a single access point, they were still visiting multiple virtual locations to carry on their business.

The next evolution of public internet was the introduction of high-speed, broadband internet connections. Users could now be online 24/7 and accessing data at ever-increasing rates. The increase in speed and connections led to the more innovations in software offering once they were combined with the increase in processing power of the average PC. Forums, Email, and Instant Messaging—a child of IRC—continue to be staples for communicating, but in the middle of the first decade of the 21st century a new moniker was coined for websites that performed these functions. The term that was now used to describe these services was Social Networking.

Where Do We Go From Here?

Just as the current incarnation of social networking has come to overshadow the bulletin board systems of the 1980s, future software will enhance the functionality and speed of communication between individuals. Some of the technological advances are already beginning to show themselves in the form of video chats and simultaneous discussions between groups of people—all of whom are in different locations. Since most methods of communication have already been introduced via the internet, it is likely that the future will hold mostly improvements on existing technology rather than pioneering completely new methods of communicating. An exception to this could be the introduction of holographic projections to replace the current video feed. Regardless of the kinds of changes seen in the future, it is clear that the computers, electronics, and internet will continue to make the world a smaller place to live.

References

BBS Corner. (2009, November 29). The BBS Corner – A Brief History of BBS Systems! Retrieved August 30, 2011, from The BBS Corner: http://www.bbscorner.com/usersinfo/bbshistory.htm

Encyclopædia Britannica. (2011). bulletin-board system (BBS). Retrieved August 30, 2011, from Encyclopædia Britannica: http://www.britannica.com/EBchecked/topic/183745/bulletin-board-system-BBS

 

Advertisements

Preventing Issues or Helping to Mitigate Risk

I recently read an article by Cassandra H. Leung claiming that promoting the idea that testers prevent issues is harming the “tester brand” by establishing unrealistic expectations for testers. My initial reaction was to think that she was crazy because testers do prevent issues if we are allowed to join the project early and influence development. After reading a bit farther, I realized that the latter part of that thought was what she was talking about. Testers can’t prevent issues if they are not allowed to be part of planning or their warnings go unheeded. Unfortunately, both of these scenarios are more common than teams would like to admit.

This revelation leads us to an identity crisis as we are forced to ask, “What should we being doing as testers?”.

Over the years, testers have been charged with many formidable tasks including: assuring quality, catching bugs, policing issues, preventing issues, enforcing acceptance criteria, etc. As a whole, we’ve done a fair job of achieving success despite having the odds stacked against us by these vague definitions. The reason we cannot be completely successful is that we rarely have the level of control needed to perform these tasks.

As thought-leaders continue to move quality considerations “left” and raise awareness of the need to have testers involved early in the process, the need for testers gets questioned. If developers are testing and product owners are writing tests in the form of acceptance criteria, testers need to properly define their role on the team. Since Quality is a team responsibility, we cannot claim it as our goal. My recommendation is to define the tester role as mitigating risk though observation and review of project quality considerations and conversations with the team.

This means that testers are not gatekeepers, defenders of quality, or even responsible for catching all of the bugs. It is our job to bring our unique perspective and abilities to the team and use them to minimize the risk of issues within an implementation.

I admit that this definition is still a bit vague but it is something that we can accomplish. Testers cannot control the quality developed into the product. Testers cannot prevent decisions that could result in issues down the road. Testers can raise concerns to the team and make sure that quality conversations occur so that everyone involved has the best information available to them before making a risky decision.

Be An Eternal Student

No, I’m not talking about spending your entire life jumping from one major to another so you don’t have to graduate. When I say, “Be an eternal student.”, I am advising you to keep learning throughout your life both actively and passively. Don’t let opportunities pass you by. Just because you don’t need to know something right now doesn’t mean that it won’t come in handy later.

One question I get from many people is how I know all of the things I do. I tell them that I just pick it up as I go. Growing up, I was surrounded by mechanics, electricians, carpenters, and other tradesmen. If they needed help, or were helping me, I paid attention and picked up some tricks from them that help me around the house today. With my career, it’s been a bit different. Until recently, I didn’t have a lot of computer people around to talk to so I had spend a lot of time tinkering on my own and doing research. I learned a lot of ways not to do things; I learned some bad habits; and I gained some excellent insight into how our magical toys work from the ground up.

Aside from the hands-on/trial and error approach, I have also invested a significant amount of time reading, watching videos, and taking courses on various topics. Usually I try to focus on things I am either actively working on or expect to in the near future, but sometimes I throw in something brand new or just plain fun to keep me excited about learning. Recently I did this by taking all of the courses in the Docker Path on Pluralsight.com. While I started the courses for fun, I quickly found that what I was learning could be implemented in my current projects, which was an added bonus since I get to practice what I learned and improve my working environment.

It has been experiences like that and some unpleasant bills, replacing things I didn’t know how to fix, that helped me realize the importance of not growing stale or letting my aptitude for learning atrophy because I already know how to do my job. I was also lucky to have grown up around other perpetual students who gave me a solid understanding of how to acquire knowledge. I have found that the keys to learning are very simple:

  1. Find something you are curious about or need to learn.
  2. Gather resources that cover the topic.
    1. Talk to people who already do or know what you need.
    2. Read books and articles about the topic.
    3. Watch videos about it.
    4. Look for someone teaching a course that you can sign up for.
    5. Experiment on your own.
  3. Do something with what you have learned.
    1. Complete a project using what you learned.
    2. Share what you learned with someone else.
  4. Appreciate yourself for learning something.
  5. Repeat.

If that sounds easy, that’s because it is most of the time. I use this approach in my daily life for everything from plumbing to performance testing applications. Granted I will never be a master plumber (it just isn’t my calling) but I also don’t need to call one when I need to unclog a drain or replace a faucet. When it comes to computers and software, there is always something new to learn regardless of your level of mastery. This is part of the reason it is important to be an eternal student. If being armed with new tools and ideas isn’t enough to fuel your desire to learn, remember that once you stop growing you begin to become stale and obsolete. Don’t let your potential sit idle. Take the time and spend the effort to find out exactly what you are capable of. You might even find out that you can do anything you set your mind to.


I have never let my schooling interfere with my education – Mark Twain

Software Dance (to the tune of Safety Dance)

We can ship if you want to, We can leave your tests behind.
Cause your tests can’t pass and if they don’t pass, Well they’re no tests of mine

We’ll hide checks where we want to, places where they will never find.
And we can act like we planned it all from the start, leave the real spec far behind

And we can ship

We can ship if you want to, We can leave your tests behind.
Cause your tests can’t pass and if they don’t pass, Well they’re no tests of mine

We’ll hide checks where we want to, places where they will never find.
And we can act like we planned it all from the start, leave the real spec far behind

And we can ship

Francois!

Ah, we can launch when we to, the code is young and so am I
And we can demo real neat with new tools or a suite
And surprise them with a new UI

We can test if you want to, if we don’t nobody will
And you can test really good and be totally removed
And I can test like an imbecile

We can ship. We can ship. Everything is out of control.
We can ship. We can ship. We’ve committed to the date on the wall.
We can ship. We can ship. Everybody looks at the plans.
We can ship. We can ship. Everybody’s taking a chance.

Software Dance
Oh well, the software dance
Ah yes, the software dance
Software Dance

We can ship if you want to, we’ve got all your tests and mine
As long as we abuse it, we’re never gonna lose it
Everything will work fine!

We can ship if you want to, We can leave your tests behind.
Cause your tests can’t pass and if they don’t pass, Well they’re no tests of mine

We can ship. We can ship. Everything is out of control.
We can ship. We can ship. We’ve committed to the date on the wall.
We can ship. We can ship. Everybody follow the plans.
We can ship. We can ship. Everybody’s taking the chance.

Oh Well the software dance
Ah yes the software dance
Oh well the software dance
Oh well the software dance
Oh yes the software dance
Oh the software dance yeah
Oh it’s the software dance
It’s the software dance
Well it’s the software dance
Oh it’s the software dance
Oh it’s the software dance
Oh it’s the software dance
Oh it’s the software dance

Limbering Up QA: Adapting to an Agile Process

In the days of Waterfall, testers were seen as the guardians of quality and the protectors of user experience. They were the last line of defense to prevent a flawed product from being released. This meant that QA needed to have all of the requirements provided to them so they could prepare their tests for when the product was finally complete and they could begin their process. Sure, the deadlines were usually tight because the release couldn’t be moved and development ran long, but that was just part of thrill. QA were sometimes viewed as an obstacle rather than an aid, but they remained strong and provided their sworn services for client and company.

All of this changed with the dawning of Agile.

The once-powerful QA is now faced with shorter deadlines, stories instead of specifications, and seemingly incomplete features being submitted for test. Worse yet, the developers are encouraged to develop unit tests that automate a chunk of what the tester once handled.  How can we possibly work like this? It’s utter madness.

It may seem like madness and chaos, but there is also method and rhythm to be found in the new processes. The first step is to stop fighting the current and dive off the waterfall instead. After taking the plunge, testers can learn to navigate the flow of sprints and iterations. Granted, this is often easier said than done, but any habit can be kicked and new ones formed. It just requires time, effort, and a willingness to change.

Unfortunately, two out of three of those things are often not in the testers’ inventory, time and willingness to change. I’m sure that a number of those reading this might be offended by that statement, but bear with me. I know that no-one will argue with the time part, but everyone trips on the willingness to change. It’s natural for people to find a comfort zone and settle in. It’s also natural to be startled and scared by change. In my experience, testers are often leery of Agile because it seems to value speed over quality, but this couldn’t be farther from the truth. Agile places emphasis on quality but it is done by building it in rather than straining out errors after development.

This change in both thought and method is the key to producing software quickly without compromising quality. The catch is that it requires developers and testers to step out of their silos and work closely together. They should also include product owners and other stakeholders in their discussions to keep everyone aligned.

The idea is to inject the knowledge of QA from the beginning rather than waiting until everything is done. While this may sound like a pitch for TDD or BDD, that is only a piece of the picture. Sometimes, it is already too late for feature to maintain quality once it gets to development. This case is most often found with legacy modifications or a stakeholder pet project that seems “simple enough” but hasn’t been fully evaluated for ripples or pitfalls. This isn’t because someone missed  something. It is a result of their standard thought processes.

  • Developers tend to think in terms of “how can I make this work?”. They are focused on solving the puzzles.
  • Product owners focus on the value of the feature to clients. Most POs leave the technical concepts to the dev team.
  • Stakeholders are usually focused on how the feature will improve their positions or increase the company’s profits

When testers are left out of the planning stages, teams sacrifice an opportunity to reduce bugs and head off troubled projects before they are sent to development. A tester’s mindset generally includes looking at contingencies, interactions, and risks within a system. Even if the person doesn’t know the  system, asking the right question during planning can shine a light on a major issue that may have been glossed over, such as “Have we considered how the new shipping system handles an order including both physical and downloadable content?”.

After planning, QA should be helping to translate business process knowledge from the POs into paths through the software and tests for the new feature. A common method of doing this is by writing Given-When-Then (or similar concept) scenarios. These scenarios will then form a basis for both automated and manual tests used to confirm the functionality during development and prior to release.

In short, testers should make an effort to be involved throughout the project cycle rather than sweeping up at the end. By doing this they can help set the stage for successful projects and avoid the stress of being the roadblock or bearer of bad news just before release. While this is a major change, it is one worth embracing.