http://www.cnet.com/news/apple-releases-ios-8-0-1-a-week-after-ios-8-launch/
One thing very clear from the Apple iOS 8 release debacle is that some entity within Apple decided to release without the approval from the QA and Release team responsible for testing features and installation.
More surprising is how Apple had no immediate backup plan available to it's customers to conveniently roll-back to the previous iOS7 installed version.
This is very un-Apple like.
It's doubtful that the QA team would approve of a release with obvious product issues such as not being able to connect to a cellular network or Touch ID when those features are front-and-center and the core of what the iPhone does, and these issues were most likely known by the QA team beforehand, or, they were not aware of any late changes to the product that broke the features without the team having either 1) not enough unit testing by the dev team, or 2) not enough time to validate these changes were working properly.
Either way, the Apple/iOS QA team was put in a no-win situation and not capable of validating the product with a disorganized process, possible non-existent unit testing by the development team, and lack of patience in allowing the QA team to verify, to the fullest extent, the best possibility of a great release and identifying product risk.
The QA team knows more about your product than anyone else and has passion for customer satisfaction, pleasant user experience, and overall intuition about how the customer will interact with installation and product features. Listen to them and allow for the QA team to impact quality.
Thursday, September 25, 2014
Tuesday, August 19, 2014
Are you a tester or a resource to impact better user experience and product quality?
Every person involved with traditional activities within the software development testing industry are referred to as "Software Quality Assurance" resources immediately realize that someone hired as a QA resource cannot impact quality of the product. They are hired as merely testers, and the only product/deliverable from these people are information about the product in that capacity.
Smart and capable VP/Directors of Engineering who really understand this realize the obvious:
1) Traditionally, QA people are hired mostly with intent of only being software testers, and testing has no impact on better software quality. Testing provides information about the product in its current state. This information is to better inform the team of more accurate product readiness.
2) Traditionally, QA people are expected to be entirely responsive to the development team's schedule, testing environment, and the development team is much more greatly appreciated and coddled to rather than the mostly neglected QA teams' effectiveness, passion, and contribution to the company's product roadmap objectives.
And the response from these managers are:
1) Respect the QA teams' concerns about user experience and product quality based on the findings and understanding of the test results.
2) Completely understand and acknowledge the leadership and intent of feedback from the QA team is entirely because of sincere concern for good user experience and product quality.
3) Acknowledge and promote the QA team's accomplishments, especially when it involves meeting the challenge to a reactive situation that they don't control, i.e. like working on weekends because the development team didn't meet the code freeze deadline.
4) Understand and reward test automation innovation and be open to acknowledgement of the effectiveness of these tests and how it benefits the customer experience and every resource in the company.
If you are a QA person, then eventually you will need to decide to accept being merely a tester with no meaningful impact on product quality, or stepping up and being a leader and positively impacting quality.
If your current company does not offer opportunities to meet your career goals as a QA professional, then quit your job. Your future employer will appreciate your initiative, talent, and passion.
Smart and capable VP/Directors of Engineering who really understand this realize the obvious:
1) Traditionally, QA people are hired mostly with intent of only being software testers, and testing has no impact on better software quality. Testing provides information about the product in its current state. This information is to better inform the team of more accurate product readiness.
2) Traditionally, QA people are expected to be entirely responsive to the development team's schedule, testing environment, and the development team is much more greatly appreciated and coddled to rather than the mostly neglected QA teams' effectiveness, passion, and contribution to the company's product roadmap objectives.
And the response from these managers are:
1) Respect the QA teams' concerns about user experience and product quality based on the findings and understanding of the test results.
2) Completely understand and acknowledge the leadership and intent of feedback from the QA team is entirely because of sincere concern for good user experience and product quality.
3) Acknowledge and promote the QA team's accomplishments, especially when it involves meeting the challenge to a reactive situation that they don't control, i.e. like working on weekends because the development team didn't meet the code freeze deadline.
4) Understand and reward test automation innovation and be open to acknowledgement of the effectiveness of these tests and how it benefits the customer experience and every resource in the company.
If you are a QA person, then eventually you will need to decide to accept being merely a tester with no meaningful impact on product quality, or stepping up and being a leader and positively impacting quality.
If your current company does not offer opportunities to meet your career goals as a QA professional, then quit your job. Your future employer will appreciate your initiative, talent, and passion.
Tuesday, May 20, 2014
The high cost of bugs found by the QA team
The average time it takes to find a bug, enter it into a bug tracking system, and then verify the fix is around 30 minutes.
The higher amount of bugs found equates linearly to the cost of product functionality verification per QA team member. As a team, it equates exponentially.
That is real time and money spent on a reactive and non-productive, non-quality impactful action to product quality.
If you feel that the development team is introducing an excessive amount of bugs into the QA environment that you test against, then be sure to bring that up in an Agile Retrospective, and provide ideas for process/quality improvement. The customer, and your company's CFO will appreciate your effort in reducing costs and promoting better product quality.
The higher amount of bugs found equates linearly to the cost of product functionality verification per QA team member. As a team, it equates exponentially.
That is real time and money spent on a reactive and non-productive, non-quality impactful action to product quality.
If you feel that the development team is introducing an excessive amount of bugs into the QA environment that you test against, then be sure to bring that up in an Agile Retrospective, and provide ideas for process/quality improvement. The customer, and your company's CFO will appreciate your effort in reducing costs and promoting better product quality.
Tuesday, May 6, 2014
Development2014 - Day 1 highlights
I was very fortunate to attend and present at Development2014 in Millbrea on Monday, May 5, 2014.
Gateway Analytics Network did a great job setting it up and I learned alot.
I learned about Kanban, Parc business updates and strategy, and Scaled Agile. Amazing stuff.
Gateway Analytics Network did a great job setting it up and I learned alot.
I learned about Kanban, Parc business updates and strategy, and Scaled Agile. Amazing stuff.
Subscribe to:
Posts (Atom)