Evaluating workers, skills Vs traits

How do we evaluate our employees? We know the traits we value in employees, but which traits are more important and which are less? Through gut feeling we may feel that trait A is more important than trait B, but how does each of them translate into day to day performance?

In this post I will discuss a rather cool method we have developed for determining which traits are the most important for an employee to posses, how to evaluate employees and more. The first steps are rather obvious, but starting from the third step it's getting rather cool. Trust me.

Some time ago, I had a conversation with one of my Team Leaders, regarding the needed skills and traits for a QFO (QA Feature Owner). We made a list of the traits we valued the most and wrote them on a whiteboard but then the calender reared its ugly head and we were forced to stop and vowed to resume the session "soon".

"Soon" turned out to be some six months later. When we met again, were no longer two people in the room but six, as I asked other leads from my team and two HR to join the party. After a long discussion we decided that our way for evaluating our employees will consist on the following phases:

1. At first we decided what are the needed skills the QFOs needed. The skills we decided our QFOs need are:

• Task planning
• Task duration assessment
• Synching other interfaces
• Reporting
• Following up on features
• Context switching
• Task prioritization
• Problem solving
• Specification document analysis
• Writing organized test documents
• Effective test coverage
• Good test prioritization
• Bug hunter
• Organized bugs
• Through bug analysis
• Bug prioritization
• Etc' (this post is not about the skills required to be a good QFO)

2. After we were happy with the skills needed, we set about writing down the traits we thought good QFOs should posses. The list we came up with was something like this:

• Fire and forget
• Broad vision
• Self driven
• Self improving
• Passionate about the product
• passionate about QA
• Technical skills
• Organized and thorough
• Businesslike (practical, focuses on getting things done instead of ego games)
• Critical thinker
• Creative
• 
  

So now we have two lists, skills and traits. Now we put them in an excel table, with traits being columns and skills being rows:


3. And now the cool stuff begins. In the next phase we marked each box in which a trait and a skill intersected. For example, Task Planning requires a QFO to have a Fire and forget attitude, posses a Broad Vision of the team's goals and be Self Driven. So we marked those intersection boxes with 1's. Self Improving, on the other hand, is not especially important for Task Planning so we left that box empty. We proceeded to fill the table until it looked something like this:


4. In the next phase, we summed (in the last row) the number time each trait was used:



Looking at the last row, we see that the three most important traits for a QFO in our organization are being Organized and Thorough, possessing a Broad Vision regarding the company's goals and being a Critical Thinker. We know that they are important because they affect the largest amount of skills we defined as important for a QFO's daily work.

Next post I'll do more fine tuning and show how to use this method for evaluating employees and giving them more effective feedback.

The role of QA in a Continuous Development environment

One of the challenges we, as a QA organization, face in a Continuous Development environment, is that the "old" definitions of QA are no longer valid for us. We are not the "gate keepers". We do not give a "green light" or "Go-no-go" signals. Why? Because if we want to deploy a new version with new features on a daily basis in production, we need to move fast and repetitive dev and QA cycles are a huge overhead.

In the following bullets I have summarized the challenges our R&D organization faces and the way we in the QA team should tackle those challenges.

• What do we want to achieve?

o We want to release features as soon as they are ready, regardless of other features’ readiness.

o We want to keep the time between the developer starts coding and the feature is deployed in Prod to a minimum.

• · How are we going to keep the development cycle short while releasing on a daily basis?

o Reduce the amount of “links” in the release chain – only one person (FO, development Feature Owner) will be needed to take a version to Production (no dev->QA->dev->QA->OPS->Prod, but instead only dev->Prod)

o Reduce the overhead of Dev/QA interaction. This overhead is bearable when releasing a version every two weeks (if the QFO (aka tester in some organizations) is stuck she can do something else) but becomes unbearable when releasing on a daily basis (if the QFO is stuck, no QA work is done and as result the whole process is stuck).

• · How are we going to reduce the number of links in the chain and reduce dev/QA friction?

o QFOs (testers) will no longer be a “required phase” for releasing the version. Instead, QFOs will now specialize in providing tools for the development Feature Owners to verify that the released version is of high quality. If the QFOs provide high quality tools and the FO uses them properly, the version will reach production in high quality.

• · What tools will the QA provide for the FOs?

o Critical review of Spec and Design

