langford/gist:e0d3c1a6253f594ebda15ded3b3b65d8

## gistfile1.txt
How do you self QA (in UIs)

By @mj_langford on twitter

I write down what success looks like from a user goals and timing level. After that, important tests, and what is likely to be wrong in a UI test environment. What I can do next tends to stick out as a series of testable bits that a machine can check, as well as a list of tools, and platforms, I can manually check the app on to verify he app functions this way.

Then looking at the stakes and dev budget, I can winnow down the possible testing and verification procedures to fit the time we have, or request more budget/less nitpicking if the quality/delivery speed tradeoff does not match with larger standard project goals and professional and reputation standards as well as ethics.

I also try to use input validation on APIs standardized checking tools and common mistake checking tools (linters, project analysis tools, etc) to check automated errors.

Lastly, I read the diff before I commit and make sure there isn't a ton of extra stuff.

For testing in a real environment, I try to make automated deployment tools and build tooling that makes the process repeatable, so that doesn't need to be checked if it completes. This means automated checking of versions, and more in that vein.

Here is a fill in the blank description similar to many I've written.

"This App is supposed to make people aware of data about their _______. It is supposed to report ____ and   _____ and ______ in a timeline of typically ____ seconds/ms and never more than _____. The stakes of failure of the app are ________ typically, and some less obvious failures that could be _____ and _____ as some people are vulnerable or reliant on the app. The following less common types of users may be using the app, and it supports ____ and _____ to make sure it does. The app functions well when viewed under a tool like vizcheck or XScope's color blind mode. The app uses a ____ grade reading level in its text, and I have checked that text for grammar and clarity using the following tools: _____,______,_______. There is/is not user generated content supplied to the app and if so it is/is not presented to other users. Data is validated for content suitability, as well as low level serviceability on the software client by the following mechanisms:____, and on the server by ______. The app may/should/must work on ____ and ____ platforms, but we are mostly targeting _____ platforms, but have used standard enough tools many accessibility tools should still work on some others."
	How do you self QA (in UIs)

	By @mj_langford on twitter

	I write down what success looks like from a user goals and timing level. After that, important tests, and what is likely to be wrong in a UI test environment. What I can do next tends to stick out as a series of testable bits that a machine can check, as well as a list of tools, and platforms, I can manually check the app on to verify he app functions this way.

	Then looking at the stakes and dev budget, I can winnow down the possible testing and verification procedures to fit the time we have, or request more budget/less nitpicking if the quality/delivery speed tradeoff does not match with larger standard project goals and professional and reputation standards as well as ethics.

	I also try to use input validation on APIs standardized checking tools and common mistake checking tools (linters, project analysis tools, etc) to check automated errors.

	Lastly, I read the diff before I commit and make sure there isn't a ton of extra stuff.

	For testing in a real environment, I try to make automated deployment tools and build tooling that makes the process repeatable, so that doesn't need to be checked if it completes. This means automated checking of versions, and more in that vein.

	Here is a fill in the blank description similar to many I've written.

	"This App is supposed to make people aware of data about their _______. It is supposed to report ____ and _____ and ______ in a timeline of typically ____ seconds/ms and never more than _____. The stakes of failure of the app are ________ typically, and some less obvious failures that could be _____ and _____ as some people are vulnerable or reliant on the app. The following less common types of users may be using the app, and it supports ____ and _____ to make sure it does. The app functions well when viewed under a tool like vizcheck or XScope's color blind mode. The app uses a ____ grade reading level in its text, and I have checked that text for grammar and clarity using the following tools: _____,______,_______. There is/is not user generated content supplied to the app and if so it is/is not presented to other users. Data is validated for content suitability, as well as low level serviceability on the software client by the following mechanisms:____, and on the server by ______. The app may/should/must work on ____ and ____ platforms, but we are mostly targeting _____ platforms, but have used standard enough tools many accessibility tools should still work on some others."