5 Thoughts on Testing Software

Testing newly developed software may sound like a simple task since it is making sure that it meets the requirements, works as it was designed for, and can be implemented in that way. However, there is an art to testing; it is more than following test scripts and the happy path. The real adventure is finding out how things work; not what the screen should show.

One has to understand the business and processes in which the software lies in order to put it through the paces. If you do not it will make knowing what to test for and how to test very difficult. Testing does not just make sure a button works but that the software can be molded around the needs of the business.

Points on Testing:

• Think about what the user should do or what the screen is designed for. Do the opposite. Does the software allow the transaction to happen? If so, it may be a defect. 
• Do not just assume something works. Keep checking the functionality. If you are testing across multiple revisions regressed functionality may occur.  
• If the user does steps in the wrong order does an intelligible error message pop up? Displaying error messages the end user can understand will enable them to help themselves figure out the problem. 
• Think about the process. Does it allow me to go back and forth from one screen to the other? Sometimes we need to add additional functionality. After it is added, does that back button still work? 
• If your software runs on a browser does it work across multiple browser types and versions? This may not seem like a big deal but when developers are writing for IE8 and IE9 but you are testing in IE7 it can make a big difference. Which brings me to - are you testing with what the end users use? 

Thinking through these scenarios and possibilities will help you uncover the "hidden functionality" in your software as well as ensuring its usefulness for the business.

3 Things to do when Blocked at Work

There comes certain times when, as a business analyst, you become blocked. It may be due to waiting for the developers to finish programming. It may also be that you are waiting on a fix for a defect that is preventing you from continue testing. However, these scenarios don't mean that you are totally stuck, leaving you only to surf the web.

3 Things you can do when Blocked:

• Let people know you are blocked! If people are aware that you are stuck, they usually make it a priority to help you out. 
• Ask other functional people on the team if they need help, such as trainer for materials, or the quality guy. Asking people on your team that work in different roles is a great time to learn about the other aspects in the software development life cycle.
• Read a book that is in your area. This could be about the industry you are working in, your role, or the work methodology currently being used for the project.  

How to Talk to People and get Your Point Across

http://bit.ly/n5tJgV

As a business analyst, one has to be able to communicate effectively with people on the business end and developers. Today's post is about my experiences communicating with developers.

I work a lot with developers and it is easy for them to dive into the realm of database terms and disposition lines. Yes, I understand that the database works in this way and that the software was coded to work a certain way, but to meet the requirements bugs need to be fixed. Normally these conversations come up when I've found a bug in the system; I need to explain why it is a bug and how the software should work. Keep in mind that multiple developers may work on the same piece of code, sometimes without even knowing each other. Other times the functional team doesn't think of all the possible outcomes until they start to see the software coming together.

Either way, here are some things I learned for explaining requirements or bugs to developers.

• It is your job as representing the business to say what needs to be displayed. It is the developers job to figure out how. (Told to me by a developer)
• If you're trying to explain a requirement and get stuck get backup! Ask another functional team member who knows the requirements to clarify what you're saying.
• Don't let dev talk confuse you or bring you down.
• Be confident when explaining the defect. Having examples and being able to reproduce the problem will help.
• Put the bug in a "compliment sandwich". Showing that you appreciate the good things about the system can help the developer not become defensive about an issue.

What it Means to be a Consultant

I've been a consultant for my first client for nine months now. Atos hired me in January for a special case; a large scale IT project involving a brand new state of the art manufacturing facility where I have to work in a cross functional team composed of IT, Production, engineering, quality, etc.

I was living in Ohio at the time but taking the job would require me to move to Washington state for a year. I had never been to the west coast and having the title Business Analyst sounded awesome to me so I took the job. A couple weeks later, after meeting some fellow consultant co-workers, I hopped on a plane and moved to WA.

At the time I didn't actually understand what it meant to be a consultant. I figured it would be like any other job except that we'd be working at the client site. What I've learned is that yes, we are given work items, but that is just the starting point. We need to be able to understand the whole picture. The client is our customer, we're not there just as work horses but to be able to help them make sure they're going down the best path.

My title may be business analyst but I help out in development, training, and quality control. I've gotten to know the people who work on the project and what their special interests are.

Here are some insights I have gathered on being a consultant:
* You are providing a service
* Make the client look good, "we all need to have our foot in the door"
* Work together with the client; find a mix between providing input and telling them how to run the project.
* Add value - don't just be a wall flower!