|A first glimpse of Ireland from the air and in the airport.
The first talk I am witnessing is courtesy of Andy Stafford-Clark and it's about "The Internet of Things ...it's Coming!" What is the Internet of Things? It's the interconnection of devices and information details that are not necessarily associated with the devices we typically refer to as Internet enabled devices. We've been focusing on the past three decades talking about computers, and phones and tablets and communication devices. Those are things that we are now well used to seeing, but what about the lights in our house? Our refrigerator? Our home thermostat? The train station display. Many of these devices are using homebrew tools (think Arduino/Raspberry Pi or other devices that can be created to control or set up servers that we can query, modify and update. To some, this is the epitome of nerdy, and for others, it's genuine and valuable information that helps us make decisions about what we can do (hmmm, that sounds familiar :) ). The goal of this initial and primitive "Internet of Things" as it stands today is that it is more of a fun curiosity for front minded nerdy types, but the promise of what it can offer is very compelling. What if we had the ability of actually putting together a clear understanding of how we use energy, as an example? We know we use water, electricity and gas for various purposes, but do we really know when we are using water? What really is causing the largest percentage of usage? Is it family showers? Laundry? Me changing out the water of the fish tanks? garden maintenance? How cool would it be if I could get an hour to hour breakdown of water usage each day and drill down to see various times? That is a perfect adaptation of the Internet of Things, if we choose to set it up and look at it.
Shall we get even more crazy? How about making a mousetrap that actually tells you when it has caught a mouse? Sound weird? well, with an Arduino board and a mechanical mouse trap, it's doable and Andy and his family did it.
One of the biggest challenges that organizations have is that they do not have the ability or the time to take a full team and train them from scratch. However, if the team has taken the time to implement a framework that is easily modified, or that allows individuals on the team to get some quick wins, that will definitely help speed the success of individuals making their way in getting involved with automation. Using a Domain Specific Language or API, many of the steps can be compartmentalized so that the whole team can communicate with the same language. Will the toolsmiths have an advantage? Of course they will, but they will also be able to make a system that all of the participants will be able to leverage (think of Cucumber and the ability to write statements that are well understood by everyone). When the testers write the tests and cover various test cases, the testers knowledge is being used in a way that is most effective, with the programmers able to help fill in the blanks for the testers to be better able to focus on test design and implementation, rather than trying to wrench the tool to work for their benefit.
Some of the best ways to help make it possible for the testers and others to be effective is to keep things simple, consistent and intuitive. Keep data and test scenarios as clear from each other as possible, do the best you can to encourage a common language and linguistics between the code and the test implementations (use labels and methods that make sense by how they are names and what they actually do), and keep tests as atomic as possible (one test from beginning to end, in as few steps as necessary to accomplish the goal. Additionally, a key consideration is to balance the ability of the tests nd methods to be humane over minimal. Refactoring to where the intention is obfuscated is much less helpful as compared to allowing a little more verbosity to give all the participants a clear understanding of what's happening. Also, use the option to create soft assertions, which allow the user to check 50 different fields, notice the one place it fails, an inform at the end of the test rather than stopping cold at the first error it discovers with a hard assert.
Other important considerations: don't make something reusable if all you are doing is adding to its reuselessness. Let the client code shape the API, and don't have the API be set in stone. Dev's and QA need to work together, in either proximity or communication. If you can sit together, sit together, or share screens and talk together in the same time and space, if not the same proximity.
- Motivation is key
- Not for the money
- It's not about us
- Encourage new ideas
- Don't be afraid
Rickard shred a story where he was working with a programmer who decided to try to be a tester and how, while he could see the problems left and right, the programmer didn't necessarily see the issue, or made assumptions based on how the code was being used. the key was, the tester wanted to see the problems. The programmers often want to get the work finished and of their plates (I totally understand this, and believe me, I make the same excuses when I am the one writing the code). This is also why I find it imperative that I have someone else test my code that I write, and not be afraid to tell me my creation is ugly (or at the very least, could be substantially improved ;) ).
Critical thinking isn't just that we question everything. We need to be discerning in the things we question. Start with "What if..." to get the ball rolling. This will help the tester start thinking creatively and get into unique areas they might not automatically consider. Also, be aware of the biases that enter you purview (and don't ever say you don't have biases, everyone does ;) ).
Everyone thinks differently, and the ability as a teach to be able to explain things in a variety of ways is critical. Likewise, we want to encourage those we are teaching to try a variety of things, even if the attempts are not successful or lead to frustration. we need to step back, regroup and give them a chance to look at what they did well, where they could improve, and how they can get the most out of the experiences. There will be theory and hard topics, and those are important, but always couch the concepts in practical uses. The names are not essential, the use and the understanding of how things work does (well, the names are seriously helpful to make sure that we do what we need to and can communicate effectively, but focus on what is being done more so that what it is called, at least at first. Once they get what is happening, the names will make sense ;) ).
Rikard has a paper that covers this topic. I'll reference it as soon as I get time to get to the link and update this stream of consciousness. Oh, and lookie lookie... green and yellow cards to manage question flow... now where have I seen that before ;)?
Rob spent the first part of the talk discussing what many of us know all too well, the long slog march of staged development, testing and release. Don't get me wrong, I am not a fan of this approach at all (too many years suffering through it), especially because, at the tail end, they would pull in everyone humanly possible to test a release (and ultimately, a condemnation for why software testing is ineffective, slow and boring). Yet ironically, the next project gets run exactly the same way.
How to do that? Rob's Company chose to do the following:
- Adopt Agile
- Prioritize work
- Bring Dev and Ops together (DevOps, get it ;)?)
- Everyone tests. Testing all the time.
- The team needs to become one with the data, and understand what the servers are telling us about our apps and services
They removed testers from the center of the team. Note, they don't remove testing from the center, in fact that's the very switch they made. Testing always happens, and the programmers get into it as well. This goes beyond Test Driven Development. It means that automation is used to verify tests where possible, and a more aggressive approach to canning as many tests as possible, with a progressive march to get more coverage and more tests in place with each story. this is very familiar to what we do on my team. the automated tests are the things we want to run every time we do a build, so we emphasize getting those tests reliable, understandable, and easy to modify if needs be that we need to modify them. Ideally, the idea is to automate as much of the drudgery as we can so that we have fresh eyes and fresh energy to look at actual new features and learning what those new features actually do.
Cycle times vary, and each organization can modify and tweak the cycle times as they choose. If weekly is the shipping schedule you want to use, then your cycle time needs to be somewhere between four and five days. Dog fooding (or pre-production) is a life that we understand very well. It helps us se the real performance and actual workflows and how they are processed, and the good bad and ugly that surrounds them. Rob emphasizes exploratory testing be used along with the focus on automation, and an emphasis on the testing that is most critical. The key to success is a focus on continuous improvement and questioning the effectiveness of what you are doing. there will be political battles, and often, there will be issues with people rather than issues with technology or process. Additionally, everyone knows how to test, but not everyone knows how to test with relevance. Remove the drudgery where you can, so that opening the testers eyes and having fresh energy to tackle real and important problems is emphasized. If "anyone can test", then examine the tests that anyone can do, then ask critically if that testing is providing value.
More to come, stay tuned :)!!!