Improvement through practice

In music, the better you are at the basics, the better you are on the bandstand. Even the pro musicians I know practice almost every day. I think testers (and developers) forget the value of practice too often.

In The Passionate Programmer, Chad Fowler suggests doing the exercises on CodeKata. I checked them out, and sure enough, the Kata are great, and I plan to start working through them. A few years ago, I solved a bunch of problems on project euler as an exercise to keep myself sharp.

As a tester, it’s sometimes hard not to practice. As I interact with software, I often ask myself “what if” …then I try it and see what happens. But this is only “sort of” testing – it’s my tester DNA seeping out into my every day life.

I’ve been thinking about other ways to practice testing. I’m a member of uTest, but I haven’t taken the time to test anything. I suppose I could volunteer to test a non-profit’s web site or find a product I like to seriously beta-test – or I suppose I could look into volunteering a few hours a week in a MS product group.

How else do you practice testing?

GUI Schmooey

I answered a few questions this week about automating GUI tests. One question was about recommendations for GUI automation tools for non-coders, and the other was about how much time to spend on the GUI in an MVC (model-view-controller) application.

The answers were easy. In the first case, I said that they weren’t going to get ROI from the effort, and they should just test the GUI manually. In the second case, I suggested that they do all of the automation ignoring the view/GUI, and test the GUI manually.

I could expand an entire post on why I gave those answers, but it doesn’t matter. I’m going to go out on a limb and make the following statement.

For 95% of all software applications, automating the GUI is a waste of time.

For the record, I typed 99% above first, then chickened out. I may change my mind again. The point is that I think testers, in general, spend too much time trying to automate GUIs. I’m not against automation – just write automation starting at a level below(*) the GUI and move down from there. I’m not saying that you shouldn’t test the GUI at all – I just don’t see why you wouldn’t want to test it manually, and get people knowledgeable in user experience to help. I just think that in most cases we are wasting our time when we try to automate GUIs, and wonder if anyone has the guts to stop.

 

* What I beam by a “level below the GUI” is automation that works with IAccessible or an object model rather than interacting with UI elements directly.

The Test Test

I am always frustrated and somewhat sad when I hear testers whine or complain that they are not treated fairly; or that they are not respected; or that their development peers look down on them. I’ve been sitting on this post for many months wondering if I should post it or not when this thread popped up over on the JoS boards.

On one hand, I am always happy to offer words of encouragement and advice on how to rise out of the situation or at least to make the best of it. On the other hand, part of me sometimes wants to just say "stop your whining. If you don’t like it that much, quit and find someplace to work where you will be treated fairly and be respected!"

If you want to find a good testing job, you just need to ask a few questions. That said, with all due respect and references to Joel and The Joel Test, I give you "The Alan Test"

The Alan Test – aka "The Test Test"

  1. Are testers influential from day one of the project?
  2. Does the test team own their own schedule?
  3. Does the test manager report to the general manager (and not to development)?
  4. Are career paths for testers and developers equal?
  5. Do the developers value testers?
  6. Do testers have the same working conditions and resources as development?
  7. Do testers use good test case management and source control tools?
  8. Are tests built daily?
  9. Are automated tests and manual tests valued appropriately?
  10. Do testers have the same coding guidelines and rules as developers?
  11. Is there a culture of quality?

Details:

Are testers influential from day one of the project?

Notice that I used the word influential and not involved or even hired. From day one of the project, testers should be reviewing specs, giving feedback on schedule, and driving testability. The full test team doesn’t need to be on staff from day one, but someone should be there setting the quality bar early. If testers are not involved (or hired) before coding begins, the organization obviously doesn’t value test (nor quality for that matter).

Does the test team own their own schedule?

The test team should own their schedule and have influence on the overall product schedule. A one-week code complete slip cannot be "absorbed" in the test schedule. If the test team determines they need n days or weeks after code complete to finish testing, they need n days or weeks. Period. If the test schedule is also known as "buffer for the dev team", the organization doesn’t recognize the value of test.

Does the test manager report to a general manager (and not to development)?

Put another way, the test manager should be a peer of the development manager. If the test manager reports to the development manager, development needs drive test, and test has a lesser voice in the product.

Are career paths for testers and developers equal?

If test and development are indeed peers, they should have equal career paths. At Microsoft, we have "levels" that line up with promotions and career paths, and developers and testers have equal opportunity for promotion. Another way to ask this question could be "would you ever pay a tester as much as you pay your top developer?". Don’t fall for the paper trick on this point – as in "On paper, testers can grow as much as developers – look, we have documents". Ask for examples. "How many developers and testers are at your most senior levels in your org". If the organization isn’t willing to promote testers to senior positions, they don’t value test.

Do the developers value testers?

Ask if the developers see test as an ally in creating quality software, or as a gang of hooligans making their lives hard (or as a bunch of robots pushing buttons)? Testers don’t exist to make developers cringe or cry. In a good organization, developers understand that the role of test can be as much about quality assurance as it can be about quality control, and know that the test team exists so that everyone can make a higher quality product.

Do testers have the same working conditions and resources as development?

Would you want to work somewhere where developers had their own offices, dual 22 inch wide-screen monitors and comfortable chairs, while the test team worked in the hallway sitting on milk crates?

Me neither.

Do testers use good test case management and source control tools?

I once tested software on a laptop, in a car on the way to drop off the master for duplication (at least I wasn’t driving). I’m a fan of ad-hoc testing, but this was over the line (I don’t work at that company anymore).

Testing is a creative activity, but some structure around recording test cases and related test code is critical on a professional test team. A test case management tool is necessary – as is the ability to version test cases and test code. If the test team doesn’t value this, they probably don’t really care that much about testing.

Are both tests and product code built daily?

Automated tests (assuming they are compilable code and not scripts) should be built at the same time, and in the same process as product code. This is particularly important in situations where the test code calls APIs or other functionality in the product code, as it provides a small level of testing at build time (function signatures and other header resources).

Do testers have the same coding guidelines and rules as developers?

Put another way – Is test code treated the same as product code. If the test team is writing unmaintainable buggy code, you could hardly expect the development team to respect them. Test code is just as important as production code, and is in need of similar efforts.

Are automated tests and manual tests valued appropriately?

Does management have unrealistic goals of test automation, or do they devalue all manual testing? Unrealistic goals for automated tests indicate that management doesn’t understand testing well enough for you to want to work there. Similarly, if all automation is de-valued by management, this indicates that management doesn’t understand testing well enough for you to want to work there. Ask about the product and testing goals, then ask how automated and non-automated tests support those goals. Ask for examples of tests on that team that are automated and for examples of manual tests. If a team tries to automate too much – or not enough, it’s a sign that you probably don’t want to work there.

Is there a culture of quality?

Finally, you need to determine if quality is something the organization tries to test into the product, or if it’s something that drives everyone on the team. Do developers "throw code over the wall" to test, or are they embarrassed and apologetic when bugs are found? Are bugs fixed as they are found, or are they left to fix at the end. In order to meet schedule, are bugs punted, or are features cut?


Eleven simple questions. Eleven questions where I would bet the majority of the answers for many testers are "no". I wouldn’t work in an organization that scored less than 9. Sadly, many organizations are much, much lower.

Of course, if you know of an eleven, please let me know where to send my resume. :}