Thursday, December 26, 2013

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 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.

Thursday, October 3, 2013

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?

Under normal
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:

·Why
do employees admire their managers?

·What
is the source of managers’ power?

·What
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

·You
have a clear vision and your people believe you’re going to fulfill it.

·The
vision exists and is achievable

·The
vision is shared with the employees

·You
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.

·Empowering
your people and make them feel they matter

·Generous
with compliments and gives credit when credit is due

·Promotes
team spirit and atmosphere of collaboration

·Authentic
and trustworthy

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

About Me

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.