Michael Burnside Twitter: @SQAEvangelist Blog: //sqaevangelist.blogspot.com/ Website:

Michael BurnsideTwitter: @SQAEvangelistBlog: http://sqaevangelist.blogspot.com/Website: http://sqaevangelist.com/Software Qual i ty Assurance, Qual i ty Engineering, and Web and Mobi le Test Automation Expert

02 May 2014

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

http://sqaevangelist.blogspot.com/

http://sqaevangelist.blogspot.com/

Effective Quality Assurance using Agile Software Development Process

Table of Contents:

1. Prerequisites

2. Quality Statements

3. Forward

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

5. Harsh Realities of QA using Agile

6. Necessary Stakeholders

7. Process Goals

8. Typical QA Tasks

9. Sprint Milestones

10. Milestone Timelines

11. 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 tasks and activities.


Quality Statements• Every single person at your company is responsible for

product quality.• You cannot “test” quality into software. In other words,

merely testing software has no appreciable impact on software quality.

• The testing assets are used to provide a more meaningful and comprehensive insight into likely user experience and product capabilities and limitations.

• Adhere to Sprint milestones and allow the process to make the decisions for your team so that each member can focus maximum energy on their contribution to product.

• Always remember that everyone that uses your products wants it to be awesome.


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 successful execution and is now entirely crucial to the advancement of the desires and wishes of people using the software and to all societies, in general.

In 2014, most of our 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


Harsh Realities of QA using Agile:

• Performing QA tasks within an agile Sprint is much more difficult than any other type of software development methodology previously used. In other words: QA is really, really hard when the team is using Agile.

• Missing milestones within the sprint puts exponential difficulty and stress on the QA team if risk is not mitigated or dealt with properly.


Necessary Stakeholders:

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

1) Product Manager

2) Software Development team

3) Quality Assurance team

Optional (but desired):

4) Scrum Master to handle the Agile process aspects of the project, or, a Project Manager with an Agile focus.

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


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.


Process Goals (Continued)

6. If you fail, you fail as a team, not because of an individual or group of individuals on the 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 possibly test every single test case manually and whatever contribution of testing coming from the test automation.


Process Goals (Continued)

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.


Typical QA Tasks

What are some of the tasks that need to be done, regardless of software development process used, before the next release of software?

• Decide which stories (new features) need testing done to be considered complete.

• Creation of test cases for new stories that describe: description, steps, and acceptance criteria. A collaborative effort involving development team story implementer, QA resource(s) to test, and Product Manager, and any other stakeholder involved.

• Review and Approval of test cases from all stakeholders.

• Documentation of test cases using a test case management system.

• Prioritize which test cases are “sanity”, “smoke”, and which ones to automate.

• Automate selected test cases to reduce test automation debt (regression testing automation)

• Manual testing of new features (and if time permits, automate them).

• Log bugs, improvement requests.

• Close Resolved bugs

• Identify any and all activities that are attributing to product risk and alert the team about the risk.


Sprint Milestones: The Quality-Centric software development process using Agile.

Milestones (Part 1):

1) Test cases collaboratively 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) Automation test debt can occur in times where QA is waiting for new features to be ready for testing.

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


Milestone Timelines (10 working day sprint) Example

1) Days 0 – 3 (or 0 – 30% of sprint time)

• Test cases identified for each story

• Test case acceptance criteria and approval by all stakeholders

• Catch up on automating regression testing (reduce test automation debt)

2) Days 3 -7 (or 30 – 70% of sprint time)

• Catch up on automating regression testing

• Test any story ready for QA

3) Day 7

• Code freeze deadline; all unfinished stories from development team get automatically pushed to next sprint.


Milestone Timelines (10 working day sprint) Example (Part 2)

4) Days 7 – 10 (or last 70 – 100% of the sprint)

• New feature testing manually or by any previously ready test automation

• Regression testing of all required test cases to be executed

5) Day 10 - General Availability

• Sanity and smoke testing for production release

*** Don’t miss these milestones. Doing so will increase product risk and chances for negative user experience ****



Thanks!

I sincerely hope this presentation was useful to you and that your company or organization implement the information and processes 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: //sqaevangelist.blogspot.com/ Website: