Michael Burnside Twitter: @SQAEvangelist Blog: Software Quality Assurance, Quality Engineering, and Web and Mobile Test

Michael BurnsideTwitter: @SQAEvangelistBlog: http://sqaevangelist.blogspot.com/Software Quality Assurance, Quality Engineering, and Web and Mobile Test Automation Expert

17 May 2013

EFFECTIVE QUALITY ASSURANCE USING AGILE SOFTWARE DEVELOPMENT PROCESS – THE QUALITY-CENTRIC APPROACH TO DEVELOPING THE BEST SOFTWARE POSSIBLE

Effective Quality Assurance using Agile Software Development Process

Table of Contents:

1. Prerequisites

2. Forward

3. Example of devices used every day that use and run software programs for successful operation

4. Software Usage Statistics

5. Necessary Stakeholders

6. Process Goals

7. Process Activities

8. Milestone Timelines

9. References


Prerequisites:• The Reader has basic knowledge and familiarity of the

Agile process and how it is used in regards to software development.

• The Reader has basic knowledge of Quality Assurance activities.


Forward:

The use of software programs in society today is so ubiquitous, transparent, and executed on such a massive scale that most people in almost every non 3rd-world society use devices that run software that requires for successful execution of that software and is now entirely crucial to the success of the desires and wishes of people using the software and to all societies, in general.

So, now we have entire societies whose normal life activities and productivity are entirely dependent on working software for the next level of human activities (Assuming that food, water, and sleep are the basic human needs and activities).


Example of devices used every day that use and run software programs that human beings depend on for successful operation

Examples of devices that can be generally regarded as a used device on an hourly/daily basis that run software programs:

1. Watches

2. Personal and Work Computer (laptop or desktop)

3. Mobile device such as a tablet computer, such as iPad, Android, Windows CE (tablet) or “smart” phone (iPhone, Android, Windows CE).

4. Microwave oven for cooking/reheating food.

5. Regular oven for cooking food.

6. Databases / data storage. This data is used for a variety of reasons.

7. Nuclear energy producing power plants and military-controlled devices of mass destruction.

8. Cable TV set top boxes

9. Digital HD, Non-CRT Televisions


Software Usage Information (and this is only includes mobile phone information, not the many other types of products that run on software that humans rely on)

For simplicity, this presentation will use usage data from the mobile device market. Highlights (next 2 slides):




Do I have your attention now?

Do you see how important the quality of software also corresponds with the quality of life for those of us whom are fortunate enough to live in a country or society wealthy enough to allow for use of devices such that we are dependent on them for positive life-enhancing experience?

Hello? McFly? Do you get it now?

Yes? Good! Then we can move onto the next part of the presentation: your team that will build the best possible quality of software for your company and/or organization.

Effective Quality Assurance using Agile Software Development ProcessNecessary Stakeholders:

At the very minimum, your team needs to include the following stakeholders WITH NO EXCEPTIONS.

1) Product Manager

2) Software Developer and/or team

3) Quality Assurance person and/or team

4) Scrum/Project Master to handle the Agile process aspects of the project

That’s it! If one of these people does not exist in your team right now, THEN GO AND HIRE THEM!

Nice to have:

5) Development and/or QA Manager involved in all updates and progress of the project

6) Project Manager to help and assist in controlling the timelines and milestones being met and help with task prioritization if involvement is in a large company where software may affect many released products whose tasks cannot be reasonably known from a smaller, more focused, Agile team.


Process Goals

1. To deliver to your customers the highest quality of software possible.

2. To make your customers love using your software and become dependent on it for good enhancement of daily life or job experience.

3. Become dependent on it for their own job/personal life success and happiness.

4. To maximize efficiency and purpose of each member in the Agile workgroup.

5. To eliminate any possible ambiguity in product requirements, acceptance criteria per test case, and product deliverable dates.

Effective Quality Assurance using Agile Software Development ProcessProcess Goals (Continued)

1. If you fail, you fail as a team, not because of an individual or group of individuals on a particular team.

For example, if a critical/show stopper bug appears in a production environment, the first question that you should NOT be asking is: how did the QA Team miss that one? Who on the QA team was responsible for this? The QA team is entirely dependent on the software being developed by the software development team and pushed into the QA environment. The QA team cannot manually possibly test every single test case. Automating tests can help and be of great assistance, but that is not the focus of this presentation and, it takes much time to build a set of automated test cases to test and have adequate test coverage to assist a manual QA tester in their job.

The correct question should be: How did the bug get into production and let’s find the fail mode and correct it immediately and for the future; but how did we AS A TEAM miss this one and what can be improved IN OUR SOFTWARE DEVELOPMENT PROCESS so that this does not happen again?

Very rarely, a bug enters the production environment because of the incompetence or failure of a QA person. More often than not, it is because not enough thought went into developing, testing, and understanding the impact of the change in an environment where it may not be testable (developer: local environment; QA person: QA testing environment; Release Engineer: Staging environment). The most common cause is inadequate and unprepared test environment or intense product schedule release pressure.

If this is the case, then you have what is called a “Development-Centric” software development process. Your organization should move away from this type of process. What will be done now is to define a “Quality-Centric” software development process. If you follow it, the process goals will be easily achieved.


The Quality-Centric software development process.

Milestones (Part 1):

1) Test cases corroboratively developed per story by the following stakeholders: Product Manager, QA, and Development team members. This includes: purpose of test case (what are we testing?), intricately and well-defined steps to execute the steps of the test case, and lastly (and most importantly) Acceptance Criteria (what result data or user experience will validate that the test passed?).

2) Once a complete list of test cases are created for each story in the iteration , an email is sent from the QA person to the developer and Product Manager asking for approval of all identified test cases, steps, and acceptance criteria. At this point, the Product Manager and any software developers have a chance to review the test cases purpose, steps, and acceptance criteria. Feedback may be given to change any part of the 3 identified data set for the test case, but eventually, THE SET OF TEST CASES (WHICH IS ULTIMATELY A TEST PLAN) MUST BE agreed to via an email from the Product Manager and Developers to the QA person. This action gives a SHARED RESPONSIBILITY if there is a problem during testing of the software or a critical bug reaching into the production environment.


The Quality-Centric software development process (Continued).


1) As the software developer starts to write the software to implement the features in the story, a QA person may or may not (but usually can) start to implement the execution of test cases. When the software is ready to be tested, the developer sends an email to the QA person that indicates the software is checked in and the feature is ready to be tested. If not, in some cases mock testing implementation can be created (use of JMock or other interfaces, etc) by the QA person to mock test the software.

2) Development on each story feature needs to be completed by at least 30% of time before the end of the iteration. If not, most likely not enough time will be available to test the story feature (and also test regression) and it is recommended to move the story completion to next sprint, and back out or comment out the code to avoid product risk. The team must determine how any unfinished story (development or QA task) can potentially cause risk to a released product.

Effective Quality Assurance using Agile Software Development ProcessThe Quality-Centric software development process (Continued).


1) The QA manual and automated tester implement the test cases. Sometimes there are companies that employ a separate/disconnected manual QA (subject matter expert – SME) and automated test implementation team per product and then a QA test automation team to write automated tests. This disconnect is a risk to the company’s test validations. It is incredibly important that if the manual and automated test case implementer are not the same person, that they need to be in complete sync to verify the test of the story is working. Most likely, the most competent subject matter expert on the QA side is the manual tester, not the automated tester (if on a separate team that provides basic automation work for the company). If so, the manual QA tester MUST VALIDATE the acceptance criteria of the feature whether it be of a manual or automated test implementation and be a constant future validator or passing tests. The manual QA tester is responsible for running the test cases and it may be easy for them to do that through a Continuous integration (CI) mechanism. But they are responsible for getting updated on the results of each test run and perform the appropriate actions if there is a test error.

2) Agile stories are NOT COMPLETE unless all tasks have been finished, and that includes any QA tasks (manual or automated). QA team should validate with development and Product Management that any test cases are indeed working and any regression errors are dealt with.


The Quality-Centric software development process (Continued).


1) The QA team and Product Management team are the stakeholders who determine when a product is of adequate quality and ready to be released to the end user.

2) The software development team NEVER decides when a product is ready to be released.



References

1. http://www.smartinsights.com/mobile-marketing/mobile-marketing-analytics/mobile-marketing-statistics/


Thanks!

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.

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.

Documents

Michael Burnside Twitter: @SQAEvangelist Blog: Software Quality Assurance, Quality Engineering, and Web and Mobile Test