Last week, I got an interesting email from LinkedIn which read:
“On Veterans Day, 11/11/11, LinkedIn and the White House will join forces to kick off the first ever Veterans Hackday. We are looking for hackers to put together projects that can improve any aspect of a veteran’s life.”
Cool! I started a discussion on LinkedIn asking if anyone wanted to be part of a distributed team. Before I knew it, there were all kinds of responses from others who wanted to participate. After generating all this interest, I read the rules and realized that all development work had to take place between 11/11 and 11/14! Could an application be built by a team with varying skill sets in such a short time? Not only did we only have four days, but two of those days were work days. We all had jobs and other responsibilities that took priority.
Well, the short time frame did create a challenge, but in the end, thanks to a talented group who was willing to volunteer a good chunk of their weekend, everyone found his or her place. Rick got the ball rolling by creating and administrating an environment. Anand, who acted as development lead, created a Forum and Job Board for Veterans using Drupal. Ravi helped to build out the site and looked into a feature that would highlight hero’s whereabouts, and Dimas quickly set to work on a logo for our new site. Suann acted as product owner and used her social media connections to solicit feedback from Vets. Manasa stepped in to help test and to hunt down answers for the team. Doug provided DBA and leadership skills and took responsibility for documenting our team submission. I acted in the role of “ScrumMaster,” organizing conference calls and team tasks. Partha and others who wanted to help but had limited availability provided feedback and acted as “cheerleaders,” supporting the team’s efforts.
Though I was uncertain whether or not we’d really be able to pull anything off, in the end the team did it! It was fun for me to be part of this self-directed team and get a feel for how it works to be constrained to a challenging “time-box.” But even more fun for me was working with a distributed team in which none of us had ever met. I’ve read and written a lot about distributed versus co-located teams. It’s a common argument that a team needs face-time to build trust. Having this experience proved to me that a team can be successful despite the many challenges of working remotely. In fact, I have additional respect for these team members because their commitment was strong enough that they were willing to work as a team without the benefit of knowing one another at all. Even without meeting in person, there is a bond when a team has a common purpose and works together to achieve something.
Thanks to this competition, there’s a whole gallery of submissions of innovative applications for veterans. It’s amazing what can be accomplished in four short days! This is one contest where we’re all winners. Congratulations to all the participants who were able to deliver this special thanks to the veterans who serve our country.
“We hear a lot of talk about Agile in the media. We want to hear from you:
-Is Agile hype or helpful?
-Do you love Agile or hate it?
-Or is your team proceeding with business as usual?”
The survey is split into the following nine sections:
2. Organizational background
3. Software methodologies
4. Use of Agile (if applicable)
5. Use of Sprints (if applicable)
6. Use of Scrum (if applicable)
7. Platforms, tools, and organizational roles
9. Impressions of the Agile Manifesto
The survey will run through November 30 and will take about 15 minutes to complete. After taking it, you’ll have the opportunity to receive a free copy of the published report.
Founder of voke, inc Theresa Lanowitz has provided insights to SSQ on a variety of topics. Check out this Webcast about APM tools titled, Application Performance: The Intersection of Business and Technology.
Though software test experts do agree on a lot, the question of how to measure software quality is a subject of great debate. In his opening keynote at STPCon 2011, Rex Black, former president of the ISQTB, talked about the importance of deriving metrics from defects, encouraging the audience to track defects throughout the development lifecycle. Meanwhile, James Whittaker, another industry expert, told testers in his STARWEST keynote to stop wasting time with bug reports (especially logging bugs that will never be fixed), and instead focus on the “only artifact that matters: the code.”
We explore more about how software quality is measured with a three-part interview with co-authors Capers Jones and Olivier Bonsignour, who have come out with a new book, The Economics of Software Quality. The book includes a list of 121 software quality attributes which are ranked according to how valuable or detrimental they are to software quality.
It appears Jones and Bonsignour would side with Black as they have “use of formal defect tracking” ranked as 10.00, indicating the highest degree of value for quality. This surprised me since I know many respected leaders, incuding Whittaker, who I’m guessing would disagree. I asked why formal defect tracking was so important to quality. Check out the Q&A to find out how they answered.
The days of being able to get a job as a “manual tester” are no more. According to a panel of QA recruiters at a recent Denver SQuAD meeting, employers are looking for testers who have highly technical skills and specialize in a particular discipline such as security, performance or automation implementation. The panel, which included Bev Berry of Modis, Elias Cobb of Gunther Douglas and Samantha Schreiner of ProtoTest, unanimously agreed that the role of the tester is changing and that employers are expecting candidates who have at least some scripting experience or experience with some of the more popular automation tools, now including the open source tool, Selenium.
The advent of Agile development, of course, plays a part in creating the demand for more technical skills as testers are expected to work side-by-side with the development team, and those testers need to be able to understand code.
This message seemed to confirm much of what James Whittaker had to say at his somewhat controversial keynote at StarWest, “All That Testing is Getting in the Way of Quality.” Eric Jacobson did a great job of summarizing the keynote in his blog, and notes a common theme: “Programmers are getting better at testing, and testers are not getting better at programming.”
Jacobson’s blog also points out suggestions from Whittaker on tester survival that confirm what the recruiters were saying: “Get a specialty and become an expert in some niche of testing (e.g., Security, Internationalization, Accessibility, Privacy), or learn how to code.”
Scott Barber weighed in on the discussion with his own blog post, in which he said: “The state of the testing practice is not evolving nearly as quickly as development, business or products containing or depending on software.”
Should testers be concerned? Certainly Whittaker thinks so. He said to his audience of testers, “You are under threat more than you’ve ever been under threat before.” His keynote underscored the idea that testers must stop justifying the need for traditional testing and get busy learning how to contribute to the code, which he said was “the only artifact that anyone cares about.”
Barber answers the question of whether a tester should be concerned this way: “Only if they are afraid of change, have stagnated in their own professional development, and/or believe what they are doing today ‘is right and will continue to be right’ for at least as long as they will be testers.”
The recruiters, too, advise the testers to be prepared to grow and change. Taking an active part in professional development will make a difference. With all the open source tools available, all testers have the opportunity to learn new technologies, and doing so shows an interest and aptitude.
What if you don’t have the interest or aptitude? The recruiters say that there are growing needs for business analysts (or Product Owners for those who practice Scrum). Technical writing is also a possible career path for testers who are not interested in coding.
But let’s face it. Whether you are a programmer, a tester, a business analyst or a technical writer, if you work with software, things change, and they change at a fast pace. Don’t fight it. Embrace it. Be part of it.
Related articles on SSQ:
Is automated testing replacing the software tester?
Are coding or testing skills more important in the corporate world?
Software development: Benefits of pairing programmers with non-programmers
Recently Gorilla Logic announced the release of their newest automated testing tool, FoneMonkey for Android. I spoke with Stu Stern, Gorilla Logic CEO, about this new tool, and he explained the FoneMonkey tool suite in general, which is available free and open source. Now Android developers and testers will have access to the same automated testing features that iOS developers have already been using, which includes record and playback functional testing.
One of the features that differentiates FoneMonkey testing tools from others according to Stu is the high-level action recording. He described how this works, saying:
We record an actual action. So rather than saying, ‘Oh you dragged your finger on the screen,’ we are recording ‘oh, you scrolled the table to row 3.’ Obviously, that is much more readable; you can create a command from scratch for that recording to try to specify a slight command manually… This high-level action recording, because we are native, and we live so-to-speak right inside the application that is being tested, we’re able to interpret a slight gesture and understand that you are scrolling a table.
With this testing tool, developers and QA testers can create tests that perform user operation sequences and confirm the results. It is also compatible with continuous integration environments.
For other recent SSQ articles related to mobile application testing, see:
You know how when you go on a cruise you feel stuffed from all that delicious food that’s served around the clock? Well, that’s sort of how my brain feels at the end of a conference: happy and full!
I’ve been able to meet with so many test leaders here at STPCon and listen to some interesting presentations. As usual, I’ve been running around with my little camera, shooting videos of speakers. This time I wasn’t the only one with a camera. Stanton Champion of uTest was at the event, too, and I must admit, I think his videos outnumber mine. In fact, he even shot a video of me! It was kind of fun being on the other side of the camera!
Check out this short video clip to see Stanton’s view of the conference:
[kml_flashembed movie="http://www.youtube.com/v/oOLj33hDBXg" width="425" height="350" wmode="transparent" /]
And for more, take a look at our STPCon page for conference videos, exclusive interviews, and these tips from well-known experts Peter Walen, Matt Heusser, Scott Barber and Catherine Powell.
Catherine Powell of Abakus is another SSQ contributor who I had the pleasure of meeting in person here at STPCon in Dallas. Catherine led an Open Jam session, an interactive learning event in which we played games and learned about the different personality types a tester might have. Catherine explains more about the personality types in Software test professionals: Five tester personality types and about the Open Jam session in the following short video clip:
[kml_flashembed movie="http://www.youtube.com/v/bmuE2Q9pTQU" width="425" height="350" wmode="transparent" /]
We hear a lot about teams transitioning to Agile, but what does this mean for the tester? Robert Walsh of Excalibur Solutions presented, “Adapting Conventional Testing Strategies for an Agile Environment” this morning at STPCon.
[kml_flashembed movie="http://www.youtube.com/v/ugh6m5fAOjg" width="425" height="350" wmode="transparent" /]
Rob started with a list of myths or misconceptions:
- Agile doesn’t test.
- Agile doesn’t need testers.
- There’s no place in Agile for manual testing.
- Agile doesn’t write documentation.
- Agile doesn’t plan.
- Agile has a public release at the end of each iteration.
Agile methodologies do encourage planning, documentation and testing; however, unlike traditional methodologies, with Agile we want to do enough but not so much that we will have to do it again.
If we are going to write that documentation, let’s do it once, and make it valuable, so we don’t need to do it again. Agile believes in ‘just enough’ but no more. If we don’t see a need for it, don’t do it.
Traditional methodologies are notorious for requiring detailed documents throughout the lifecycle. Most of us know the pain of writing these documents and wondering if they’re ever even read. Walsh said that he heard of someone who stuck a brownie recipe in the middle of a document just to check if anyone was actually reading it. He was met with understanding nods from the audience.
Though there were many other examples that Walsh gave of working in a more Agile way, the anecdote that I enjoyed most was one that I’ve often used as well.
Walsh told the story of the family that cut the end off of roast for generations without really knowing why. It’s just that it was the way it had always been done. Upon investigation, it was learned that the practice started because Great Grandma’s roast pan was too small to fit a full roast.
“Once upon a time there was a reason. If it’s not valuable, don’t do it.”
We need to use our critical thinking skills and question why we are doing what we do. Is there a better way? We should never do things simply because it’s the way it’s always been done. And, in fact, Agile tells us to always be looking for ways to do things better.
Crowdsource test organization uTest has partnered with Mozilla to create a new test management system, CaseConductor™ . This system will allow testers to collaborate on test case creation, management and execution, regardless of where they are physically located.
CaseConductor beta is now available for download in a github.com repository, where developers and QA managers are encouraged to start leveraging the tool, view the source code, provide feedback on usability and ultimately help advance the development of this TCM system.
I caught up with Chief Marketing Officer Matt Johnston, who delivered the lunchtime keynote at this year’s STPCon, “In-the-wild testing: Your survival may depend on it.” He has this to say about the annoucement:
[kml_flashembed movie="http://www.youtube.com/v/LRaAPHPjDWc" width="425" height="350" wmode="transparent" /]
But that’s not all. Another announcement made here at STPCon was the expanded partnership with SOASTA to include uTest’s “JumpStart” service for the SOASTA CloudTest Platform. Now customers using SOASTA CloudTest Lite can conduct both performance and automated functional testing using uTests crowdsourced service.
When Karen Johnson told a barista that she was working on a data warehouse, the barista said, “Oh, where is it located?”
While most of us that work with software realize that a data warehouse is sort of a mega-database, not a physical building, we still might feel a little lost when tasked with testing data on a data warehouse project.
“A BI [Business Intelligence] project is like a foreign language. You can’t really see it. If you’re in management and you’re trying to staff for it, you’re not sure how to hire for it,” said Johnson, talking about the difficulty of trying to explain the skills needed for testing data on BI/DW systems.
I attended Johnson’s presentation this morning at STPCon titled, “Data Testing on Business Intelligence and Data Warehouse Projects.” She gives a quick overview in the short clip below.
[kml_flashembed movie="http://www.youtube.com/v/5QZYWwQ-yq4" width="425" height="350" wmode="transparent" /]
Johnson described a lot of the basics, including the term ETL: Extract, Transform, Load. She explained that this really was all about sucking data out of systems, transforming it to a common format, and then loading it into a database which will allow for some sophisticated analytics. One simple example she gave was with date formats. If you are working with multiple systems that are using different date formats, you would first extract the appropriate data, use an algorithm to transform the data into a consistent format, and then load it into a table in that common format so that reporting could be done.
So what should a tester look for when testing data? Here are some bug opportunities:
- data type mismatches
- boundary conditions
- data accuracy
- is the data current
- data refreshes
- data security
What about when you’re working in an Agile environment? Check out the interview I had with Ken Collier about his book, Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing.