Software Quality Assurance: The Ultimate Setup

Alright, this time I'm going to get right to the gut of quality assurance and talk about the ideal kind of testing environment when it comes to software, big or small.

Firstly, what kind of project are you planning on building? Is it a website? A desktop application? A mobile phone application? Realistically, it can be any project so long as you follow these 12 guidelines.

1. Do you have source control?
       It's always good to have source control and especially for the type of test driven environment you're looking for it will be even better for running all of those tests.
2. Can you build your solution in 1 Step
       Most of us are using Visual Studio to build our projects but nevertheless you should be able to build your solution in 1 step whether it be building it for debug or compile and/or including deployment. It's a pretty common scenario where you want to deploy your solution immediately when you're done.
3. Do you perform daily builds?
       If you're working on a project that goes day in and day out of work you should ensure that you at least build once a day or at night to follow up tests and issues in the program.
4. Do you have a bug database?
       Bug databases are used for instant tracking of all of your bugs, whether automatically reported by the system or typed in by a user or developer on the team. It's very good to have one of these if you're working in a larger team. But even in a small team (like yourself) it can be pretty handy to organize everything into a simple database of bugs. Makes it easier to clean things off.
5. Do you fix bugs before writing new code?
       This one is tough if you're not working directly off test driven code. What test-driven code means is that for every feature or series of implementations you have written tests to ensure that all logic and implementations are valid or work according to a standard. Think of test-driven development as writing the model that you want your project to become and the code that you are writing to be tested against are the drafts to the sculpture.
6. Do you have an up-to-date schedule?
       What are you working on? What needs to be done? Who's working on what? Try not to think of schedules as some mundane constraint who's only use to keep the manager out of your hair. Schedules are incredibly valuable tools for time management. They teach you to manage your time wisely and keep you from working day in and day out on a silly problem that may mean nothing in the long run. In our industry we are too often thinking about the how and the what-if scenarios of software development but we rarely take a step back and ask whether or not we should do something rather than if it's possible.
7. Do you a specification?
       If you're working on something that other people are going to be either working on or integrating with, please please please for the sake of all time and humanity, write healthy comments and anything else that will help people understand how to work with said system. Tutorials, samples, anything that relates to your system is really helpful for others to use their time just as wisely and timely.
8. Does your team have quiet working environments?
       I know, you're thinking, "Wait a minute. What does quiet working environments have to do with software quality assurance." Well believe it or not, but a quiet working environment is basically a large white board to the mind of a developer and a tester. It ensures that not only can someone hear their own thoughts, but as a team it makes it easier to discuss and collaborate without disturbance.
9. Do you own or use the best tools money can buy?
       Better tools, newer technologies anything that can aid you and speed up your time in development or your goals is far more useful than ever, especially to your users who are so eager to see what you've come up with.
10. Do you have a group of people or person who's sole purpose is to write tests?
        This is more so for larger groups, in small groups you will be the tester and as a developer it's best practice to get in the habit of testing your own code before hand.
11. When you have new people on the project, do you have them write code before joining the team?
        Usually it's a great idea to have the person you're interviewing actually write code related to what you're working with or what you plan to have them working with. Sometimes it doesn't really have to be a test of knowledge but to allow the person to get a feel for the code that he/she will be working with and it allows you to adapt to whatever practices or standards he/she may already go by.
12. Do you perform hallway usability testing?
        Hallway usability tests are done by simply taking your laptop out into the hallway and showing what you've made. It's a great way to get suggestions and get other people excited about your creations. It's a great motivator if the people you test give back constructive criticism. And if you've followed the above guidelines this step should be no problem because you'll never run into a situation of a useless feature or a bug. You can explain it with confidence and passion!

What do I use for my test-driven quality assurance setup?

1. Subversion Web: I try to always have a subversion setup that I can access via the web. These are useful for the fact that most of them have wikis for documentation and logs that come from subversion. It makes it especially easier for deployment since I can just create a release from the website.
   I've been using: unfuddle lately. I think it's great!