"When your development team is nimble, quick, and ready to start coding, they don't have time to wait for your research results, so we can't afford to be slow in UX, either. The way to achieve quick results is to be very focused on what you want to find out. Once you have a solid hypothesis for a product persona, you find two or three people that match the profile and interview each one for an hour or so about their daily tasks, their skills, background, and what's important to them. These interviews validate that the persona you envision actually does the tasks you think they do and you're not completely off. Plus, you'll learn a lot more about the users than you may expect."
—Nellie LeMonier on performing persona research with speed and efficiency.
"The key distinction I would make between “quality debt” and “technical debt” is that where technical debt usually focuses on the cost and impact on development and future development cycles (and there are many sub-categories of technical debt,) quality debt focuses on the impact of implementation and quality decisions on the end user and business; how those decisions affect their ability to do their day-to day-job."
—Jordan Setters on the difference between “quality debt” and “technical debt.”
"The tip I would give those that are working to scale an environment that can foster high-performing teams is to assemble a group that models the framework petals. Each petal is really a perspective into the complex system so when a change is being planned all the perspectives can be weighed to craft the change."
—Michael DePaoli on hyper-productivity and teams in the enterprise.
"Input validation. Many, many types of attacks leverage the fact that developers do not do an effective job of validating the integrity of the inputs their programs/interfaces accept. Too often input buffers can be overflowed, executable commands can be sent to a database, or inadequate authentication mechanisms are used to assure the person logging in is legitimate. Just cleaning up our inputs can go a long way toward making software more secure. These types of security issues are also ones that testers can understand and test for without understanding the details of the code."
—Jeffrey Payne on security areas that testers may overlook.