In this post, we’ll briefly outline how our hardware and robotics roadmap looks. We’ll also give you a feel for how work proceeded before we had a roadmap and how it has proceeded after we came up with one.
Why use a roadmap in the first place?
The return on investment on R&D is not obvious. Our R&D work, in the short term, seems to go waste and is largely ignored. On the other hand, employees like to know that they are making progress. They want some validation that the work they do matters. These two conflicting forces make it hard for us to help employees get started on R&D work. When they start, our employees want to know what exactly they will be accomplishing and why will it matter. We caved in and presented people with an inaccurate plan (a high-level roadmap) rather than no plan at all. And surprise, surprise! People had a much easier time getting started with R&D. Once they got started, they ignored the roadmap and generated their own next steps.
Why should a tester even look at this?
Because this is going to be a standard part of your work sometime in the next few years. To learn more, read The need for change (at Qxf2).
The hardware and robotics roadmap
We cannot see everything. But we have listed a collection of starting points for us to learn more about hardware. We’ll explain what kind of R&D we were performing before the roadmap and the kind of R&D we have done since then. The task we choose to perform on will be a child of the leaf node and will be made small enough to complete in a week. For example, designing a specific circuit using circuit.io. We haven’t really listed the tasks themselves because we found that any pre-defined notions we had of what we should do ended up limiting our learning and ability to adapt.
At a high level (blue nodes), here is what we listed:
1. Areas: We have listed some areas we want to explore. These are generally buzzwords you see in the news.
2. Tools: These are some of the tools we think we will end up using.
3. Experiment/Develop: We have some suggestions on what to experiment or develop when doing R&D on hardware and robotics.
4. Learn: Things which we want to know more about. We feel we can borrow a lot of ideas from these fields.
5. Resources: Places to keep in touch with what is happening in this field.
Where we started
Although we are writing this in 2017, we had more than inkling that we needed to hire hardware engineers, mathematicians and other people who did not have a traditional QA background. We hired Rohan Dudam, our first hardware engineer, in February 2016.
It was hard to tell Rohan what was expected of him. But we had set the expectation that he would have to learn software testing. We tried our best to explain the general trend we were seeing and how he can contribute to our R&D efforts. But without anything concrete, we struggled to get started. We started by trying to come up with a starter kit. Then, Rohan built Qxf2’s first robot – but this was child’s play for Rohan. He wasn’t too thrilled. We put our R&D effort on ice for a bit since Rohan had to be deployed to a client.
Baby step 1 – the Fitbit
Once he returned, our next attempt was to try and test the Fitbit. We simply chose one of the more popular (and affordable) hardware success stories in the market and decided to test Fitbit’s heart rate monitor. We ended up using colored papers, an Arduino and some motors. You can read about the Fitbit testing here. It took us about 2 months to do the technical work and another 1 month to write about it and polish the work.
Baby step 2 – an automated and configurable pothole
Once we wrapped up our work on the Fitbit, we explored autonomous cars for a month. This time around, we were quicker in identifying a problem that interested us. We learned that self-driving cars find it difficult to judge potholes. So we expected a lot of work and research to happen around this problem. We ended up building a configurable pothole to help with such development efforts. You can read about our automated and configurable pothole over here. This effort took us about 5 months. Roughly one month to read about self-driving cars. Three months to work on the hardware (includes fabrication time) and about one month to write about and polish the work. In the process, we discovered we need people with CAD skills too!
Progress since the roadmap
We started with writing a tutorial for internal Qxf2 employees so they could get started with hardware. The tutorial took a couple of weeks to write. It ended up being a little dry too. We stopped this effort at the end of two weeks and decided to revisit it when we had a more interesting hook.
We moved on to identifying starter kits that we could send it to new employees. We anyway purchase and ship a new laptop to employees. Adding on a simple electronics starter kit would not be such a large cost to the company. And new employees are usually impressionable and want to impress. So we decided to try out a starter kit. Our first attempt met with failure – the kit we bought was never delivered. Then, we tried to source all the individual components on our own and that never went anywhere. We have finally landed upon and purchased one new kit. Our next hire will be getting to use it.
We wanted to explore beacon technology. So we purchased Estimote beacons. We started reading about beacon technologies and wondering about their possible use. When we looked at Estimote’s SDK, we realized it would be good to learn how to write Android apps to connect to the beacon. So we have now set out to learn how to write Android apps in general.
Key takeaway: The roadmap helped us get started. We continue to land at places we would not have imagined. But that is ok. Discovering next steps is what happens naturally over the course of work.
Developing a feel for the work
No person at Qxf2 can be expected to know everything we are trying to cover. So it is important to develop a ‘feel’ for the progress. We feel much better about this starting point because it seems to have a number of characteristics that overlap with some of our previously successful starting points:
a) The work feels like a multi-purpose move. Learning how to write Android apps does help us eventually when testing beacons and other IoT devices. However, it also strengthens our mobile testing and software development skills.
b) There are ‘familiar’ elements. We have one foot firmly planted in an area we know well. So we aren’t leaping too far out of our comfort zone. The person doing the work has enough support within Qxf2 and on the Internet.
c) The engineer’s resume gets better. Our engineer, if he/she wishes to quit Qxf2, still has a very strong and relevant skill on their resume
Worth repeating
If you are planning on trying something similar with your team, we’d like to reiterate two things that have helped us:
a) keep the weekly tasks small and specific
b) don’t get too attached to deadlines
Just focus on what is being done and what you can learn from it.
Related posts
- Where is Qxf2 headed?
- The need for change (at Qxf2)
- An introduction to R&D at Qxf2
- An introduction to training at Qxf2
- An introduction to hiring and onboarding at Qxf2
- Experimenting with team structures at Qxf2
I want to find out what conditions produce remarkable software. A few years ago, I chose to work as the first professional tester at a startup. I successfully won credibility for testers and established a world-class team. I have lead the testing for early versions of multiple products. Today, I run Qxf2 Services. Qxf2 provides software testing services for startups. If you are interested in what Qxf2 offers or simply want to talk about testing, you can contact me at: [email protected]. I like testing, math, chess and dogs.
I’m honestly inspired by your works, how you do it, your sense of learning these skills and you do it and I would honestly love to join you guys in this venture and what you want me do I’m in and ready to learn.