Quality: Who asks “What if…?” question

Testing involves operation of a system or application under controlled conditions and evaluating the results (eg, ‘if the user is in interface A of the application while using hardware B, and does C, than D should happen’). The controlled conditions should include both normal and abnormal conditions. Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should. It is oriented to ‘detection’.

Organizations vary considerably in how they assign responsibility for quality assurance and testing. Sometimes they’re the combined responsibility of one group or individual. Common are teams that include a mix of QA experts and engineers who work closely together to ensure that necessary attention to the topic and activities are in place. It will depend on what best fits an organization’s size and business structure.

Please take a look at the following link and you will get a lot of useful information about testing – http://www.aptest.com/resources.html

Do you spend enough time on quality? Here are very interesting facts that might help you to makeup your mind:

  • Software problems in the automated baggage sorting system of a major airport in February 2008 prevented thousands of passengers from checking baggage for their flights. It was reported that the breakdown occurred during a software upgrade, despite pre-testing of the software. The system continued to have problems in subsequent months.
  • News reports in December of 2007 indicated that significant software problems were continuing to occur in a new ERP payroll system for a large urban school system. It was believed that more than one-third of employees had received incorrect paychecks at various times since the new system went live the preceding January, resulting in overpayments of $53 million, as well as underpayments. An employees’ union brought a lawsuit against the school system, the cost of the ERP system was expected to rise by 40%, and the non-payroll part of the ERP system was delayed. Inadequate testing reportedly contributed to the problems.
  • In November of 2007 a regional government reportedly brought a multi-million dollar lawsuit against a software services vendor, claiming that the vendor ‘minimized quality’ in delivering software for a large criminal justice information system and the system did not meet requirements. The vendor also sued its subcontractor on the project.
  • In June of 2007 news reports claimed that software flaws in a popular online stock-picking contest could be used to gain an unfair advantage in pursuit of the game’s large cash prizes. Outside investigators were called in and in July the contest winner was announced. Reportedly the winner had previously been in 6th place, indicating that the top 5 contestants may have been disqualified.
  • A software problem contributed to a rail car fire in a major underground metro system in April of 2007 according to newspaper accounts. The software reportedly failed to perform as expected in detecting and preventing excess power usage in equipment on a new passenger rail car, resulting in overheating and fire in the rail car, and evacuation and shutdown of part of the system.

Do you find right balance between speed and quality? Do you have a team member who asks this question: “What if?…”

Allies within the company

“A problem shared is a problem halved”. When it comes to working your way through the challenges that you face every day, it’s a great help to be able to draw on a network of supportive individuals that you can work with to find a solution. There are many of them. Of course you might expect certain help from them, but you also need to give something back.

Ally Can help you Expectations in return
Team Members Assist you with regular tasks
Be loyal
Be a sounding board
Deliver results
Information
Loyalty
Recognition
Credit – given both publicly and privately
Boss
Senior Management Members
Protect you
Champion you
Mentor
Loyalty
Support
Assistance with his/her tasks
Commitment
Willingness to go the extra mile
Image building
Support Staff Willing performance of day-to-day functions
Cooperation
Appreciation
Attention
Recognition
Gateway People (Secretaries, Executive Assistants) Provide you with access to crucial information and people Appreciation
Attention
Recognition
More Experienced Colleagues Provide expertise, perspective, contacts, knowledge Respect
Recognition
Attention
Clients Provide inputs for new product development initiatives
Provide referrals
Provide preferential status
Preferential status
Willingness to go extra mile
Business leads
Referrals
Vendors Provide extra assistance
Provide preferential status
Preferential status
Business leads
Referrals

Can’t come up with more examples at the moment. What do you think?

Do you measure?

statsIf you are watching football you can find lot’s of stats available about different aspects of the game: personal info about each player, movement of the whole team, shots and much more. Here is one example about shots that Belgium made in second half (picture is taken from here)

But for some reasons it’s not always a case in software development and often focus shifts towards # of errors with common tools: Jira, Bugzilla and etc. Those teams who work according Scrum use burndown charts and velocity.

But is it enough to make conscious decision in the future and decide on further product improvements?

So, should we learn from football and think of more things to consider in a daily teams’ life? Some examples from the top of my head:

  • Maximum capacity
  • Time that user spends with your solution to solve his problem
  • Growth of technical debt
  • Where users spend most of their time
  • Response times
  • Users behaviour patterns per page, per component

What do you measure?

p.s. from previous post: one of the Scrum Master responsibilities is to radiate information.

p.p.s. Can you go even more crazy than that? Castrol Rankings Index

 

Hints by Niccolo Machiavelli: outsource

….Army that defends the country can be of three types: own, allied, hired or mixed. Allied and hired armies are useless and dangerous as you can’t use them as solid foundation, such armies can be as dangerous as enemy during a war – they will use your resources during a peacetime, but will not sacrifice their lives in times of danger.

Allied armies are dangerous as stronger partner will use the victory for their benefit, not yours….

keepcalm_zed
Of course it’s not about war, but about building strong and successful company. Even though i made several points for myself keeping in mind context of a fast growing company working on a complex product.

  • Keep unique and core knowledge or experience inside the company
  • Spend effort on educating and training your team
  • “Hide” core functionality behind APIs
  • Outsource repetitive, mechanic, support or experimental activities that your team is not interested in. Give your team time to focus on core things and building API