o Test cases

o Automatic tests (where the QFO is able to code automation)

o Exploratory tests once the feature reaches production

• · Who does the actual testing? It depends:

o Automation can be written either by the development Feature Owner or QA Feature Owner, depending on availability and proficiency in automation coding.

o High priority manual tests are usually performed by FO. QFO assists when needed.

o Low priority tests are QFO domain

o When a feature reaches production, after it is deployed, QA run exploratory tests on it, to see if we missed anything

• · Who owns the quality?

o FO owns the quality of each release. The FO bases her assessments of the release quality based on the tools provided by QA.

§ Why can’t QA own the quality of each release? Because if the QA is to own it, we will need time testing it and this is the exact overhead we’re trying to cut out.

o QA owns the general quality of the application. They are required to reflect the quality of the application to decision makers and help them focus the bug fixing resources on the most painful areas.

Our CEO, having seen the above bullets in an email thread, challenged me and asked: "so if you guys are not doing the testing and not the owners of quality, why do we need QA?". Fair question, to which I gave the following reply:

Why do we need QA?

• (Most) developers don’t write good tests.

o Developers tend to think positively instead of negatively. The tests that they will write will make sure that the feature works where used properly, but will not find where it breaks.

o QFOs usually have broader view of the system and see interactions between components developers tend to neglect when designing tests.

• QA still owns the quality of the application end to end.

o QA is responsible for examing all the exiting problems in the system and generating relevant heat maps that will serve decision makers when deciding resource balancing between developing new features and fixing bugs.

o Even if developers test their features perfectly without QA assistance, QA is needed to reflect whether the experience is good. Are the response times reasonable? Is it easy (not only possible) to register? Is the newsfeed interesting (instead of merely working)?

o QA is still the team to ask “what is the quality of the our offering?”

• I believe that QFO can also take ownership of automating the tests, as we see in some cases. Developers will code the feature and QFOs will code the tests and hand them to the developers.

Prioritizing and automating tests

After choosing an automation platform and methodology, one of the greatest challenges QA/automation teams face is deciding what to automate and defining test priorities for automation. In Delver initially we asked QFOs for lists of Test Cases (TCs) to automate. The QFOs were supposed to compile lists, send them to Automation Lead who would review the TCs and allocate them to Automation Engineers (AE) to automate. In order to monitor this process, I used to measure the amount of automated tests Vs total TCs in the system. The amazing thing about this procedure was that it managed to frustrate everyone equally:

• The QFOs kept feeling that hunting TCs in the system for the automation team was a time consuming burden. It was reoccurring task and often the AEs rejected the selected TCs for low ROI in automation.
• Secondly, QFOs discovered that the regression tests that were needed for each version were not the ones automated. This was due to the fact that when the automation team were assigned TC to automate, the assigned cases were not correlated to any specific version, just arbitrarily selected from the TC pool.
• The automation engineers did not manage to increase coverage rates. When comparing the automated cases to the TC pool, despite all the efforts, the impact was slim, and it was rarely over 35% coverage.
• We also found out that of all the team in Delver R&D, the QA automation team were the only team who did not feel part of the release cycle. Their output was not correlated to any specific version or content and they slowly became "those dudes" who came in the morning, wrote a bunch of "automation things", and went home in the evening.
• I became frustrated myself, seeing my talented automation engineers slowly drifting apart from the rest of the QA team, doing "their thing" without being able to relate to what everyone else was doing. Their feeling of belonging was waning slowly.

So we changed everything. Instead of going after (and annoying the hell out of) the QFOs and demanding lists of TCs, we decided to automate the needed regression tests based on the known content of the upcoming version. In Delver we have a new version once in two weeks, so the AEs typically had two weeks to automate the needed TCs for the upcoming version. The list of tests for each version is compiled in advance anyway, so the only thing needed was to go to the list (we call them Test Runs, a list of Ad hoc TCs, compiled specifically for each version based on the contents of that version) take the most important TCs and start automating them, moving to TCs of lesser priority when to higher priority TCs were done. This left us in a more favorable position:

