Can developers QA their own code?

Been really busy with everything and can't believe that it's been like two years since my last post.

So here's the thing, a lot of managers wonder should they have developers write more tests for their code or should they invest more in hiring QA's? In my experience I've worked in environments where developers write absolutely no tests of any kind (unit, user behavioral tests) and on the opposite side of the spectrum where developers write tons of tests whether it's unit tests or following TTD model and writing tests before coding even begins.

Does it help overall quality of the code? Does it save QA's time? Is it worth investing in?
Dev testing is defiantly worth implementing into your SDLC but should not over heavily be relied on. I do believe having unit tests is a good thing since a lot of tests with different state transitions could be tested much quicker by devs as apposed to manually generating users events by a manual tester performing regression testing. It defiantly saves QA's time by having dev do a basic end to end test on a client that a customer would be using. I can't remember how many times I've seen a feature be so badly broken that I would have to log bunch of bugs, wait for them to be fixed then spend time verifying. In these cases it should not even made to QA. All of this takes longer to ship product to end user and usually add to dev time and easts through QA's. So why most developers are not so effective testing their own product? Here are my takes on the subject.

Emotional Connection
1. When a developer writes code to implement a feature there is some kind of connection between with their code since it's their baby project that they just created. Writing code also represents the logical decisions one makes so it's hard to be objective to those decisions.

Rails: Understanding Models, Views and Controllers

Here is how I understand how rails work, high level. And I was able to find this great diagram.

The browser makes a request, such as http://leonidpekker.com/picture/show/13



The web server (mongrel, nginx, unicorn etc.) receives the request. It uses Routing System to find out which controller to use: the default route pattern is “/controller/action/id” as defined in config/routes.rb.
In our case, it’s the “picture” controller, method “show”, id “13″. The web server then uses the dispatcher to create a new controller, call the action and pass the parameters.

Controllers do the work of parsing user requests, data submissions, cookies, sessions and the “browser stuff”. They are like a bossy manager who tells their employees what to do. They give orders without knowing (or caring) how it gets done. In our case, the show method in the video controller knows it needs to lookup a picture. It asks the model to get picture 13, and will eventually display it to the user.

Models are Ruby classes. They talk to the database, store and validate data, perform the business logic and otherwise do the heavy lifting. In this case, the model retrieves picture 13 from the database.

Linux Directory Structure

Have you wondered why certain programs are located under /bin, or /sbin, or /usr/bin, or /usr/sbin?
For example, less command is located under /usr/bin directory. Why not /bin, or /sbin, or /usr/sbin? What is the different between all these directories? In this article, let us review the Linux filesystem structures and understand the meaning of individual high-level directories.

1. / – Root
 Every single file and directory starts from the root directory. Only root user has write privilege under this directory. Please note that /root is root user’s home directory, which is not same as /.

2. /bin- User Binaries 
 Contains binary executables. Common linux commands you need to use in single-user modes are located under this directory. Commands used by all the users of the system are located here. For example: ps, ls, ping, grep, cp.

3. /sbin – System Binaries 
 Just like /bin, /sbin also contains binary executables. But, the linux commands located under this directory are used typically by system aministrator, for system maintenance purpose. For example: iptables, reboot, fdisk, ifconfig, swapon

4. /etc – Configuration Files
 Contains configuration files required by all programs. This also contains startup and shutdown shell scripts used to start/stop individual programs. For example: /etc/resolv.conf, /etc/logrotate.conf

5. /dev – Device Files 
 Contains device files. These include terminal devices, usb, or any device attached to the system. For example: /dev/tty1, /dev/usbmon0

What makes a great QA!?

Recently as we did some QA hiring and it was really tough to find an good replacement for someone that had left the team so I started thinking on what it takes to be an AWESOME QA?

1) You should be a 'Know-How'
Not only you have to know the product inside and out you have to be a know how all around. Let me explain. As a QA person you are sort of positioned in between many teams such as product, marketing, development and other business owners. You are a company advocate as well as customer advocate. For you to be on top of the game you need to know what each of these people value and trying to achieve. Spend time with other teams to learn what they do and how they breathe. This will position you in a very good place. I've spend hours talking to developers about bugs and tried to find out what the issue is and what caused it and try to remember it all. Later I will explain more benefits of this. I spend hours talking to IXD people and they are super awesome. I've learned a lot from them as far as how things should look like and what customers would expect to see. I always take them in consideration when I test a product. Same goes for customer service people, analytics etc.. Spend time with them you will learn a lot and it will make a better QA I promise. Learn, Learn and Learn!
2) Know the application
I don't know how much time I spend learning the application that I work on. I get shocked when I find out that half of our development team don't know more that 30% of our application. I mean I really get it. A lot of times they are working on an isolated chunk of code and don't need to know how other parts of the site work. We QA can't afford that. I do end-to-end testing and for me to be able to do that I have to know our app inside and out. Again talk to developers and product managers get to know the application as much as you can and never stop learning. If you want to be a kick ass QA you will know how the app breaths. In time you want to be the subject matter so developers will go to you with questions and you will be well respected.

3) Hyper-Sensitivity to Little Things
QA have to be super sensitive and aware of potential bugs that might show symptoms. A lot of times I test the app and I just sense that something does not feel right but can't really figure out what. I will trust my hunch and it never lets me down and certainly after some time I will find that glory bug. A lot of times developers miss certain things that are not so obvious and QA has to be sensitive enough to notice all the little things that might be bugs or potential bugs like a sore throat before getting a cough. Anything at all out of the ordinary is worth pursuing.

Using Selenium to capture screen-shots and save them to dropbox

I am going to share a small piece of code I use for screenshot capture in Selenium RC in Ruby.
First I wanted to set this up on my machine and on a mac mini that I use at work so I had to figure out a way to detect the os since the file path is different on a mac vs pc.

def is_mac?
   RUBY_PLATFORM.downcase.include?("darwin")
 end

 def is_windows?
    RUBY_PLATFORM.downcase.include?("mingw32")
 end

Code:

file_path="C:\\Users\\Leo\\Dropbox\\QA scripts\\Screenshots\\" if is_windows?
file_path="/Users/administrator/Dropbox/QA\ scripts/Screenshots/" if is_mac?

After that I wanted to make sure that the files are saved will consisst the name of the
test-case + date and time so I will know later which one is which. Here is how the magic happens.

@selenium.capture_entire_page_screenshot("#{file_path}NameOfTestCase#{Time.now.strftime("%Y-%m-%d_%H%M")}.png", '');

Testing vs Quality Assurance

One interesting fact that I often come across working in startup environments that a lot of people I work with do not know what software quality assurance is all about. Usually it includes co-workers without technical background. People say ‘testing’ is easy and anybody can do it. That is not necessary true in my opinion.  In this first post I would like to talk about the difference between testing and quality assurance and go in specific details between the two.

What is Testing?  Testing is about finding bugs not preventing them. It does not necessary have to have a process or any specific methodologies. It could by just simple as doing ad-hoc testing or looking for bugs against the requirements if any exists.  A lot of times you are essentially looking for bugs that are already there, you are not necessary preventing them.