The quality-Centric software development process. Michael Burnside Twitter: @ SQAEvangelist Blog: http://sqaevangelist.blogspot.com / Website: http://sqaevangelist.com / Software Quality Assurance, Quality Engineering, and Web and Mobile Test Automation Expert 31 May 2013.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Software Quality Assurance, Quality Engineering, and Web and Mobile Test Automation Expert
31 May 2013
Table of Contents:
The Quality-Centric software development process focuses on the execution of a team of very highly technically capable, narrowly-focused, and dedicated software related professionals with the goal of building and delivering the very highest quality of product to the customer and document software and processes (product requirements, software development, and testing) such that it reduces risk to the company in the event that team members leave the team so that further progress and support of the product continues with the least possible risk to the company and ultimately, to the customer and User Experience (UX).
You cannot test quality into software.
What does this mean to you?
Before I start, let me introduce myself and thank you for allowing me the opportunity to present to you my ideas. Your open-mindedness and ability to be a listener, and being a proponent for change is appreciated and encouraged.
I have worked for almost 20 years as a software developer (and later software architect) in Basic, assembly (Motorola 68010), Pascal, C, C++, Perl, and later more focused on Java, J2EE (server-side and client-side using Swing) and then, after much career reflection and disappointment with the extremely low focus on developer unit testing and many software organization’s low respect for QA activities; I decided to transition to the Quality Engineering role to organizations in the software development process with goal of raising the bar of quality in all software products I was part of testing and becoming what I feel is a complete “software engineer” and VP Engineering at some point in the future using the best practices that I have learned.
Software Myths (Part 1):
There are a group of individuals that test the product and deliver accurate results of the tests to the other stakeholders. The people who test the product are a part of a larger team that determines what is acceptable product functionality and user experience to release for customer use.
Software Myths (Part 2):
2) The Agile process makes developing software easier and using it results in higher-quality software and better User Experience. Reality:Agile is really about improving work team communication and identifying risk and changing direction quickly because of business needs. It is a process that is a very good (and better) process when applied for developing software than using earlier methods (waterfall, etc.) but Software Testing, and the activity milestones in regards to the testing activities, are not directly addressed. In fact, testing activities and goals are actually more difficult to accomplish within the compressed timeframes of a sprint. This is especially true when it comes to the actual time to test new features and do regression during the sprints.
Testing activities are more difficult using the Agile process.
Software Myths (Part 3):
3) It’s mainly the fault of the Quality Assurance team when a showstopper/critical bug is found in the production environment. Reality: The problem is very rarely due to the incompetence of a person on the QA team or the QA team and QA processes.It has much more to do with the dysfunction of the team itself, or, in most cases, the lack of communication, and in some cases: schedule pressure; identifying test cases, or unawareness of testing environment differences between local, QA, staging and production environments.
Schedule pressure within short Agile sprints reduce the time to identify any potential problems.
Software Myths (Part 4):
4) Product Development teams need to have much more development resources than QA resources. Typical VP of Engineering will recommend 5:1 Dev:QA ratio . Reality: The ratio of onsite (not counting remote from India, China, etc.) of Dev:QA resources need to be at least 1:1 and even better 1:1.5 or 1:2.
Software Myths (Part 5):
5) If conducting main business and software development operations in the USA, remote QA/Testing resources and teams from India, China, Russia, etc. are as effective and from a resources dev:QA standpoint count the same as a local/onsite resources from a dev:QA ratio standpoint. Reality:Remote QA resources from half-way around the world as the US (or wherever the main team is located) are not nearly as effective as on-site and local QA in the USA. Technical ability and skill of remote and local resources are, in most cases, the same. The main issue is delay of communication. In general, remote QA teams can test the product but any problems found in the product have a communication delay of 8-12 hours. On-site resources that can communicate in real-time with the development team without time delays are critical in effect of testing of the software development process.
Software Myths (Part 6):
6) The main goal of automated testing is to find bugs. Reality:The first goal of automated testing is to assist the manual QA person in testing more of the product, ie; code coverage without the physical use of their time. The secondary goal is to find bugs that may be applicable to user experience. Example: for mobile applications, this usually consists of finding memory management and crash problems.
Test Automation effort is a “marathon” and not a “100 yard dash”. Have a long term plan with the automated tests. Do it right. Don’t rush it. Remember that software is being written for the singular purpose of not using human effort and time to effectively test the product and that it must work correctly. Rushing the completion of automated test code results in the same mistakes as the customer-facing product.
People who write test automation code have one customer: The manual Testing person. The manual testing person is the end-user of automated test code.
Software Myths (Part 7):
7) For mobile applications, Testing teams can switch easily from testing applications on different platforms, ie; iPhone, iPad, Android tablets and phones, Kindle. Reality: This is an extremely inefficient and unproductive use of testing teams. Allow the testing person to focus on testing a product on one platform (iOS, android, etc) and become an expert. In general, your test person(s) should use the product much more than the end user (customer) and become familiar with every aspect of the OS and the app running on that OS.
Each test team members focuses on intense testing of the product on one product and platform only.
Software Myths (Part 8):
8) Quality can be Tested into Software. Reality: You cannot test quality into software. Quality Assurance team cannot guarantee quality. The reason is that quality is an opinion that varies. If you want good quality, it has to be very clearly defined; ie; what features and user experience will make this product to be determined that has good quality. Acceptance Criteria for defined test cases required to be tested are the barometer for quality.
Acceptable product quality must be pre-determined before software development and testing activities occur.
Overview of traditional Development-Centric tasks and responsibilities for team members
Advantages over using Development-Centric Approach (Part 1)
Advantages over using Development-Centric Approach (Part 2)
The Process, Players, and Activities (Part 1)
The Process, Players, and Activities (Part 2)
The Process, Players, and Activities (Part 3)
Special Thanks to Matt Au, who is an amazing software engineer and a smart person that I have known and respected for 10 years, for reviewing several versions of this document and providing great feedback and recommendations for improvement which I have enthusiastically implemented in the presentation that you have just read.
I sincerely hope this presentation was useful to you and that your company or organization implement the information and process in this presentation to the fullest extent. At the very least, I hope it inspires discussion and action for software and user experience improvement.
If you have any feedback, please feel free to get in touch with me (via Twitter) at @SQAEvangelist. I would love to hear very constructive comments on how to improve this presentation and make it more effective.