• We no longer need the QFOs for setting automation priorities. We know what to automate: the tests we're about to run in two weeks.
• QFOs immediately felt the relief. Since we started on automating the next version, when testing started, they had very little regression tests to run manually.
• Automation team is now measured differently. Instead of measuring automated TCs Vs the whole pool of all available tests, they are now measured by the percentage of automated tests in each version. The numbers are significantly higher, reaching ~70% automation of regression tests.
• Automation Engineers now feel they are part of the group because their schedules are now directly synchronized to everyone else's and their work affects the team within a week or two, not in some obscure future.

Managing a team of developers in the QA group is challenging. The automation engineers' work is dramatically different from classic testing work and left unchecked, there is a risk they'll start drifting apart from the rest of the group. By finding a method in which the automation efforts directly affect our day by day testing efforts, we manged to bring them back to the team and dramatically increase their effectiveness on our daily work.

Automatic tests in Delver: past and present

Our automation efforts started in May/June 2009 and have changed and evolved rapidly to their current form. In this post I'll review the process, what are we currently doing and where do we want to go.

We started by programming Greybox testing. After reading a product's spec, we have developed code which tested each method from QA point of view, going deeper and broader than what developers tested in their unit and integration tests. We were quite happy for a while: we found bugs early, the bugs were fixed before the final version reached QA and we did not need to wait for the final version to start testing. Cool, huh?

Not really. On July we had 3 testers writing code and one manual tester. However, researching the number of bugs found via automated testing versus bugs found manually it quickly became apparent that ~80% of the bugs were detected by one manual tester after the version reached QA while the remaining 20% was detected by three testers writing automated tests. What was the problem? Apparently many of the bugs were a result of missing components (the button wasn't there), broken components (the button was there but it didn't work) and other UI shenanigans. Yes, the backend was working quite efficiently, but the application was buggy as hell. If hell has bugs, that is.

Another problem we found with Greybox testing is that we have realized we were writing tests developers were supposed to write. The developers liked it, of course, but we felt we are not doing our job.

Next step was to switch to Automatic UI tests, or AUI. We have reviewed some solutions and finally settled on Selenium, which we still use today and will probably continue using in the foreseeable future.

We use AUI tests as an extension of our QA Feature Owners (QFOs, for short). AUI tests are tests written by the QFOs and are automated by our Automation Engineers (AEs) based on priority (for the QFO) and complexity of automation (for the AEs). Tests which are both of high priority and low complexity are automated. It is important to note that after tests are automated their execution is the responsibility of the QFO. QFOs are the driving force of Delver's QA team and AUI tests are tools at their disposal.

One of the greatest challenges we faced when starting automate UI tests is switching manual tests to tests which are easy for our AEs to automate. In a way, manual tests are the complete opposite of automated tests:

• It is effective to write long manual tests which cover several aspects/features of the application in one flow. If this approach is used in AUI tests, when a test fails, you have no clear indication of what exactly failed. For example if you mean to test feature A but you go through feature B and feature C on your way to A, if the AUI test fails, how can you be sure whether the test failed at A, B or C?
• In manual tests there's no problem with copying and pasting blocks of instruction texts ("Login, , Search, click on button A") and modifying them per test ("Login, , Search, click on button B"). This poses a major headache for AEs when they struggle to pinpoint minuscule differences between tests (Button A in the first example, Button B in the second).
  

After understanding the problems AEs face, we have changed the way tests are written. QFOs write tests which are short, specific and very focused. For the sake of automation, we encourage writing multiple short tests over fewer, longer ones. This change wasn't easy for the QFOs, but they adapted rapidly. The alternative, I explained to them, was manually running their tests every two weeks.

After the test is written by the QFO and we decide to automate it, QFO and AE meet and we make sure the AE understands what the tests does and does it test. The fact that all of the AEs are required to run some manual tests in each version also helps in that regard: the application is not "the QFO's problem" but a living entity they interact with on regular basis.

After an AE is done writing the test, she is required to hold two reviews. A Code Review with a fellow AE, in which they run over the effectiveness of the code written in the same manner every code writing member of Delver R&D is required to hold Code Review. The second review is Test Review in which the QFO verifies that the code actually tests what it is supposed to. In the past, Test Reviews were painful to us because large gaps between QFO's intention and AE's execution were revealed in them but as QFOs began writing more automation oriented tests and AEs becoming more familiar with the application and testing focus, the reviews are shorter and easier now.

Here is the procedure we use now for QFO/AE interaction:

• QFO writes a test.
  
