Regardless of what we develop, what platform, what use case, everything we do at some point comes down to data. Without data there's not much point to using any application.
Lots of applications require copious amounts of data, reliably accessible, reliably recreateable, and confirmed content that will meet the needs of our tests. At the same time, we may want to generate loads of fresh data to drive our applications, inform our decisions, or give us a sense of security that the data we create is safe and protected from prying eyes. Regardless of who you are and where you are in the application development cycle, data is vital, and its care, feeding and protection is critical.
Smita Mishra is giving us a run down on Big Data / Enterprise Data Warehouse / ETL Process (Extract, Transport, Load) and Business Intelligence practices. We can test with 1KB of data or 1TB of data. The principles of testing are the same, but the order of magnitude difference can be huge.
Big Data in my world view is used to describe really large sets, so large that it cannot easily fit into a standard database or file system. Smita points out that 5 Petabytes or more defines "Big Data". Smita also showed us an example of an "Internet Minute" and what happens and transmits during a typical minute over the Internet. Is anyone surprised that the largest bulk of data comes from Netflix ;)?
Big Data requires different approaches for storage and processing. Large parallel systems, databases of databases, distributed cloud system implementations, and large scale aggregation tools all come into play. Ultimately, it's just a broad array of tools designed to work together to cut massive data amounts to some manageable level.
In my own world, I have not yet had to get into really big data, but I do have to consider data that spans multiple machines and instances. Additionally, while I sometimes think Business Intelligence is an overused word and a bit flighty in its meaning, it really comes down to data mining, analytical processing, querying and reporting. That process itself is not too hard to wrap your head around, but again, the order of magnitude with Big Data applications makes it a more challenging endeavor. Order of operations, and aggregation/drill down becomes essential. Consider it a little bit like making Tradizionale Balsamic Vinegar, in the sense that your end product effectively gets moved to ever smaller barrels as the concentration level increases. I'll admit, that's a weird comparison, but in a sense it's apt. The Tradizionale process can't go backwards, and your data queries can't either.
There are some unique challenges related to data warehouse testing. Consistency and quality of data is problematic. Even in small sample sets, inconsistent data formats and missing values can mess up tests and deployments. Big Data takes those same issues and makes them writ large. we need to consider the entry points of our data, and to extend that Tradizionale example, each paring down step and aggregation entry point needs to verify consistency. If you find an error, stop that error at the point that you find it, and don't case it to be passed on and cascade through the system.
Wednesday, April 6, 2016
Continuous Testing: Live from #STPCON
Continuous Testing is one of the holy grails of deployment. We've got the continuous integration piece down, for the most part. Continuous testing, of course fits into that paradigm. The integration piece isn't helpful if changes break what's already there and working. From my own experience, the dream of push button build, test and deploy feels close at hand, but somehow there's enough variance that we don't quite get there 100%. This is for an organization that deploys a few times a week. Now imagine the challenge if you are at an organization that deploys multiple times every day.
Neil Manvar is describing his time at Yahoo! working on their mail tool, and some of the challenges they faced getting the automated testing pieces to harmonize with the integration and deployment steps. Some of the ways they dealt with making a change from a more traditional waterfall development approach to an Agile implementation was to emphasize more manual testing, more often. Additionally, the development team aimed to help in the process of testing. Plus in that there were more testers, but minus in that programmers weren't programming when they were testing. Later, the brute force release approach became too costly to continue, so the next step was to set up a CI server using selenium tests, running an internal Grid and coordinating the build and test steps with Jenkins. Can you guess where we might be going from here ;)?
Yep, unreliable tests, need to rework and maintain brittle tests, limited testability, limited testability baked in, etc. Thus, while the automation was a step towards the goal, there was still so much new feature work happening that the automation efforts couldn't keep up (hence, more of a reliance on even more manual testing). A plus from this was that the test teams and the development teams started talking to each other about ways of writing robust and reliable tests, and providing the infrastructure and tooling to make that happen.
This led to a focus on continuous delivery, rapid iteration, and allowing for the time to develop and deploy the needed automated tests. In addition, the new management mandate was regular delivery of software, not just over a period of weeks, but multiple deploys per day. What helped considerably was that senior management gave the teams the time and bandwidth to help them implement the automation, including health checks, maintenance steps, iron out the deployment process, and ultimately enforce a discipline to pull requests and merges so that the deployment pipeline, including build, test, and deployment, would be as hands off as possible. Incrementally updating also improved the stability of the product considerably (which, I can totally appreciate :) ).
Ok, so this is all interesting, but what was the long term effects of making these changes? Ultimately, it allowed QA to expand their skill set and take the busywork off of their plates (or a large amount of it) so they could focus on more interesting problems. Developers were able to emphasize development, including unit tests and more iterative improvement. Accountability was easier to implement, and see where the issues were introduced, and by who. Additionally, a new standard of quality was established, and overall, features were delivered more quickly, uptime improved, new features were deployed and overall satisfaction with the product improved (and with it, revenue, which is always a nice plus ;) ).
Neil Manvar is describing his time at Yahoo! working on their mail tool, and some of the challenges they faced getting the automated testing pieces to harmonize with the integration and deployment steps. Some of the ways they dealt with making a change from a more traditional waterfall development approach to an Agile implementation was to emphasize more manual testing, more often. Additionally, the development team aimed to help in the process of testing. Plus in that there were more testers, but minus in that programmers weren't programming when they were testing. Later, the brute force release approach became too costly to continue, so the next step was to set up a CI server using selenium tests, running an internal Grid and coordinating the build and test steps with Jenkins. Can you guess where we might be going from here ;)?
Yep, unreliable tests, need to rework and maintain brittle tests, limited testability, limited testability baked in, etc. Thus, while the automation was a step towards the goal, there was still so much new feature work happening that the automation efforts couldn't keep up (hence, more of a reliance on even more manual testing). A plus from this was that the test teams and the development teams started talking to each other about ways of writing robust and reliable tests, and providing the infrastructure and tooling to make that happen.
This led to a focus on continuous delivery, rapid iteration, and allowing for the time to develop and deploy the needed automated tests. In addition, the new management mandate was regular delivery of software, not just over a period of weeks, but multiple deploys per day. What helped considerably was that senior management gave the teams the time and bandwidth to help them implement the automation, including health checks, maintenance steps, iron out the deployment process, and ultimately enforce a discipline to pull requests and merges so that the deployment pipeline, including build, test, and deployment, would be as hands off as possible. Incrementally updating also improved the stability of the product considerably (which, I can totally appreciate :) ).
Ok, so this is all interesting, but what was the long term effects of making these changes? Ultimately, it allowed QA to expand their skill set and take the busywork off of their plates (or a large amount of it) so they could focus on more interesting problems. Developers were able to emphasize development, including unit tests and more iterative improvement. Accountability was easier to implement, and see where the issues were introduced, and by who. Additionally, a new standard of quality was established, and overall, features were delivered more quickly, uptime improved, new features were deployed and overall satisfaction with the product improved (and with it, revenue, which is always a nice plus ;) ).
Demystifying the Test Automation Pyramid: Live from #STPCON
One of the key things I look for in talks is not to find things that I am good at (otherwise, really, what's the point of going?) but to visit and examine areas where I could use improvement or, to be frank, may just not be all that savvy about at all. Jim Hazen and I have communicated through Twitter and testing channels for years, and I have often appreciated his insights on writing test automation, specifically because he highlights the pitfalls that often get glossed over.
One of those areas is the Test Automation Pyramid. What's that you say? Well, there are different levels of automation, and foundations that automation is built on. Really, that's the core of the idea of a test automation pyramid. We build up from a lower foundation to get more specific and more focused, just as a pyramid start broad and wide and rises to a point at the top. Different levels and contexts require a different focus, some larger than others, but all structurally important. Commonly, this pyramid is structured in three layers: Unit Tests at the base , Service Tests in the middle, and UI tests at the top. Some benefits here are that by considering these tests in their places and consider them in order of creation, we put test design up front and carry it through the whole process.
Sometimes we look at the pyramid and we equate placement with importance. UI tests are at the top, and the smallest part of the pyramid, so that means they really aren't as important... right? Well, no, that's not what it means at all. What it does mean is that, by focusing on the Unit and Service tests, we are able to put in place logic and fixtures we can use higher up the pyramid. UI tests have value, but yes they can be finicky if the work below it hasn't been done or done well. Also, many think that because the Unit tests are at the bottom of the pyramid that that should be most of your tests. Well, not quite. The idea of unit tests is atomic testing of elements (methods, functions, etc.) and to make sure that we have a strong sense the tests are validating the functionality of the smallest elements of the code. They re numerous by their very nature, and by developing robust unit tests, we can develop a base for Service and UI tests. So does that mean the pyramid diagram is wrong? Potentially, but it still serves as a good way to look at the structuring of tests, timing and precedence. The pyramid is meant to be a guideline, not hard and fast rules.
Think about it this way. The extent of unit testing may result in a test for each line of code, and sometimes more. Positive and negative conditions may be exercised, and the basis of those unit tests can be used to help develop fixtures to help test higher up the pyramid. Additionally at the unit test level, we can look at ways to build testability and instrumentation into the product from the ground up. Where is that insight likely to happen? Probably at the component level. write a lot of unit tests, and it's likely procs and fixtures will come out of it, because good programmers are lazy, and that is a very good thing :).
When someone tells you they are going to do 100% automation, take a step back and realize that it's never going to happen. There's a lot that can be done, but there are still a lot of tests that require eyes, ears, and brains to determine and evaluate. Having said that, the tools are getting us closer to that 100%, but we still have quite a ways to go.
Another helpful rule of thumb is to think of tests getting more granular as you go down the pyramid, and becoming more complex the higher up the pyramid you go. Tools help, but no tools covers all of these areas comprehensively. No one tool will solve all of your problems. Custom code will very likely be required to make sure each of the levels and layers can play well with each other. Someone needs to write that code, and its likely a new tester writing automated tests will not be the ideal candidate for that job (they may well grow into it over time, but unlikely at the early part of their careers).
We also need to have a chat with management and set realistic expectations. See above about one tool to rule them all (hint, there isn't one). You need a staff with proper skills at each level. You may get lucky and find all of them in one person, but it's more likely you will have a bunch of people that have those skills. Ge them together and talk amongst themselves.
Overall interesting model, much of it makes sense, some of it breaks down, but taken in the spirit in which it was originally designed, it's quite useful, even if it should be more of a broad parallelogram, but that's nowhere near as catchy ;).
One of those areas is the Test Automation Pyramid. What's that you say? Well, there are different levels of automation, and foundations that automation is built on. Really, that's the core of the idea of a test automation pyramid. We build up from a lower foundation to get more specific and more focused, just as a pyramid start broad and wide and rises to a point at the top. Different levels and contexts require a different focus, some larger than others, but all structurally important. Commonly, this pyramid is structured in three layers: Unit Tests at the base , Service Tests in the middle, and UI tests at the top. Some benefits here are that by considering these tests in their places and consider them in order of creation, we put test design up front and carry it through the whole process.
Sometimes we look at the pyramid and we equate placement with importance. UI tests are at the top, and the smallest part of the pyramid, so that means they really aren't as important... right? Well, no, that's not what it means at all. What it does mean is that, by focusing on the Unit and Service tests, we are able to put in place logic and fixtures we can use higher up the pyramid. UI tests have value, but yes they can be finicky if the work below it hasn't been done or done well. Also, many think that because the Unit tests are at the bottom of the pyramid that that should be most of your tests. Well, not quite. The idea of unit tests is atomic testing of elements (methods, functions, etc.) and to make sure that we have a strong sense the tests are validating the functionality of the smallest elements of the code. They re numerous by their very nature, and by developing robust unit tests, we can develop a base for Service and UI tests. So does that mean the pyramid diagram is wrong? Potentially, but it still serves as a good way to look at the structuring of tests, timing and precedence. The pyramid is meant to be a guideline, not hard and fast rules.
Think about it this way. The extent of unit testing may result in a test for each line of code, and sometimes more. Positive and negative conditions may be exercised, and the basis of those unit tests can be used to help develop fixtures to help test higher up the pyramid. Additionally at the unit test level, we can look at ways to build testability and instrumentation into the product from the ground up. Where is that insight likely to happen? Probably at the component level. write a lot of unit tests, and it's likely procs and fixtures will come out of it, because good programmers are lazy, and that is a very good thing :).
When someone tells you they are going to do 100% automation, take a step back and realize that it's never going to happen. There's a lot that can be done, but there are still a lot of tests that require eyes, ears, and brains to determine and evaluate. Having said that, the tools are getting us closer to that 100%, but we still have quite a ways to go.
Another helpful rule of thumb is to think of tests getting more granular as you go down the pyramid, and becoming more complex the higher up the pyramid you go. Tools help, but no tools covers all of these areas comprehensively. No one tool will solve all of your problems. Custom code will very likely be required to make sure each of the levels and layers can play well with each other. Someone needs to write that code, and its likely a new tester writing automated tests will not be the ideal candidate for that job (they may well grow into it over time, but unlikely at the early part of their careers).
We also need to have a chat with management and set realistic expectations. See above about one tool to rule them all (hint, there isn't one). You need a staff with proper skills at each level. You may get lucky and find all of them in one person, but it's more likely you will have a bunch of people that have those skills. Ge them together and talk amongst themselves.
Overall interesting model, much of it makes sense, some of it breaks down, but taken in the spirit in which it was originally designed, it's quite useful, even if it should be more of a broad parallelogram, but that's nowhere near as catchy ;).
Automation for the People: Live from #STPCON
Automation is often couched in the terms of tools and test automation. Christin Wiedemann thinks we need to look at this whole automation thing differently.
I've long been a believer that people put themselves into a box when they say they are good or not good at test automation. Part of the problem is that many people don't give themselves credit for the automation they do every day.have you written a script to run a sequence of commands, so you don't have to type them all the time. Guess what? You're automating.at it's core, that's really what automation is, it's a way to get sequential steps to run in the order you want, without you personally having to enter those commands. Everything else is an order of magnitude from that concept.
One of the biggest issues with automation is "waste". Yes, automation efforts can be every bit as wasteful as the manual efforts and waste they are hoping to replace. Too often, we emphasize the coding aspect of the endeavor, without really looking at all of the other elements that contribute to that.
Have we ever stopped to think about how silly the term "Automated Tester" sounds? What is an Automated Tester? is it a cyborg? A machine? When this term is being used, we really mean "a tester who is proficient at writing software test automation", but it also points to a bias and an attitude we need to think about. We want to automate testing... why? We want to get people out of the equation... again, why? I know what I often say is that I want to get the "busywork" out of the way, so that I can save my eyes and my attention for the really interesting stuff, or the areas that have not been explored yet.
We don't build code, we build a product. In that sense, every one of us in the engineering and delivery process is a developer. Yes, testers are developers, even if we may not be programmers (and again, more of you do more programming than you give yourselves credit for). There are many areas that automation will struggle to be of a benefit to, though each year it narrows the current gaps. Automation does offer some tremendous benefits when you need repeatability, or when you want to parallelize work. Running fifty tests on fifty different machines is a real plus for time. Setting up machines and getting them to an interesting state is also very time consuming, and there is a place where I wholeheartedly welcome automation. Time to market can influence a need for automation, but make no mistake, automation takes time and resources. It may set us up for a later time saving, but it will be expensive up front. That's not a criticism, but it is a reality check ;).
When we say "we want to replace manual testing with automation", what are we actually saying? How will we do it? What is the method we will employ? When will we do it? How long will it take? What's the most important areas to cover? If we can't quantify these questions, we will have a really hard time putting together a successful implementation.
There are a lot of myths around automation. It will save us time. It will save us money. It will get us to market faster. Can those ideals come to fruition? Sure, but probably not right away. In fact, at the beginning of an automation effort, you may go in the red on all of these areas before you get any sustainable benefits. Make no mistake, I am not a luddite decrying automation, I use it daily and I love using it. Deploying releases would be murderous without it. Setting up my development environment by hand would take a lot of time. Serially running tests can sap even the most energetic. Still, there's a lot that goes into creating automation, and there's a lot of work that needs to happen up front before any automation can happen. St the moment, systems cannot invent tests automatically (though there are some algorithms that can create dynamic test branches that on the surface look like they are creating tests out of thin air, but even there, it's based on known knowns). When we deal with new development and features, there needs to be thinking and planning and experimentation (exploring) while the programming is happening and, we hope, while unit tests are being written.
One thought I would say before we discuss the obvious (that is, coding) is that anyone involved in automation needs to know how to design repeatable, reliable and informative tests. I have met excellent programmers who struggle with designing good tests, and I've met people who can develop great tests but struggle with the coding part. Solution: get those two people together. Put that chocolate into the peanut butter (you may have to be my age to get that reference ;) ). Test automation requires planning, preparation, creation, execution, analysis, and reporting. All of those need to be considered and developed, and news flash, the automation programmer may not be the person best suited to perform all of those tasks :).
Christin makes the case that automation can be helped by developing personas, not so much for developing tests, but to determine what skills contribute to the process and who might have those skills. Personas go beyond a laundry list of attributes, it humanizes them and helps us see who can be helpful for each part of the journey. Remember, our goal here is to maximize the possibility our efforts will be successful, and to do that, it would help a lot to get as many people involved in it as possible, and leveraging the skills they bring to the table.
I've long been a believer that people put themselves into a box when they say they are good or not good at test automation. Part of the problem is that many people don't give themselves credit for the automation they do every day.have you written a script to run a sequence of commands, so you don't have to type them all the time. Guess what? You're automating.at it's core, that's really what automation is, it's a way to get sequential steps to run in the order you want, without you personally having to enter those commands. Everything else is an order of magnitude from that concept.
One of the biggest issues with automation is "waste". Yes, automation efforts can be every bit as wasteful as the manual efforts and waste they are hoping to replace. Too often, we emphasize the coding aspect of the endeavor, without really looking at all of the other elements that contribute to that.
Have we ever stopped to think about how silly the term "Automated Tester" sounds? What is an Automated Tester? is it a cyborg? A machine? When this term is being used, we really mean "a tester who is proficient at writing software test automation", but it also points to a bias and an attitude we need to think about. We want to automate testing... why? We want to get people out of the equation... again, why? I know what I often say is that I want to get the "busywork" out of the way, so that I can save my eyes and my attention for the really interesting stuff, or the areas that have not been explored yet.
We don't build code, we build a product. In that sense, every one of us in the engineering and delivery process is a developer. Yes, testers are developers, even if we may not be programmers (and again, more of you do more programming than you give yourselves credit for). There are many areas that automation will struggle to be of a benefit to, though each year it narrows the current gaps. Automation does offer some tremendous benefits when you need repeatability, or when you want to parallelize work. Running fifty tests on fifty different machines is a real plus for time. Setting up machines and getting them to an interesting state is also very time consuming, and there is a place where I wholeheartedly welcome automation. Time to market can influence a need for automation, but make no mistake, automation takes time and resources. It may set us up for a later time saving, but it will be expensive up front. That's not a criticism, but it is a reality check ;).
When we say "we want to replace manual testing with automation", what are we actually saying? How will we do it? What is the method we will employ? When will we do it? How long will it take? What's the most important areas to cover? If we can't quantify these questions, we will have a really hard time putting together a successful implementation.
There are a lot of myths around automation. It will save us time. It will save us money. It will get us to market faster. Can those ideals come to fruition? Sure, but probably not right away. In fact, at the beginning of an automation effort, you may go in the red on all of these areas before you get any sustainable benefits. Make no mistake, I am not a luddite decrying automation, I use it daily and I love using it. Deploying releases would be murderous without it. Setting up my development environment by hand would take a lot of time. Serially running tests can sap even the most energetic. Still, there's a lot that goes into creating automation, and there's a lot of work that needs to happen up front before any automation can happen. St the moment, systems cannot invent tests automatically (though there are some algorithms that can create dynamic test branches that on the surface look like they are creating tests out of thin air, but even there, it's based on known knowns). When we deal with new development and features, there needs to be thinking and planning and experimentation (exploring) while the programming is happening and, we hope, while unit tests are being written.
One thought I would say before we discuss the obvious (that is, coding) is that anyone involved in automation needs to know how to design repeatable, reliable and informative tests. I have met excellent programmers who struggle with designing good tests, and I've met people who can develop great tests but struggle with the coding part. Solution: get those two people together. Put that chocolate into the peanut butter (you may have to be my age to get that reference ;) ). Test automation requires planning, preparation, creation, execution, analysis, and reporting. All of those need to be considered and developed, and news flash, the automation programmer may not be the person best suited to perform all of those tasks :).
Christin makes the case that automation can be helped by developing personas, not so much for developing tests, but to determine what skills contribute to the process and who might have those skills. Personas go beyond a laundry list of attributes, it humanizes them and helps us see who can be helpful for each part of the journey. Remember, our goal here is to maximize the possibility our efforts will be successful, and to do that, it would help a lot to get as many people involved in it as possible, and leveraging the skills they bring to the table.
Home Field Advantage: Welcome to #STPCON
It's here. After months of waiting working, tweaking and applying ideas, Software Test Professionals Conference (STP-Con) has come to Millbrae, California. I cannot begin to explain how nice it feels to be able to attend a conference that consists of total travel time from my house to venue of less than fifteen minutes.
I had a great opportunity Monday to teach and facilitate a workshop on "Teaching New Software Testers", and I received some great feedback about where the material is on track, where it can be improved, and some new ideas to consider adding to future presentations. Since it's an extra pay item, I'm not going to blog about all of the details from that talk, but if you read my blog regularly, you probably already know what I've covered :).
Tuesday night we had a Meet & Greet at Steelhead Brewery in Burlingame, and I was really happy to have two special guest attend with me; my daughters Karina and Amber. They have both expressed interest about learning more about tech and how it might be something they can contribute to in the future, and it was wonderful to see so many of my colleagues reach out to them, include them in conversations, talk about their careers, and other avenues that might get them excited. I want to give special thanks to Smita Mishra for taking the girls under her wing and introducing them to so many people, and to Ben Kelly for hanging out with them and talking all things Japan and Game of Thrones. On the drive home last night, they were happy and excited to have attended, and mentioned key conversation points and things that interested them.
Today is the first day of the conference proper, and that means the TESTHEAD live blog is now in full swing. There will be individual posts for each session other than mine (I'll post a summary of my session later ;) ).
We start off today with Karen Jonson giving a keynote about "How Nancy Drew Prepared Me to Become a Software Tester", but before she got into the main topic, she gave some great advice for career curation, including encouraging attendees to attend sessions that are relevant to their current work, but to also look for something that makes you stretch or may be outside of your current focus. You may or may not be working at the same company a year from now, but your career carries with you. Attend sessions that will grow you not just for now, but into the future, too.
For those not familiar with Nancy Drew, she's an iconic literary figure in children's books. She has different names in different countries, but she's a young lady who solved mysteries. a quote include in Karen's talk was that "Women in many occupations told of learning from Nancy to see adventures in problem solving and the joy of self-reliance". That's a great description of a software tester, too, isn't it :)? Every product is its own unique mystery. Now, to be frank, I didn't read many Nancy Drew books, but I read the Hardy Boys, which was the mystery series aimed for boys, while Nancy Drew was aimed to girls. If that seems a little closed minded, please realize, I was a boy in the seventies. I did boy things, but later on, I learned more about Nancy Drew, and especially wanted to learn more about her when my daughters came into my life. The Hardy Boys and Nancy Drew books are similar in format, and in delivery. They both let the reader get drawn into problems and challenges, and follow along as the protagonist learns more about the situations, and they get to test out their own hypothesis about "whodunnit". These really are wonderful primers to help encourage young readers to see the mysteries and how they might solve them.
I've been a fan of the metaphor of tester as "beat reporter", but "detective" is a natural fit as well. We often have to take on different domains. They put themselves in unfamiliar situations. They observe, they take notes, the look for situations that could potentially be dangerous, and they present the case to find the "whodunnits". Karen mentions a book called "Making Thinking Visible", and how it allows people to visualize problems. The basic idea is the triplet of See/Think/Wonder. Testing at its core uses these three words, if you step back and think about it. Additionally, another triplet is Think/Pair/Share. We don't want testing to be a mystery, we want to be open and share our findings. The more people that look at testing as cognitively challenging and interesting, the more people will get involved with it, and frankly, we need more testers, even if tester is not part of their title.
Consider the fact that what we think about things changes as we get new information. We are conditioned to think tht changing our minds shows a weakness. It shouldn't. We should embrace the idea that "I used to think.... but now I think..." because that means that we are actively considering what we are learning. We should not get so tied up in our world view, because new information can change the entire trajectory of what we are doing. We should be open to and welcome that, even though that may be uncomfortable. We should embrace active thinking, and we should approach things with wonder. Believe me, that can be hard when you've tested something multiple times. "been there, done that" is not just mind numbing, it's dangerous, because that's the condition where we are most vulnerable to missing things. We get blind to what we see all the time, and we take shortcuts in our heads because we know what's happening... or so we think.
Ultimately, the same traits that excite the imagination the way that Nancy Drew mysteries (and OK, Hardy Boys mysteries for me when I was a kid), they really do give some great parallels as to how we can re-engage and make testing much more interesting.
I had a great opportunity Monday to teach and facilitate a workshop on "Teaching New Software Testers", and I received some great feedback about where the material is on track, where it can be improved, and some new ideas to consider adding to future presentations. Since it's an extra pay item, I'm not going to blog about all of the details from that talk, but if you read my blog regularly, you probably already know what I've covered :).
Tuesday night we had a Meet & Greet at Steelhead Brewery in Burlingame, and I was really happy to have two special guest attend with me; my daughters Karina and Amber. They have both expressed interest about learning more about tech and how it might be something they can contribute to in the future, and it was wonderful to see so many of my colleagues reach out to them, include them in conversations, talk about their careers, and other avenues that might get them excited. I want to give special thanks to Smita Mishra for taking the girls under her wing and introducing them to so many people, and to Ben Kelly for hanging out with them and talking all things Japan and Game of Thrones. On the drive home last night, they were happy and excited to have attended, and mentioned key conversation points and things that interested them.
Today is the first day of the conference proper, and that means the TESTHEAD live blog is now in full swing. There will be individual posts for each session other than mine (I'll post a summary of my session later ;) ).
We start off today with Karen Jonson giving a keynote about "How Nancy Drew Prepared Me to Become a Software Tester", but before she got into the main topic, she gave some great advice for career curation, including encouraging attendees to attend sessions that are relevant to their current work, but to also look for something that makes you stretch or may be outside of your current focus. You may or may not be working at the same company a year from now, but your career carries with you. Attend sessions that will grow you not just for now, but into the future, too.
For those not familiar with Nancy Drew, she's an iconic literary figure in children's books. She has different names in different countries, but she's a young lady who solved mysteries. a quote include in Karen's talk was that "Women in many occupations told of learning from Nancy to see adventures in problem solving and the joy of self-reliance". That's a great description of a software tester, too, isn't it :)? Every product is its own unique mystery. Now, to be frank, I didn't read many Nancy Drew books, but I read the Hardy Boys, which was the mystery series aimed for boys, while Nancy Drew was aimed to girls. If that seems a little closed minded, please realize, I was a boy in the seventies. I did boy things, but later on, I learned more about Nancy Drew, and especially wanted to learn more about her when my daughters came into my life. The Hardy Boys and Nancy Drew books are similar in format, and in delivery. They both let the reader get drawn into problems and challenges, and follow along as the protagonist learns more about the situations, and they get to test out their own hypothesis about "whodunnit". These really are wonderful primers to help encourage young readers to see the mysteries and how they might solve them.
I've been a fan of the metaphor of tester as "beat reporter", but "detective" is a natural fit as well. We often have to take on different domains. They put themselves in unfamiliar situations. They observe, they take notes, the look for situations that could potentially be dangerous, and they present the case to find the "whodunnits". Karen mentions a book called "Making Thinking Visible", and how it allows people to visualize problems. The basic idea is the triplet of See/Think/Wonder. Testing at its core uses these three words, if you step back and think about it. Additionally, another triplet is Think/Pair/Share. We don't want testing to be a mystery, we want to be open and share our findings. The more people that look at testing as cognitively challenging and interesting, the more people will get involved with it, and frankly, we need more testers, even if tester is not part of their title.
Consider the fact that what we think about things changes as we get new information. We are conditioned to think tht changing our minds shows a weakness. It shouldn't. We should embrace the idea that "I used to think.... but now I think..." because that means that we are actively considering what we are learning. We should not get so tied up in our world view, because new information can change the entire trajectory of what we are doing. We should be open to and welcome that, even though that may be uncomfortable. We should embrace active thinking, and we should approach things with wonder. Believe me, that can be hard when you've tested something multiple times. "been there, done that" is not just mind numbing, it's dangerous, because that's the condition where we are most vulnerable to missing things. We get blind to what we see all the time, and we take shortcuts in our heads because we know what's happening... or so we think.
Ultimately, the same traits that excite the imagination the way that Nancy Drew mysteries (and OK, Hardy Boys mysteries for me when I was a kid), they really do give some great parallels as to how we can re-engage and make testing much more interesting.
Friday, March 18, 2016
Come See TESTHEAD Speak at STP-CON 2016 in Millbrae, California
First of all, I will be giving a half day workshop/tutorial based around "Teaching New Software Testers". I'm sure some of you looked at that title and said "ah well, I'm not a new software tester, so that's not relevant to me." However, this workshop is not geared towards new testers, it's actually geared towards those who will mentor new software testers. My guess is that's a significantly larger audience. The workshop is built around the materials that were prepared with several contributors, along with myself, for the SummerQAmp program.
We put together six modules (What is the Scientific Method?, What is Testing?, What is Context?, What is Bias? What is the SDLC/STLC?, What is Bug Reporting? How Does the Web Work?). These modules have been field tested, we've received a good deal of feedback, and some cool experiments have grown out of the work with these modules and test mentors who have used them to train new testers, some with zero experience in testing whatsoever. This session will be light on talk, and will focus much more on exercises and action. In short, each participant will get a chance to mentor and be mentored. Each participant will get the stack of materials that made up the SummerQAmp materials (developed with the help of the Association For Software Testing and creative commons licensed). In short, if you want to possibly pick up some new approaches to talking about testing with new testers, this may be up your alley. Come join us April 4, 2016, 9:00a.m. - 12:00p.m. in the Poplar Room.
My second talk (this is just a talk, so less of a time commitment) covers The Intersection of Accessibility and Inclusive Design. Wait, what?!
Accessibility focuses on designing products that allow those who otherwise could not use them to gain access to information and services. It makes this possible through assistive technology (screen readers, close captioning, voice dictation, joystick controllers, etc.). This is important work, but I want to also emphasize there's a lot we can do to make software applications even more usable by as many people as possible. This is the core idea behind Inclusive Design. We will give examples of both accessibility, and show apps that have taken advantage of, whether by design or by happy accident, principles to make software that is usable by the most people possible. Come join us April 6, 2016, from 2:30p.m. - 3:30p.m. in the Hickory/Hawthorn room.
Just a couple weeks to go. Can't wait to see you all in my neck of the woods!
Thursday, March 17, 2016
Introducing... The Testing Show!!!
Qualitest Group has agreed to do a run of podcasts with Matt Heusser, Justin Rohrman and me as regualr attendees, along with Brian Van Stone from Qualitest and a revolving cast of what we hope will be many people in the software testing world to interact with us and talk testing topics, news of the day, and have a slight propensity for silliness at times.
We have posted the first three episodes at "The Testing Show" page. The first three episodes cover "Skill on the Test Team", "Testing as a Trusted Advisor" and "Testing When You Don't Have Enough Testers". We have a couple more episodes that will be posted within the next week, and then we aim to keep up to date with a new post every two weeks.
So what do we want you all to do? Well, we want you to listen. We want you to comment. We want you to suggest topics for us to talk about. Most of all, if you like what you hear, we want to have you share it with others. The more people listen, like, and respond to the podcast, the more likely that Qualitest will book us to do more shows in the future. We should also mention that while Qualitest is sponsoring the show, The Testing Show is not being used to market Qualitest, at least not directly. Of course they want to encourage people to consider them, but Qualitest does not tell us what to say or tell us what topics we cover. We do that ourselves.
Anyway, it's been a long time. Come join us, and if you genuinely enjoy what you hear, considering getting in on the action with us. We are always interested in topics and guest speakers, so if you want to participate, let us know :)!
Friday, March 11, 2016
Aedificamus: Book Review: The Negative Calorie Diet
Rocco DiSpirito is a celebrity chef, and has appeared in a number of media outlets over the past decade plus. I have heard him on Kara Rota's "Clever Cookstr" podcast. It was the most recent episode, in fact that covered "The Negative Calorie Diet" that finally made me say "all right, I'm curious, what is the premise and what is on offer with this?" (I'm reviewing the Kindle version of this book, just in case anyone is curious).
First things first, what in the world is a "negative calorie diet"? That doesn't make any sense on the surface, and in truth, there really isn't a truly "negative" food, is there? What is DiSpirito driving at here? Turns out that what he is really emphasizing is eating whole, unprocessed foods that, when taken in and metabolized, the net effect is that your body, on balance, works harder to digest them than the nutrient content provides. DiSpirito identifies three aspects to foods that make them "negative calorie foods".
Whole foods rather than processed foods
The idea here is that whole, unprocessed or very lightly processed foods contain more fiber and denser nutrient profiles as compared to processed foods. The density of the nutrient profile, as well as the inclusion of cellulose, bran, germ and other components of a whole food diet means your body has to work harder to process and break down the food consumed than the total calories that food provides. This sounds a little far fetched, but I've actually seen this in action, especially when I buy bulk vegetables like cauliflower, broccoli and carrots. There's a lot of volume to make two hundred calories of these vegetables, with fiber and water making up a large percentage.
The Fat Burn Factor
Here the idea follows the thought that certain foods provide a low level "work load" in your body, and by the virtue of that consistent work load, it is priming the body for fat burning. DiSpirito points out that certain foods like cruciferous vegetables and protein have a "thermic effect", in that your body works harder to break down these foods, and in the process, requires more fuel to do its work. Granted, the workload is not on the same scale as, say, a strenuous weightlifting session or high intensity training activities, but it's not insignificant, either. By leveraging this thermic property of certain foods, the net result can be more calories burned than consumed.
The Fullness Factor
Skeptic hat firmly on, here's where I think a large part of this "diet" really comes into play. By focusing on whole, unprocessed foods, we are taking them in in their least broken down state. Whole oranges are going to take up more room in our stomach than orange juice. Fiber and water take up space. Proteins and fats have the ability to let our brain know that we have some dense stuff to work through. In short, we get full on items that take up space, rather than consuming small, concentrated convenience foods that may taste good, but are largely concentrated, small volume items that pack in a lot of calories but offer little in the way of satiation. In certain circumstances, that's fine. When I go on a backpack trip, I personally love having calorically dense foods in very small and light containers. Less to carry and more fuel for the pound, but that's not what I do, or should do, every day. In most cases, allowing myself to be filled by whole foods, chased with water in most cases, I should find myself in situations where I am not hungry, I am full and satisfied with my meals, and ultimately, my body is burning more energy working through the food I am eating than I am actually consuming.
"The Negative Calorie Diet" is split into three sections.
Part One talks about the Negative Calorie Diet concepts, and describes the philosophy behind the diet (much of which is explained in the three points above) and highlighting foods that help reach the goals DiSpirito sets out. It then goes into a thirty day "course" the reader can choose to take to get results from the diet as described. The first ten days are described as a "cleanse". Skeptic hat back on; I tend to think of the notion of "detox" to be food quackery, but as it is termed here, it's really more an adjustment of the food items consumed, and for the first ten days, it leverages eating via smoothies, soups and salads. In other words, we are aiming to up the intake of a lot of food items we may not already be consuming. In that light, I'm OK with the process. The next twenty days goes into preparing three meals and one snack each day, with the goal of not worrying about portion or calorie count. It may sound like DiSpirito is saying you an eat as much as you want of these foods, and in a way, that's true, but really, what's going on is that you will likely find yourself full before the size of the caloric payload will be of much concern. This section also provides shopping lists for the items recommended for each of the days in question, as well as links to the recipes in the book for each meal.
Part Two covers the Negative Diet Recipes. For many, this may be all you are really interested in. To that end, there are indeed a lot of options.
Chapter 6 is all about Smoothies, fifteen to be specific, with tastes ranging everywhere from fruits to vegetables to a Virgin Mary smoothie for good measure (memories of "Tuna Shake, Baby!" are going through my head right now from years on the misc.fitness.weights newsgroup in the 1990s, but this is a little different ;) ).
Chapter 7 focuses on Breakfasts, providing nine recipes ranging from a breakfast "risotto" to Mexican cauliflower chili and spinach and mushroom omelets.
Chapter 8 covers Soups and Salads. Fifteen options are available here, and an emphasis is placed on variety, fresh ingredients, and a judicious use of spices. There are options for omnivores as well as vegetarians and vegans.
Chapter 9 goes into Mains, and provides seventeen entrees that, again, cover a broad variety of cuisine styles, ingredients, and dietary goals. Various cuts of meat, seafood, vegetables, fruits and spices make their way into these recipes, and again, there's sure to be something to please just about everyone.
Chapter 10 brings us to the topic of Snacks. Yes, snacks are encouraged, as long as you are the one making them and they use the foods recommended to reach the negative calorie goals. Eight unique ideas ranging from homemade cucumber and almond sushi, red ants on a log (which is really celery stalks, peanut butter and cranberries, which frankly works fine for me :) ), to making your own granola bars.
Chapter 11 is Desserts. Yep, desserts. We all crave sweets, so rather than deny us the pleasure, DiSpirito has developed options that let us enjoy them, albeit with some modifications. Almond cake, crepes suzette, citrus and berry bowls with whipped topping, no need to deny your sweet toth while pursuing this course.
Part Three focuses on The Negative Calorie Lifestyle. DiSpirito's aim is to encourage healthy eating for the long haul, and to that end, he makes a number of suggestions. Go meatless, or barring that, use meat sparingly and up your intake of fresh fruits and vegetables. Encourage your family to participate in this approach with you. To this end I am painfully aware that it is much harder to eat when you are preparing your food separate from the rest of the family. Getting everyone on board makes for a big boost in the likelihood the habits you develop will stick. Eating Out and On the Go need not be a black hole of unhealthy food or limited options, but it helps to be forewarned and forearmed, and DiSpirito devotes a chapter to suggested approaches for a variety of restaurants and cuisine styles. The last chapter focuses on Maintenance, and helping you keep to the habits while losing weight, and in that approach, keeping the weight off.
Bottom Line:
The title is a bit gimmicky, but the concept DiSpirito is describing does make sense, and I've used variations of it myself over the past seven months as I have lost close to 70 pounds. It is entirely possible to expend more energy than we consume, and that ultimately helps us develop a deficit so that we lose weight. The ideas in "the Negative Calorie Diet" do indeed meet that goal, both through nutrient quality and variety, as well as nutrient density, including insoluble fiber and water. If I have to offer a criticism, it's that there are a lot of terms and studies thrown around in the sections setting up the first part of the book, but no references to those studies. Granted, this is a cookbook, so that may be overkill, but I would think that, at least, a list of studies as an Appendix would be a huge plus. Yes, we live in the era of Google and the ability to search, but some more clarity on where these terms came from and the basis for making the claims would have been nice.
Even if you are not interested in going all out and living a "Negative calorie lifestyle" but want to see how to create some interesting whole food options, and perhaps try some things you've never had before that would taste great and also be overall healthy, there is much to like here.
Thursday, March 10, 2016
Happy 6th Birthday, TESTHEAD
Time flies.
Six years ago today, I initiated an opening salvo that I had hoped would help me develop some more interest in my chosen career. It was a way to get me out of a rut, to make me re-examine my thinking, and to engage with the community.
Well, that's what I'd like to believe was why I started it, but truth be told, what I just said is the result of what happened because I started it. The original entry actually looks a lot like this (OK, it looks exactly like this):
Wednesday, March 10, 2010
Welcome to TESTHEAD
OK, why the need for a blog like this? Well, truth be told, I don’t know that there really is a “need” for this blog, but I’m doing this as a challenge to myself. I consider this an opportunity to “give back” to a community that has helped me over the course of many years, as I have been the beneficiary of many great insights and learned a lot from a number of people and sources over nearly two decades.
First off, professionally, I am a Tester. It's been what I've done in one way, shape or form for most of my career. As such, I am strangely drawn to the fine art of "breaking things on purpose" and then trying to find ways to improve the process so that they do not break again.
Being a Tester requires a bit of many disciplines. Saying "I like to test things" really isn't enough. A good Tester needs to have some understanding of the Software Development Cycle. This means that, to really be good at what they do, they need to "embrace the code", and I'll be the first to say I've had my fair share of ups and downs with that. They also need to have some skills with troubleshooting systems and finding solutions to issues. They need to be able to communicate to a broad group of people as to what they are doing, and ultimately, they need to be a part of the solution to the issue whenever possible. It's in the spirit of those areas I hope to contribute something here.
Most of all, this will be a site where I share my own experiences, both good and bad, and what I've learned from them. Expect there to be talk about tools, both proprietary and open source. Expect some talk about test case design (and how I so hate to do it at times). Expect to hear me vent about some frustrations at times, because like all people, I have my share of frustrations when things don't seem to work correctly or go the way that I planned them to. Expect me to share ideas on testing that don't divulge too much of what I do at my day job... much as I find what I do interesting, chances are there's not much anyone who is not in my particular niche market (software applications for the Legal industry) will be able to use outside of that area, but if I come across a cool concept or a neat way to do something, I'll definitely put a more generic example of it here. Most of all, expect to get a real person's perspective on these things and an attempt to communicate them in plain English, whenever I possibly can.
Opportunity to “give back” to the community - I think that's true.
Drawn to the fine art of "breaking things on purpose" and then trying to find ways to improve the process so that they do not break again - I've since changed my terminology here. Testers don't really break anything unless they maliciously and intentionally try to. I really don't do that, but I do try my best to uncover and discover what is already broken.
They need to "embrace the code", and I'll be the first to say I've had my fair share of ups and downs with that - this has proven to be more true than I originally intended, and I've gotten more "code involved" these past years, but more so in my role as release manager than in my role as tester.
They need to be able to communicate to a broad group of people as to what they are doing, and ultimately, they need to be a part of the solution to the issue whenever possible - I think that is still the spirit of how I try to operate, at least much of the time.
Most of all, this will be a site where I share my own experiences, both good and bad, and what I've learned from them - this has partially proven true, but I've realized less often than I intended. I've realized that this has been a springboard for many endeavors, and I've give many of them coverage here, but if there is a desire to get back to the true intention of TESTHEAD, I'd say I have some work to do right here.
Most of all, expect to get a real person's perspective on these things and an attempt to communicate them in plain English, whenever I possibly can - Wait, how can I have two most of all's? Looks like editorial oversight was not an early strong suit (and yes, I'm well aware some might say that is still true now, thankyouverymuch). Still, this is what I've always hoped this blog would be, a tester, working as a tester, talking about testing and other topics in something resembling "dude" as much as was possible. If I am doing well here, I aim to keep doing well. If not, I aim to do better.
Ultimately, this platform has been a springboard into a reality I didn't imagine I'd be inhabiting six years ago. The world is different, and I've grown and adapted along with it. In many ways, having this blog has been a touch point for my sanity, as well as a venting place to make sure I retained that sanity. Many books have been read and reviewed. Many Weekend Testing sessions have come and gone. Many podcast episodes have been recorded and announced (and there might be some more on that front in the not too distant future ;) ). I've been able to speak in a variety of places, including three trips to Europe. I've collaborated on a book with several others. I declared a "Year of Accessibility" learning and teaching along with Albert Gareev. I served on the Board of Directors with the Association for Software Testing for four years. I've written and published scores of articles in numerous magazines and portal sites. What's more, I've met many amazing people who have greatly enriched both my career and my life, and this humble little blog started all of that. To all who have been with me thus far, thank you so much. You are why I am still doing this, and I look forward to many more posts, and many more opportunities for interaction.
Six years ago today, I initiated an opening salvo that I had hoped would help me develop some more interest in my chosen career. It was a way to get me out of a rut, to make me re-examine my thinking, and to engage with the community.
Well, that's what I'd like to believe was why I started it, but truth be told, what I just said is the result of what happened because I started it. The original entry actually looks a lot like this (OK, it looks exactly like this):
Wednesday, March 10, 2010
Welcome to TESTHEAD
OK, why the need for a blog like this? Well, truth be told, I don’t know that there really is a “need” for this blog, but I’m doing this as a challenge to myself. I consider this an opportunity to “give back” to a community that has helped me over the course of many years, as I have been the beneficiary of many great insights and learned a lot from a number of people and sources over nearly two decades.
First off, professionally, I am a Tester. It's been what I've done in one way, shape or form for most of my career. As such, I am strangely drawn to the fine art of "breaking things on purpose" and then trying to find ways to improve the process so that they do not break again.
Being a Tester requires a bit of many disciplines. Saying "I like to test things" really isn't enough. A good Tester needs to have some understanding of the Software Development Cycle. This means that, to really be good at what they do, they need to "embrace the code", and I'll be the first to say I've had my fair share of ups and downs with that. They also need to have some skills with troubleshooting systems and finding solutions to issues. They need to be able to communicate to a broad group of people as to what they are doing, and ultimately, they need to be a part of the solution to the issue whenever possible. It's in the spirit of those areas I hope to contribute something here.
Most of all, this will be a site where I share my own experiences, both good and bad, and what I've learned from them. Expect there to be talk about tools, both proprietary and open source. Expect some talk about test case design (and how I so hate to do it at times). Expect to hear me vent about some frustrations at times, because like all people, I have my share of frustrations when things don't seem to work correctly or go the way that I planned them to. Expect me to share ideas on testing that don't divulge too much of what I do at my day job... much as I find what I do interesting, chances are there's not much anyone who is not in my particular niche market (software applications for the Legal industry) will be able to use outside of that area, but if I come across a cool concept or a neat way to do something, I'll definitely put a more generic example of it here. Most of all, expect to get a real person's perspective on these things and an attempt to communicate them in plain English, whenever I possibly can.
Opportunity to “give back” to the community - I think that's true.
Drawn to the fine art of "breaking things on purpose" and then trying to find ways to improve the process so that they do not break again - I've since changed my terminology here. Testers don't really break anything unless they maliciously and intentionally try to. I really don't do that, but I do try my best to uncover and discover what is already broken.
They need to "embrace the code", and I'll be the first to say I've had my fair share of ups and downs with that - this has proven to be more true than I originally intended, and I've gotten more "code involved" these past years, but more so in my role as release manager than in my role as tester.
They need to be able to communicate to a broad group of people as to what they are doing, and ultimately, they need to be a part of the solution to the issue whenever possible - I think that is still the spirit of how I try to operate, at least much of the time.
Most of all, this will be a site where I share my own experiences, both good and bad, and what I've learned from them - this has partially proven true, but I've realized less often than I intended. I've realized that this has been a springboard for many endeavors, and I've give many of them coverage here, but if there is a desire to get back to the true intention of TESTHEAD, I'd say I have some work to do right here.
Most of all, expect to get a real person's perspective on these things and an attempt to communicate them in plain English, whenever I possibly can - Wait, how can I have two most of all's? Looks like editorial oversight was not an early strong suit (and yes, I'm well aware some might say that is still true now, thankyouverymuch). Still, this is what I've always hoped this blog would be, a tester, working as a tester, talking about testing and other topics in something resembling "dude" as much as was possible. If I am doing well here, I aim to keep doing well. If not, I aim to do better.
Ultimately, this platform has been a springboard into a reality I didn't imagine I'd be inhabiting six years ago. The world is different, and I've grown and adapted along with it. In many ways, having this blog has been a touch point for my sanity, as well as a venting place to make sure I retained that sanity. Many books have been read and reviewed. Many Weekend Testing sessions have come and gone. Many podcast episodes have been recorded and announced (and there might be some more on that front in the not too distant future ;) ). I've been able to speak in a variety of places, including three trips to Europe. I've collaborated on a book with several others. I declared a "Year of Accessibility" learning and teaching along with Albert Gareev. I served on the Board of Directors with the Association for Software Testing for four years. I've written and published scores of articles in numerous magazines and portal sites. What's more, I've met many amazing people who have greatly enriched both my career and my life, and this humble little blog started all of that. To all who have been with me thus far, thank you so much. You are why I am still doing this, and I look forward to many more posts, and many more opportunities for interaction.
Monday, February 1, 2016
Aedificamus: Product Review: Fitbit Surge and Fitbit Portal
I have looked at these devices for awhile now, wondering if it made sense to buy one. Would I really use it? Would it be worth the investment? Are they durable enough to live through someone as awkward and clumsy as me? Following Christmas this past year, as we came into the first full week of the new year, I finally said “OK, let’s see what these things can offer”. There were certainly plenty of options to choose from, but for me, I figured if I was going to make the plunge, I’d go for the one that offered the most options to play with. That meant the FitBit Surge.
So what does this somewhat chunky digital watch on steroids offer?
It utilizes GPS Tracking. By way of triangulating your movements, it can determine the distance, pace and elevation climbed. From the main screen a couple of swipes can tell me the number of steps I’ve taken, how many miles I’ve covered, and how many flights of stairs I have climbed (up and down count as flights, so if you go up once and down once, you get two flights counted, etc.).
It can keep track of your heart rate throughout the day. On the device itself, you can see your current heart rate, and on the FitBit web portal or mobile app, you can see your heart rate throughout the day, and the zones your heart rate has tracked through.
You can see the number of calories you are burning throughout the day. It’s pretty cool to see what it says I have burned, especially when compared to what I track in other apps food-wise, such as LoseIt. I’m still just about thirty days into using it, so I’m not sure how accurate it is, but for what I do and the goals I’m currently reaching for, it’s been accurate enough.
You can have the Surge monitor your sleep patterns. It can be fooled into thinking you are asleep if you lay back on the couch and watch TV, so it’s not an optimal sleep tracker, but in general, it still does a pretty good job telling you when you are motionless and when you are restless and moving about in the night. Another nice little feature is that you can set silent alarms (several if you so choose) so that you can be alerted at various times, or woken up without noisy alarms.
You can set up call notifications and text alerts, so that you can get those updates on your wrist without having to dig for your phone. You can also control your music player on your phone or music player if sync’d via bluetooth.
The FitBit pairs with a number of different mobile devices (iPhone and Android) and it also comes with a wireless USB dongle that you can plug into your computer and sync your data there, if you so choose. The FitBit dashboard allows users to see lots of collected data on their activity, and also allow synchronization with other apps.
Standalone, I think the FitBit Surge is awesome. It tells me so much with just a few swipes, and what it tells me often spurs me on to keep doing better. It’s portal can collect a lot of data and you can look over days, weeks and months of past activity to discover trends and areas where you have improved, and areas where you need improvement. The sync options are good, but they are not universal. Apple’s Health app doesn’t sync with FitBit, but you can use a third party app like SyncSolver to read and write data. If you are using just a few companion apps, then this may be of little concern. The more apps you use, however, the more aware you have to be of the values being read and written to your various accounts. It’s very easy to get double and triple counts for activities if the proper read and write permissions are not set. Also, some apps incorporate the calories burned in activities as part of their calculations and some do not. An example is that, even though FitBit integrates with FitStar Yoga, when it reports the completion of activities, it still posts FitStar’s approximation of calories burned. In other activities that are manually posted (say through LoseIt) the option to select the FitBit and aggregate calories burned to the device and app is covered. Consider this a slightly long way of saying “check to make sure the data you are reporting and reading corresponds to what you are actually doing”.
Final detail to mention is that the Surge has a decent battery life, but even it runs down over the course of a week. You will have to take of the device and charge it for about two hours to get back to a full charge. FitBit utilizes a proprietary USB connector to charge. If you were hoping to use a generic micro USB connector like you might with so many other devices, sorry, FitBit Surge has its own cable, and you have to use it. It’s certainly not the end of the world, but it’s something to be aware of, and an encouragement to make sure you know where that cable is.
The FitBit Surge is a sweet little device, and on the whole I am quite happy with it. It’s flexible, adaptable, allows me to learn new stuff all the time, and its data portal is genuinely interesting. Syncing with iPhone apps in general is easy, though it has some quirks I’m still working with. It’s not a cheap investment, and you may decide you do not need all of the bells and whistles. If not, you can certainly get a lower priced FitBit item, or another brand. If, however, you are not full on Apple Watch geek mode, and want a device that can do a lot, tell you a lot about what you do, and not look obnoxious in the process, by all means, check out a FitBit Surge. Your body and health may well thank you for doing so.
Subscribe to:
Posts (Atom)