Was an Outlier Born That Way?

Malcolm Gladwell writes about people of great measure in their respected fields in his book “Outliers.” He talks about the numerous things that may affect the reason that a professional athlete or violinist is so good at what they do. He has come up with the 10,000 hour rule stating that if someone puts 10k hours of work into something, they can be an expert. What I want to know is whether I too can be a professional basketball player if I put 10,000 hours of work into it, or are there some people who are more predisposed. Bill Gates and Steve Jobs have both commented on the fact that they were in the right place at the right time. Clearly, these two are some of the better known outliers in the world. So, with enough work, can I be the next Bill Gates?

A few years ago, I was flying to Colorado for a cross-country race. In the pocket on the seat in front of me was a magazine featuring an article about a man aspiring to be a professional golfer. He commented on a book written by Malcolm Gladwell and stated that he wanted to put it to the test. He quit his job and decided to spend the time he could playing golf. In the article, this man’s mother commented negatively on the habits of his son. The comments were along the line of, “He hasn’t finished anything in his life before, I am surprised he is still going.” Early on while reading this article it was clear to me that this man didn’t have the background of a professional athlete. He didn’t start playing the sport at a young age. He didn’t have a golf ball in his crib (that’s just good parenting). The article did not state whether he went on to play professionally, but it did state that he improved his gameplay within the first year tremendously. After another 5-10 years he may have been able to go pro. After all, golf is an old man’s sport right?

So, back to the question at hand. Is an outlier born an outlier? I say no. I remember running the mile in gym class in 3rd grade. The margin was fairly small between my peers and I. It wasn’t until my senior year of high school that I truly became an expert of the sport. It took me almost 10 years to get to the point where racing and training was second nature.

In the world of testing and quality assurance I think that millennials have been putting in hours without meaning to. Millennials have been growing up surrounded by technology that no one told them how to use. They have been developing the tools that one would need to notice that there is something wrong with the program they are using. Outliers are not born outliers. They may be naturally better at certain things but time will make someone an expert. Millennials have become experts in technology testing without noticing it. Who is willing to put it to the test?

 

Creating My Very Own ArrayAdapter

If you are new to Java in Android Studio, you may have tried to drag a button into your layout file. When you try to run your program the button doesn’t do anything. That makes sense, you didn’t tell the button to do anything ‘onclick’. The same thing is going to happen when you add a ListView to your project. You know, the thing that lets you see the same thing over and over again with different data inside?

Today, I’m going to talk about my experiences using ArrayAdapters. As software developers know, there are many different ways to write code. So, this is the variant that I chose this time around. My experiences are going to be done in Android Studio developing for an Android Application.

Creating a basic non-Custom ArrayAdapter

When creating an ArrayAdapter inside of an Activity it is very simple. By this I mean that the there are very few lines of code and there is limited functionality. For example, displaying a checkbox and a TextView requires a custom adapter.

Create the array of items.

There are many ways to create/gather an array of data but this is the way that I have chosen.

String[] items = {"Milk", "Bread", "Sandwich meat", "Sandwich cheese","Pickles", "Mustard", "Mayo", "Water"};

In this example, I have created and array of strings called items.

Call Your Method

This is super simple. In my example, I have chosen to call my method populateListView(); Call this method inside of the onCreate Method to call it when the Activity starts.

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_item_list);

    populateListView();
}

Initialize the Adapter

Next, we need to initialize the adapter. In other words we need to make a new adapter.

ArrayAdapter<String> itemsAdapter = new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1, items);

 Attach the ListView to the Adapter and Set the Adapter

Now, we need to tie the ListView to the Adapter so that we know what element to populate.

ListView listView = (ListView) findViewById(R.id.listViewMain);
listView.setAdapter(itemsAdapter);

Now there are only two files that we need to create/edit to finalize our work. These are the layout files. The first one is going to contain a ListView inside of a Linear/Relative Layout. The second is going to be a TextView  without a Linear/Relative Layout. Make sure the layouts are referenced correctly when initializing the adapters.

Creating a Custom ArrayAdapter

Now we are going to try to create a Custom ArrayAdapter. This is going to allow us to customize the item layout in any way we want. For the sake of this example, I have added a checkbox to our item layout.

I am going to talk about what is different from the Basic ArrayAdapter that way we do not duplicate too much code. Things that are going to remain the same are the first layout xml file, the way we create our array, and the way in which we call our method. The second layout file is going to be slightly different as well. We are going to add the checkbox and make sure the entire file is now inside of a Linear/Relative Layout much like the first layout.

There are going to be one new file that we need to create. In our situation I have called it ItemAdapter.java.

public class ItemAdapter extends ArrayAdapter<String> {

    public ItemAdapter(Context context) {
        super(context, 0, new ArrayList<String>());
    }

    public void setItems(List items) {
        addAll(items);
    }

    @Override
    public View getView(int position, View view, ViewGroup viewGroup) {
      if (view == null) {
        view = LayoutInflater.from(getContext()).inflate(R.layout.item, viewGroup, false);
      }

      TextView textView1 = (TextView) view.findViewById(R.id.textViewMain);
      CheckBox cb = (CheckBox) view.findViewById(R.id.checkBox1);
      textView1.setText(getItem(position));

      return view;
    }

}

We are going to use this file to populate the items in the ListView. We are going to tell it what data we want it to use (the array that we created) and then we are going to tell it what layout to talk to. In this situation we are going to talk to the layout item.xml. In specific we are going to talk to the TextView and the CheckBox with their respected ID’s inside of this file. We do not need to do anything with the checkbox yet but we are going to setText for the TextViews based on their position.