• If we decide to automate the test, QFO and AE meet in order to briefly go over the test and make sure the AE understands it completely. This meeting is not mandatory.
• AE writes the test. This typically takes one day.
• AE reviews the code with another AE.
• QFO reviews the final product.
  

In order to be where we are today, QFO's needed to adjust the way they write tests to a way which is not optimal for manual tests and AEs were required to make sure their code reflects QFO's tests intention. We have come a long way in less than a year and I am currently happy with the results. If the QFOs are the heart of the QA team, automation are their cybernetic legs and arms allowing them to move and test faster.

I just wish I could find a metaphor for QFOs shooting laser out of their eyes, that would have been so cool.

QA Feature owner - when testers become project managers II

We have been using QA Feature Owner (QFO) methodology for two months now so I guess it's time for me to review where this is going. My vision is very clear to me:

• I (QA manager/Team Leader) don't want to decide what will be tested in each build

• I want to increase testers' commitment and familiarity with "their" features
• I want each tester to be skilled in all three testing methodologies we employ (Greybox/Integration tests, UI automation tests and manual tests) as well as with core QA methodologies and skills such as reading a specification document, analyzing it, deriving risks etc'

If that wasn't clear enough, I'll now emphasize what team I don't want:

• I don't want a team in which I have to decide which test will run in each new build. Too many test cases and too many changes in each build for me to do this effectively.
• I don't want a team of domain experts who only test their area of expertise. I don't want the UI automation expert doing nothing but recording scripts and I don't want the person who is used to testing manually treat automation like black magic.
• I don't want testers who test features when they assigned to them and forget them after the testing is done. I don't want tester who move from feature to feature.
• I also don't want tester who got job security because they are the only ones who can "do this thing". This is not exactly QFO related so I'll deal with the versatility issue in another post.

Since we started using the QFO methodology, we are testing differently. When we get a new build I sit with each QFO, asking her what she wants to test and why. Why is this test left out? Why do we run that test again? While I'm there to supervise, each QFO is responsible for creating "test runs" (that's how a collection of tests is called in Testopia, our testing suite) for new and existing features. QFOs run some of the tests themselves, other tests they delegate to other team members. That's OK, that's how the system works.

This system is obviously not suited for every testing team. Team members need to be able to (and want to!) take responsibility over their features. Team members need to delegate tasks to other team members and perform testing tasks which aren't "theirs" so good communication skills are also required. It is geared towards responsible testers who want to be involved with the product and not just perform tests assigned to them by some authority figure.

QA Feature owner - when testers become project managers

In our R&D organization, new features are usually led by developers. While managing the new feature, the leading developer is assigned the title Feature Owner for that feature. She delegates some work to other developers while performing some coding tasks personally. The larger the feature, more time is spent on managing and coordinating efforts and in smaller ones the FO spends more time coding. The interesting issue (for me) is the interaction with the testing team.

Most features are multi tiered: there's a backend layer, some application layer and a UI. Tests for each layer are different, of course: Greybox testing for backend layer, SQL scripts for database related tests, UI Automation and manual tests for the UI, etc'. The problem is, most testers don't feel equally comfortable with each testing methodology so what tester do I sign for each feature? If I assign a manual tester to a "mostly UI" feature does it mean we want test the backend? My coder can't handle the UI automation suite, maybe I'll just skip automatic UI test?

The other alternative is assigning several testers for each feature, based on their skills. This ensures that each tester is assigned tasks she's good at but it also poses other problems:

• The overhead of testers learning new features is now multiplied by number of testers involved in testing the feature
• Dispatching work between the testers and writing a test plan can not be done by the development FO, as she does not have the testing know how. Also, who is to know all the bugs related to the feature? Each assigned tester? Too messy and getting a quality overview is hard.
  
• Why not assign the QA team leader for dispatching tasks and writing a test plan? Because most of the time she will not do the actual testing on the feature, so we have a paradox: the QA person who studied the feature and designed the tests does not test it and the people who test it did not study it thoroughly (overhead, remember?)

The solution we are practicing now in my testing team is assigning a QA Feature Owner (QFO) to the development Feature Owner (FO). The assigned QFO is usually the person who's skills are the most relevant to the feature, but she needn't posses all the required testing skills: the QFO will assign tasks to other testers in the team in areas in which she lacks or simply does not have time to run or design tests.

