Are you a leader with a quality problem? Every organization struggles with quality at some point in their product lifecycle. Knowing what to measure and how to build a culture of quality with specific and actionable methods is key.
Technologist and evangelist Peter Varhol and Gerie Owens, a test architect and certified ScrumMaster, discuss their STARWEST presentation, “What Aircrews Can Teach Testers about Testing.” They talk about how testers can apply airline safety practices to their teams’ delivery of high-quality applications through complementary expertise, collaboration, and decision-making. They also explain how blind deference to authority and automation can be detrimental to a testing team, and how to use everyone’s skills to achieve success.
Rob Sabourin, the program chair for STARWEST 2018, discusses the selection process for conference speakers, his favorite aspect of the conference, and the interactive Test Lab. He also details his “Testing in the Dark” talk, which gives strategies to use when you’re required to test software without any requirements, design, or product knowledge.
Greg Paskal, test automation lead at Ramsey Solutions, talks about data lakes and how to effectively use data visualization. Done well, data visualization should help practitioners, managers, and stakeholders easily consume, understand, and act on the information the visual displays.
The test pyramid is a great model for designing your test portfolio. However, the bottom tends to fall out when you shift from progression testing to regression testing. The tests start failing, eroding the number of working unit tests at the base of your pyramid. If you don't have the development resources required for continuous unit test maintenance, there are still things you can do.
In this interview, Hans Buwalda, the CTO at LogiGear, talks about whether you need developers in test, pure testers, or domain experts, based on what you are testing. He also talks about where you should spend your time and how many tests should be at what levels.
We are often reminded by those experienced in writing test automation that code is code. The sentiment being conveyed is that test code should be written with the same care and rigor that production code is written with.