private void populateListView() {
    String[] items = {"Milk", "Bread", "Sandwich meat", "Sandwich cheese", "Pickles", "Mustard", "Mayo", "Water", "Paper Plates", "Paper Cups", "Paper Towels", "Cleaning Spray", "Plastic Forks", "Plastic Spoons", "Yogurt", "Pop Tarts", "Coca Cola", "Chips", "Coffee", "Coffee Filters", "Cereal", "Crackers"};

 List<String> arrayOfItems = Arrays.asList(items);
 ItemAdapter adapter = new ItemAdapter(this);
 ListView listView = (ListView) findViewById(R.id.listViewMain);
 listView.setAdapter(adapter);
 adapter.setItems(arrayOfItems);
}

As shown above there are some changes to the Activity. We are now going to reference the array we have created, create the adapter, find the view by its ID, tie the adapter and the view together and setItems. These items are going to be Strings in this situation. If you would like to, you can make them an Object. For this example this is what works best.

Are you the slow one?

Do you keep getting the question of, “Are you done yet?” from your coworkers? If you do, please close the tab with Facebook open and read this.

In school, taking an exam can take a couple hours. The professors give you 2 hours and they say, “Take all the time you need.” So, naturally, you take the entire 120 minutes. You check over your work a dozen times and make sure your student ID is written correctly. In your mind you don’t want to turn the exam in until you absolutely have to. Unfortunately, I would recommend not doing that in the real world of Software Engineering and QA Testing.

Much like the professor, your boss is going to give you an allotted amount of time for a project. Let’s say in this situation it is 2 weeks. You know it isn’t going to take 2 weeks to actually complete the entire project. So, get it done early. You want to avoid your boss asking, “Are you done yet?” What you want to hear is, “Wait, you’re already done?”

My goal when working on a project is to make sure I am always ahead of the game. I never want anyone to wait on me to finish something. Small fixes/testing can be completed quickly and should be.

Being the slow one in the office is not always a bad thing. Just make sure you aren’t blocking Jill, Ben, AND Simon on their work too. The last thing you want to do is mimic the timeline of a government run project (i.e. roadwork).

Is this a good question?

Quite possibly the worst question to ask a developer is, “What am I testing?” Some other really bad questions are: What does the app do? How does this work? Am I supposed to be able to do this?

These are unhelpful questions. Asking questions is good, but only questions you can’t figure out by trying the software yourself. Asking how something works can be a good question, but only when you are asking what calls a client makes to an API. Being more specific lets you use the information to test in a particular way.

Understanding the software like it is your own is important. You want to know why things are happening but you also don’t want to draw the wrong conclusions. After all, the developer hired you to find the bug, not fix it.

For example, if someone starts typing on their keyboard when they get to the office and nothing is showing up on the screen, they are going to assume the keyboard is broken. They may go to the local Best Buy, buy a new keyboard, and plug it in quickly figuring out the keyboard wasn’t broken at all. In conclusion, the USB port was broken not the keyboard.

A tester needs to know what to try and when to try it. If 10 people use an app, it may not ever break but if 10,000 people use an app, it will for one of them. Someone is going to have an iPhone from 2008 that doesn’t like the mobile version of the website. It is the testers job to ask the questions that give them the insight into whether the app can handle certain things.

You need to make sure the questions you ask can be answered incorrectly. As explained in Monday’s post, the developer is going to assume that his code works. It is your job to figure out what can and will be wrong and prove it to be true or false. You want to ask a question like, “What happens when I enter 3,000 characters into the username EditText with special characters, letters, and numbers?” or “What happens when I tap ‘Pay’ 10 times in one second for this in-app purchase?”

Being a tester is about finding the areas of the app that need to be fine tuned. Sometimes, you need to test functionality but most of the time it is all about finding the features that don’t work when you do something the developer didn’t account for.

“Is this a good question?” is in fact not a good question. You want to think more along the lines of, “What does a good question look like?”

Don’t trust the developer.

Every developer assumes the code they write is going to work perfectly. I would know, I have made that assumption too many times.

As aggravating as it may get, the computer will always do what you tell it. Every once in awhile you will spool up a program and it seems to be flawless. Every feature is working as you intended. The software is working flawlessly on your devices in the office. So, you decide to show it to your boss. You are super excited to see the look on your boss’s face when he launches the application, and then it happens.

Your boss spent 3 minutes fiddling with the app and he already broke it, but you can’t even figure out how to recreate it. Most likely, your boss did something you never tried on your dev machine because he interacts with technology different than you do.

Throughout high school, my teachers always told me to make sure I knew my audience when writing a paper. It turns out teachers are right sometimes. This is not a cookie cutter situation though. I’m not writing to a school board about the lack of parking spots for sophomore students. Most likely, your application is written for an unknown user type.

The first thing I do when testing software is getting familiar with the product and the users. Knowing what the app does is very important. Will you be interacting with an API? Will there be in-app purchases? Can the users interact with each other? Each question will result in a different method of testing. Knowing what user type is already using the app is also very important, but not for the reason you would think.

The second thing I do is take everything I know about the app and assume it is broken. Then I try to find out where it is broken. This is where you do NOT trust the developer. If they told you the application can only make an in app purchase if the user has a credit card on file, try making a purchase without a user.

Make sure the developer doesn’t do your job for you before you even start testing. In that case, he shouldn’t have hired you in the first place.