This is how it works: upon reading the spec, the QFO designs a test plan, a document detailing the general testing strategy. In this document risks are identified and then tests are written as a sketch: a few words describing the general purpose of each test. We find it convenient to start by designing Greybox (GB) tests, then Automatic UI tests (AUI) and finally manual tests.

It doesn't matter if the QFO is a programmer or not when designing GB tests. Using Data Driven Testing methodologies most GB test cases are list of methods and what they are supposed to do and attached CSV files which are no more than input/output files based on the original spec. AUI tests are simply stories in English ("go here, click there") which can also be augmented beforehand using CSV files. Test cases are later reviewed by other team members to validate their testing logic and enrich the tests in areas in which the QFO is weaker. For example, a manual tester can review the manual tests written by a QFO who has strong programming background and suggest additional tests. Test cases will later be examined by the FO and QFO together, in order to ensure full coverage.

Once all test cases are approved by the QFO and feature and test coding begins, the QFO starts following the testing project. The QFO is responsible for ensuring that tests are run but not necessarily by the QFO personally: testing tasks can be assigned to other testers as long as the QFO remains the testing team's focal point for the feature. The QFO does not need to be the one reporting all defects but must know all defects opened which are relevant to her feature. The QFO is responsible for the testing of the feature but the actual tests may be performed by others.

We have started implementing this methodology only a few weeks ago and it remains to be seen whether we benefit from it on the long run. I don't take the fact that we're asking hands-on testers to become project managers for granted and believe some will adapt to it better than others. Others will resent the time spent in meetings and reporting and will feel more at home getting their hands dirty with testing. I have no intention of forcing any tester to become a QFO, I consider it a perk, not a requirement. I do, however, believe that tester assuming the role of QFO will enjoy the challenge of managing a testing project, interacting with more team members from the R&D than they are used to and experience new testing methodologies. I believe a good QFO is a potential testing leader.

QAing in a startup

After 8 years in big companies like Mercury (R.I.P) and Symantec I have started working for Delver, a startup company, in late 2007. After 15 months of starting and running the QA team I am wiser about QAing in a startup company.

1. Testing is Testing is Testing. Good QA is about methodology: be methodic in your risk analysis and in your tests. This principal doesn't correlate to the size of the company. In Delver we won't write a test case to a feature if it's not documented. I don't settle for oral briefing or email overview. No document, no test case. Easy, really. On the same principal, no testing without a test case, even for small features.
2. Speed over quality. In a startup company the emphasis is on fast development with speed being first priority, quality second. This perspective dictates more investment in speeding up the testing process. We used the following methods:
   
-Automation for testing relatively stable components
-Testing new components outside the main build if the build is not ready
-Issuing "non release" build for focusing on delicate features

3. QA freedom/No safety net. Another aspect of speed oriented, developer dominated organization is the freedom for QA. Since the focus is usually on the developers the QA team in Delver enjoys more professional latitude than what I have experienced on larger organizations. The flip side is the lack of testing peers and no organizational testing history. There is no safety net for me in Delver and when I make a methodical mistake usually there will be no one to correct me. This is an exhilarating feeling, but it's also a scary one. Like all good thrills, I guess.
4. Smaller budgets. Big, commercial testing software is expensive. Startups don't like "expensive". Startups like "cheap" or even better: "free". On one hand this seems like a major limitation (oh, who am I fooling. It is a major limitation.) but on the other hand it's also a challenge and a cool one. Finding a 300$ alternative for a 80K$ load testing suite is a personal victory and shows me that I can overcome seemingly seemingly impassable hurdles (financial, for example). In the future I'll dedicate a post to cheap and free tools we use in Delver.
   
5. No bureaucracy. Well, this one is obvious but it's still cool. When I need to ask something I can go to the guy and ask him. No email to another office, no phone calls to another continent. Go to the guy. Ask. End of story. If I want to hire a candidate I can give him a contract a day or two since the first interview. If I need a new license I simply go to the room of the guy who signs the checks and ask for the money. Simple. Fast.
6. More flexibility in reporting bugs. I don't open a bug for every problem we encounter. Since the company is a small one, when I'm not sure I can simply go to the room of the developer who is responsible for the code I found the problem in and verify whether it's a bug or not. This can be done in larger organizations as well but sometimes the relevant developer is not in the same building. Or town. Or continent.