How to Become a Software Tester (QA Engineer)

Lecture 4 - The Software Development Life Cycle -> Quick Intro -> Idea -> Product Design -> Coding: Part 1 -> Coding: Part 2

In a nutshell, the programmer’s job is to translate ideas from the specs (or from other sources, like a brainstorming session during lunch) into the software code.

The translation can be made:

– either directly (i.e., the programmer takes a spec and immediately starts coding (BAD idea)

– or after creating the software design documentation. The software design documentation is a detailed technical description about how the spec requirements are going to be implemented into the software code (GOOD idea)

Two common types of software design documentation are:

– 1. System/Architecture Design Document.

– 2. Code Design Document.

An emerging culture of the creation and maintenance of software design documentation is the first sign that a start-up is converting from a bunch of dudes who write code into a serious software company.

Let’s proceed.

In an ideal case, each developer has his own environment (i.e., software/hardware combo) with a certain version of the Web site. This is called the “development environment”, “development playground“, “playground” or “sandbox”. The architecture of the playground imitates the architecture of the production environment. Here is a typical architecture of the production environment of Web-based application:

– Web server

– Application core

– Database

Let’s take a quick look at how these components interact with each other.

1. After the user enters https://www.sharelane.com into the address bar of the Web browser and presses the Web browser button “GO,” request to retrieve the default Web page of www.sharelane.com hits the Web server of sharelane.com, and in response the Web server sends this to the hard disk of the user:

– a text file index.html (https://www.sharelane.com/index.html), containing HTML code and

– an image file logo.jpg (https://www.sharelane.com/images/logo.jpg).

2. After the user clicks link “Enter”, HTTP request is sent to the Web server to launch Python script main.py (https://www.sharelane.com/cgi-bin/main.py).

Python script main.py belongs to the application core. That script generates HTML code that is sent to user’s hard disk via Web server.

3. After the user clicks link “Sign up”, HTTP request is sent to the Web server to launch Python script register.py (https://www.sharelane.com/cgi-bin/register.py).

Python script register.py also belongs to the application core. That script generates HTML code that is sent to user’s hard disk via Web server. HTML code generated by register.py includes Web form with text field “ZIP code” and button “Continue”.

4. After the user presses button “Continue”, form data (name of the field: zip_code and its value, i.e., user’s input into text field “ZIP code”) is passed through the Web server to register.py for processing.

5. If supplied ZIP code has correct format (5 digits), register.py generates HTML page with web form containing fields “First Name,” “Last Name,” “Email,” “Password,” “Confirm Password,” and a button “Register”. As we already know, that Web page is sent to user’s hard disk by the Web server.

6. After the user filled all fields, he presses button “Register” and request containing Web form data is passed through the Web server to register.py for processing.

Script register.py does processing and if everything is OK (e.g., email format is valid), it inserts new row into DB table users (Test Portal>DB>Data>users) and generates confirmation Web page about successful registration. As we already know, that confirmation Web page is sent to user’s hard disk by the Web server.

Programmers are primarily responsible for developing the code for the application core.*

*At start-ups the same programmers usually do it all: write code for the user interface and for the application core. Later, the company usually hires a special person, a UI developer, whose only focus is UI coding.

Later on that code will be given to us, the merciless testers, who know perfectly well all the main reasons why bugs appear in the software code:

a. Bad and/or changing specs

We just covered this.

b. Personality of developer

For example, a developer might be irresponsible, not caring, or just lazy.

c. Not enough programming experience

A developer can be a responsible person, but has no idea how to do programming right.

d. Neglecting coding standards

We’ll cover this next.

e. Complexity of the software

Many Internet projects are so complex that the brain of a mere mortal just cannot possibly predict all the consequences of the creation/modification/removal of a code.

f. Bugs in third party software

For example:

– bugs in operating systems;

– bugs in compilers and interpreters (the programs that translate software code written by humans into software code understandable by hardware; i.e., into 0’s and 1’s – we’ll cover this in a minute);

– bugs in Web servers;

– bugs in databases;

– bugs in software libraries.

g. The absence of unit testing

Unit testing is testing performed by the programmer himself. (The typical developer’s excuses: “Why should I look for bugs while we have testers?” and “I don’t have time.”). We’ll go over this.

h. Unrealistic time frames given to write code

We’ll go over this.

Below are the measures to help us enhance programming practices and prevent a substantial number of bugs:

1. Hire good people, and be prepared to give them a break.

2. Direct, fast, effective communication between coworkers.

3. Code inspections.

4. Coding standards.

5. Realistic schedules.

6. Availability of documentation.

7. Rules about unit testing.

8. “If it ain’t broke, don’t fix it.”

9. Being loved by the company.

10. Having “quality” and “happiness of users” as fundamental principles of the company philosophy.

Details:

1. HIRE GOOD PEOPLE, AND BE PREPARED TO GIVE THEM A BREAK

Hiring is a hard process because an interviewer communicates with a candidate for a maybe an hour or less and afterwards has to make a decision about both that candidate’s technical skills and personal qualities. The simplest and very effective determination about a candidate’s personality is this: that person must be excited about your start-up. If he is not, don’t hire him. The reason is simple: The start-up environment is about a gang of passionate dreamers who are sincerely excited about their product and willing to sacrifice their talents, time and efforts for the company. You don’t need sour, unmotivated folks in your team. It’s better to hire a motivated passionate beginner with the shine of inspiration in his eyes rather than a highly skilled jerk who will later contaminate the start-up atmosphere with his negative attitude.

Here is another thing. A new programmer in the company often doesn’t have enough time to get up to speed. As a consequence, he can write buggy code and/or screw up code written by others. That’s why it does make sense to:

– give time and tutoring to new developers;

– give new developers easy projects to start with.

2. DIRECT, FAST, EFFECTIVE COMMUNICATION BETWEEN COWORKERS

It’s very important to have this unwritten rule in any start-up:

“If you are asked for help, go ahead and help.”

Yes, there ARE situations when it’s not possible to interrupt your work; in this case, promise to get back to the person (and really get back!) or refer the person to someone else who can help. BUT in the majority of cases, it IS possible to spend several minutes with whoever asks you for help.

Now, let’s talk about what happens if people just ignore help requests.

Who is to blame in this situation? Actually, both the PM and the programmer.

The PM is to blame for failing to do his job properly.

The programmer is to blame because he:

– should have insisted on getting an answer from the PM;

– should not have done coding without a comprehensive understanding of the spec.

Here is a great quote from movie Ronin: “Either you’re part of the problem or you’re part of the solution – or you’re just part of the landscape.” So, let’s toast to being a part of the solution when we are asked for help!

Management must understand that it’s very important to help workers develop relationships with each other. One of the ways to do this is to have team-building activities. In my opinion, it’s much better to go hiking or play paintball once a month rather than get together every Friday and marinate everyone’s brains with alcohol. But, well, whatever works.

A technical aspect about communications is that each participant of the Cycle must be available for contact. Encourage everyone to publish their

– office, mobile, and home phone numbers

– work and personal email addresses

– instant messaging info

on the Wiki (you can find examples of these documents under Contacts in the Downloads section of qatutor.com).

3. CODE INSPECTIONS

Some programmers have this concept: “If I write code that only I can understand, then nobody will fire me.” WRONG!

First, anyone can be fired, including CEOs (thanks to corporate corruption in the U.S., we have many stories to illustrate this point).

Second, this approach is simply dishonest, because nobody forced you to work at the company; it was your decision to work there. So, if you agreed to work for the company, go ahead and do your best or leave if you don’t like it there*.

* If you are a consultant, then you usually have a specified period of time in your contract, i.e., three months, during which you must provide your services to the company. If you are an employee, then you’re usually expected to give two weeks notice before you can leave. Read all documents before signing!

To prevent “only-I-can-understand-my-code” behavior (which not only creates bugs, but also makes it harder to fix them), the company must have a practice for code inspections. This can be a weekly meeting when the manager of the programmers prints out the code of a random programmer and the latter explains his code to his colleagues. I doubt that the programmer would have an “only-I-can-understand-my-code” approach if he would most likely be asked at the meeting: “What the heck is wrong with your code, comrade?”

4. CODING STANDARDS

Code inspections have a great ally called “coding standards.”

Remember the story about building the Tower of Babylon, when everyone started to speak different languages? The consequences were really sad: people on earth got disconnected by a language barrier. So in order to communicate, we need to

– learn each other’s native tongue (very difficult if you have friends in many countries) and/or

– get a translator (costly and inconvenient for everyday use) and/or

– create some kind of standard (good idea!)

A similar mess like in Babylon happens at a software company if each programmer uses his own coding standard.

Coding standards can include:

– rules about comments

– naming conventions for classes, functions and variables

– rules about formatting

– and a HUGE PILE of other things

Needless to say, coding standards must be published on the company’s Wiki site, and every new developer must be referred to them. Coding standards must be adopted and followed in any software company that has more than one programmer. For a new company, it makes sense to start with a simple version of coding standards and then update them as the company grows.

5. REALISTIC SCHEDULES

When I was a child, my mother used to ask me to help her sort rice. As wild as it might sound nowadays, rice sold in the Soviet Union was not edible until you spent several hours sorting it before cooking. Even after I became quite proficient, there still was a speed limitation, after which I’d start missing things like little stones, so my family members would have to spit out my omissions during the dinner. Why am I bringing this up now? Every person has a limit, whether it’s about sorting rice or writing a software code.

If you create an unrealistic schedule, then either

– you won’t get what you wanted OR

– you’ll get what you wanted, but the result will most likely have poor quality.

This is exactly what often happens at software start-ups: developers are pressed to finish writing code in time, and while they do manage to produce the code on schedule, its quality might be really bad. Can we blame the developers? Of course not! We are all in the game called “start-up craziness” and unrealistic schedules are a part of our lives. Timing is everything, and we have to release our product and win users before our competitors do. That’s why the tester’s role in a start-up is critical – we allow the developers to move on to new projects while we are testing their OFTEN MESSY code. Like it or not, that’s the reality of start-up life.

The good news is that there are ways to ease up on the pressure of unrealistic schedules. One of the most effective solutions is this: before including spec into release, the engineering manager should ask the developer for a time estimate for coding that spec; i.e., how much time the developer thinks it will take to write the code. Having estimates from all the developers, the management can:

– rearrange projects between developers

– drop specs with less priority

– ask the PM to exclude some functionalities from the spec

Our only “hope” is that one day our start-up will become a big company, and everybody will be able to leave work at 6:00 pm. But, trust me, you’ll be missing those old good times when you were sleeping four hours a night but felt happy like never before!

6. AVAILABILITY OF DOCUMENTATION

ALL documents which are relevant to the Cycle, including the specs, spec change procedures, coding standards, test suites, etc.:

– MUST be available on the Intranet (e.g., by using Wiki)

– MUST be optimized for easy searching and browsing

It sounds simple and obvious, but if you don’t think about it, others will have to waste time and effort to access your documents.

7. RULES ABOUT UNIT TESTING

Unit testing is a test performed by the programmer against his own freshly baked code. I must stress two points here:

1. It’s very important to correctly create and introduce rules about unit testing. If you do it wrong, the developers will be really annoyed, because they are not paid for testing – we, the testers, are.

2. If we don’t have concrete rules about unit testing, then the cost of the bugs will be increased.

Let’s get back to unit testing. Here are two recommendations:

1. In the case of more or less complex/time consuming projects, e.g., a project dealing with important architectural changes with an estimated coding time of 5 or more days, unit tests should be created BEFORE the code is written. Then, when the programmer gets a new spec for coding, he doesn’t rush in to start coding, but first creates the code design document and the unit test document.

Please note that “document” does NOT mean some multipage, highly formalized document ready to be printed in the Journal of Computer Science. After all, in the start-up phase, timing is everything, so both the code design and the unit test documents can be short memos. However, the programmer must make sure that those memos are:

a. published on the Wiki;

b. easily understood by others.

The beauty of this approach is this:

– First, when the programmer abstracts himself from hands-on code writing, he has more intellectual resources to think about the “big picture”. This way the programmer gives himself a chance to predict – and hence prevent – mistakes in the future code.

– Second, the programmer will have to imagine HOW he will test his code, and that “HOW” will stick in his brain like a splinter. This way, the programmer will have a “quality guard” in his brain to monitor programming activities and thus prevent and catch bugs.

2. Requirements about unit testing must be formalized in Unit Test Standards. For example, there should be at least one test case for each Python function.

8. “IF IT AIN’T BROKE, DON’T FIX IT”

Every software engineer knows about cases where a perfectly working code becomes a nightmare after some “I-can-do-it-better” type of developer tries to improve it.

The problem that I’m referring to usually happens when a major chunk of the code is written and released; users are enjoying our product, and we can relax a bit from the craziness of the early start-up days. Some “I-can-do-it-better” type of developer (or any developer asked to do so by his manager) looks back at the old working code, finds room for improvement, and implements that improvement. And here come the problems!

You might be surprised, but situations like the above happen in software companies over and over again. And all because some folks cannot comprehend programming wisdom as old as the world: “IF IT AIN’T BROKE, DON’T FIX IT.”

So why should programmers think twice before changing an old code just to beautify it? The reason is simple:

The old code is usually part of the software foundation in which many pieces of old code and newer code have been heavily integrated, thus creating a complex net of dependencies.

So, when we shake this foundation, as a rule we simply cannot predict which part of the application is going to be affected. That’s why even a simple change in the old working code can have major negative consequences in totally unexpected parts of the software. This kind of effect is called “unintended consequences.”

Unintended consequences during a code change are the major reason we need regression testing.

So, remember that it is usually a very BAD idea to change working code just to improve it. Simply put: “IF IT AIN’T BROKE, DON’T FIX IT.”

9. BEING LOVED BY THE COMPANY

It’s really simple. Management should take care of people. Start-up employees are heroes, spending day and night at the office, working on their shared dream to create a super product and get rich. Management should reward them for their hard labor and dedication. Is it too much for the company to give a $100 gift certificate or an extra thousand stock options to the employee who finished some amazing project? Or is it really all that expensive to buy lunches for the employees at least once a week?

It’s human nature to get discouraged when work is not appreciated. I’m amazed that so many managers don’t understand this simple truth. Again and again, I hear stories about unfair financial treatment and the absence of financial encouragement. Who suffers because of it? Everybody in particular, and the business as a whole!

On the opposite end, companies where employees are treated fairly and encouraged to go above and beyond have MUCH more chances of creating a great product.

For a while I worked at the Plug and Play building in Sunnyvale, California. This is an incubator for new companies, with lot of software-related conferences taking place there. The tradition is that the speaker writes something on the wall on the first floor. What do you think one of Google’s managers wrote? “It’s all about the people.”

Yep, without this kind of attitude Google would have been a smart search algorithm, nothing more. But because founders Sergey Brin and Larry Page built their company on the principle “It’s all about the people”, Google is the most successful company in the history of software development. Let me list some of the things available to Google employees at Google’s Mountain View, California campus. Most of these things are FREE:

– 11 gourmet cafeterias,

– laundry,

– dry cleaning,

– oil change,

– car wash,

– gym,

– exercise classes,

– massage,

– Mandarin, Japanese, Spanish, and French classes,

– personal concierge to arrange dinner reservations,

– hairstylist,

– $5,000 toward environmentally friendly car,

– $500 in takeout food for new parents for first month at home,

– five on-site doctors,

– Wi-Fi-enabled shuttles from five Bay Area locations,

– breast pumps for nursing moms,

– heated toilet seats (!),

– requirement to spend 20% of work time for dream projects.

Source CNN Money, 01/05/2007

I forgot to mention that ALL pre-IPO employees of Google became millionaires, and several hundred thousand dollars is a possible bonus for a successful project.

I could go on and on about Google. Now you understand what I’m talking about when I praise Google as an employer that LOVES its employees!

I realize that Google is a rich public company, and start-ups don’t have such huge material resources. But think about this: each big company was once a start-up, and as we know, big companies very often suck as employers. So why is Google both a huge company and a great employer? Because both in Google’s start-up years and now, it’s always been all about the people.

Here’s what any start-up can do, even without Google’s resources:

– pay bonuses for successful projects; even $1000 is better than a moneyless “Amazing job, man!”

– provide free lunches

– provide free soda and bottled water

– provide free snacks

– reward with gift certificates or concert tickets

– give Christmas gifts like jackets with the company logo

– organize paintball parties, hiking, or rafting trips

– give promotions

– pay for memberships to a nearby gym

There are many options, and every dollar spent on employees can turn into hundreds of dollars, because people are basically good and we DO work better in exchange for management taking better care of us.

10. HAVING “QUALITY” AND “HAPPINESS OF USERS” AS FUNDAMENTAL PRINCIPLES OF COMPANY PHILOSOPHY

Management must make sure that everyone at the company understands that “quality” and “happiness of users” are not just abstract concepts but rather the way to success for the company, and hence a way to personal success for everyone who works for the company. If managers make fun of quality measures and make jokes about users (even during an informal chat!), it does real harm to the internal morale of the company, and in the end there will be negative consequences for the company as a whole and hence for those idiots-humorists in particular.

Users know whether or not they are respected after a single error message, email from the company, or call to customer support. And if the real philosophy inside the company is, “Our users are stupid,” then that philosophy will sooner or later be evident to users. Of course, this will be great news for that company’s competitors.

Our users are real people. They should not be perceived as a faceless crowd, but rather as friends who trust us and appreciate our hard work. Next ->

Lecture 4 - The Software Development Life Cycle -> Quick Intro -> Idea -> Product Design -> Coding: Part 1 -> Coding: Part 2