During the last six years in Sears Israel, we have kept shortening the release cycle. During the first two years we deployed a version every two months (give or take a week or two). Later, sometime in 2010, we opted for a two weeks release cycles. This posed many challenges to all teams involved in the process, but we all adapted and the classic roles of the teams did not change much: Product team wrote the spec, R&D wrote the code, QA tested and approved the quality and Operations team deployed it. When we decided to deploy the code "when the feature is done", things had to change. We could no longer afford to have the QA team standing as a Gate Keeper, approving every version thus slowing the process down. Responsibility for the quality of the features was officially shifted from the QA team to the developers and "QA approval" was no longer a mandatory step in order to deploy to Production.
This shift posed a big challenge to the QA team. If we're not the gate Keepers, who are we? If developers are not required to get QA approval, why would they go through all the hassle of "version to qa-> bugs -> fix -> version to qa" ad nauseam? Looking for answers in the web was not very encouraging, as we quickly found out that Facebook doesn't have a QA team and Google says Test is Dead so what hope did our little team have? Many people were concerned: mostly QA engineers failing to understand their future role (some probably fearing for their jobs) and developers not too happy about losing their testers and having to dirty their hands with the undignified work of manual testing.
The journey took almost two years. From a team of concerned and doubtful QA engineers and managers we shaped a team of professionals who know exactly why are they needed in the release cycle even if the are not mandatory. The major state of mind shift was from a acting as a mandatory link between R&D and Operations to service providers, catering to the needs of other groups in the organization. We're not the Gate Keepers anymore, but we don't want to be.
We are the testing experts. Not manual tests, mind you (though we will lend a hand if a developer asks nicely) but other, specialized testing forms: performance testing, subjective quality (search results quality, recommendations quality, newsfeed quality, etc.), mobile testing, fault and recovery and more.
We provide Risk Analysis and assist developers and product managers see risks in integration with other interfaces. Over time, our application grew more complex, with a lot of moving parts interacting with each other. Due to the QA team being small, sharing information is relatively easy for us and we invest time and resources keeping our QDOs informed on other components they may not have a day to day experience with. This knowledge allows each QDO to identify risks not only in his domain and feature but also in the interaction of new features with other interfaces and domains.
We are the reporters and intelligence officers. When you deploy a version every few weeks, there's plenty of time to investigate and reflect what went wrong and what went right, what are the current problems and where should go next. This task gets more complex when you deploy a version several times per day. When, exactly, are you supposed to stop and reflect? One of the services our QA team provides is weekly reports in which we connect the dots, so to speak, and tell interesting and important stories reflecting the quality in each domain. Not automatically generated bugs list, mind you, but thoughtful analysis of the current quality in a domain, usage patterns analysis, recommendations on where should we invest development resources and more.
Theses are the main services we provide, but there are numerous others as well: we manage bugs reported by support and internal users, we run usability and functionality analysis, we champion specific bugs that need to be fixed and fall between the cracks, we manage interfaces with other QA teams in the organization and we go over domain specific bugs with the relevant domain stakeholders and assist in prioritizing them.
What about automation, I hear people ask. What about what used to be the holy grail of QA future? While we have some automation capabilities, we believe that since the developers own the quality of their code, they should also be the ones concerned with automating the tests. We assist and have our own automation solutions but the majority of automation in our organization lies on the R&D side and it makes perfect sense to everyone.
The software industry changed dramatically during the last 10 years and the QA needs to change and adapt. We were once the gate keepers but we evolved, offering unique services no other team in the organization can: testing expertise, analysis, connecting the quality dots and providing quality related services to whomever needs them. If your organization faces the same challenges, you had better think in advance where you want the QA team to be and what uniqueness can they bring to the game. As the old saying goes, evolve or die.
The call - Former manager of you gives you a
ring. He is now in a new company and wants you to leave your current company
and join him. Assuming the position, salary and most other factors are similar
to the position you now hold, what personal/leadership traits of that manger
will make you consider leaving your job and join the new venture?
circumstances, employees will obey you because of basic organizational
hierarchy. However, relying on organizational hierarchy as the sole motivator
will hurt their performance on the long run since most
employees feel bound to their managers, not the organization (“peoplejoin
organizations but leave their boss”) and Unbound employees are more likely
leave when opportunity arises. Furthermore, motivated
employees perform better and inspire others while unmotivated employees just go
through the motions. So, Motivated employees = good, non motivated = not good. I'm glad we got that out of the way.
Find your Awesome
I wrote this post while trying to identify and highlight personal traits which can assist managers in being
perceived as Awesome by their employees, thus connecting the employees to the
manager and increasing the employees’ motivation and commitment. I started by asked myself the following questions:
do employees admire their managers?
is the source of managers’ power?
makes people follow?
There are many articles about character traits which mark great managers but upon reading them I felt that these character traits help managers be more successful in their work, they are not traits that will mark them as Awesome by their employees and make people want to follow them. So I compiled my own list of character traits which I believe will make employees admire their managers to the point where they'll take drastic actions such as leaving their work in order to work the that manager.
1. Visionary and going places
have a clear vision and your people believe you’re going to fulfill it.
vision exists and is achievable
vision is shared with the employees
actively strive towards the vision and make visible progress
Quote: “My manager knows where
she’s going. Following her will take me far.”
2. People’s Person
You care about your
people and they know it.
your people and make them feel they matter
with compliments and gives credit when credit is due
team spirit and atmosphere of collaboration
Quote:“I love working for her.” 3. Source of knowledge You are a source of knowledge for your people. Working with you is
a constant learning experience.
·Source of new professional knowledge
·Vast professional experience
·Deep grasp of the profession and the product
·Professional could be Technical, Management, Political, etc.
Quote:“My manager knows more about this stuff than the rest of us
together.” 4. The coach You help people improve and inspire growth.
·You set high standards, demand high standards and don’t compromise
·You show the way to improvement and enjoy mentoring people
·You share knowledge willingly and encourage others in the team to
do so as well
Quote:“She is tough, but she is the best teacher I’ve ever had and she
will help me grow.” The character traits which employees admire in their managers and
will make them follow those managers are the ones which bestow confidence
in the employees and the first thing people look for in their managers is the confidence they project. Different people look for different things in their managers but
the one character trait all employees seek in their managers is confidence in
their ability to lead. When I presented this to the managers in our company, some people asked "Where are the other traits such as Honesty, Passion, Communication,
Humor, Commitment, Personal Example, Coolness under fire etc’?" My answer was that while these traits are crucial in order to be a good leader, they
rarely make an employee connect with his manager based on these traits alone,
i.e. the fact that a manager sets great Personal Example does not make her a
leader to follow on the long run. Different people look for different traits in their leaders. One
person will tolerate an uncaring manager if that manager sets high standards,
another will not consider working with a manager who doesn't know his spouse’s
name.Different leaders are awesome due to different personality traits.
Find your awesome and focus on it. Remember: he who wishes to be strong on all fronts will ultimately
be weak on all fronts. Focus on your strengths instead of trying to strengthen
your weak points. Discuss
·Are there more awesome leadership traits not covered?
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 duration assessment
Synching other interfaces
Following up on features
Specification document analysis
Writing organized test documents
Effective test coverage
Good test prioritization
Through bug analysis
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
Passionate about the product
passionate about QA
Organized and thorough
Businesslike (practical, focuses on getting things done instead of ego games)
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.
I'm in QA since 2000, started by specializing in Performance testing and later set up a QA group from a tiny start-up phase to corporate. I also collect and paint miniatures, raise two daughters and a boy and ride a bike. Usually not at the same time.