But as the story unfolds, there are a few details that may come as surprise. Here is a list of Heartbleed’s most recent developments.
1. One arrest has been made.
Canadian police arrested 19-year-old Solis-Reyes in London, Ontario last week. He is accused of exploiting the Heartbleed Bug vulnerability to steal social security numbers from servers of Canada’s tax collection agency and is charged with one count of mischief in relation to the data.
The accusation comes two days after the Canada Revenue Agency announced that the sensitive information of 900 Canadians had been compromised. But law enforcement has not made any direct connection.
The teenager’s lawyer tells a story of when Solis was only 14 and proved that his high school’s computer system was vulnerable to hacking when administration didn’t believe him. It’s very possible that when the Heartbleed Bug news hit mainstream media, he became curious and tested it out for himself. On Tuesday, the Solis-Reyes turned himself in.
2. The company responsible for the OpenSSL software has just 1 full-time employee.
The breach was the result of a flaw in OpenSSL, a platform designed to provide users with a free set of encryption tools that prevent hackers from obtaining user data.
The irony is that although two-thirds of all websites use this software, the foundation’s revenue stream is so insignificant that it can’t afford a full security audit or to pay a full staff. Therefore, the foundation is comprised of 1 full time employee and 10 volunteers.
Steve Marquess, founder of OpenSSL Software Foundation, released an open statement explaining:
“These guys don’t work on OpenSSL for money. They don’t do it for fame (who outside of geek circles ever heard of them or OpenSSL until “heartbleed” hit the news?). They do it out of pride in craftsmanship and the responsibility for something they believe in.”
3. One small error in one line of code can lead to something like Heartbleed.
German developer Robin Seggelmann believes he accidentally made the coding error that was overlooked by a reviewer, and made it’s way to the released version of OpenSSL two years ago. He was submitting bug fixes at the time when he made the mistake.
Being an “open source” platform– free, attainable, and open to everyone– hypothetically anyone could have spotted a vulnerability like Heartbleed. But few users participate in this way, leaving a small group of people essentially in charge of hundreds of thousands of lines of complex code, used by banks, governments, and social media sites everywhere.
4. OpenSSL had the flaw, but underfunding is to blame.
The company’s revenue stream relies heavily on donations, which amount to about $2,000 a year. They also sell annual commercial software support contracts worth $20,000 a year. Most volunteers make their money from “work-for-hire” consulting.
How does it make sense that such a widely used resource is so short-staffed and underfunded? In his statement, Marques makes it clear that he believes OpenSSL is ignored and should be paid for by the Fortune 1000 companies and governments that use it extensively.
“I stand in awe of their talent and dedication, that of Stephen Henson in particular. It takes nerves of steel to work for many years on hundreds of thousands of lines of very complex code, with every line of code you touch visible to the world, knowing that code is used by banks, firewalls, weapons systems, web sites, smart phones, industry, government, everywhere. Knowing that you’ll be ignored and unappreciated until something goes wrong.”
5. High priority websites have been fixed, but there is still affected websites.
New SSL certificates have been issued to affected websites, clearing them of the vulnerability. Also, Apple issued a statement that Apple’s desktop and mobile operating systems were never affected. But it is reported that there are still nearly 500,000 or more vulnerable SSL certificates.
Ed Felton, a computer scientist at Princeton University makes a valid analogy: “Open SSL is like Public infrastructure without a tax base”. Do you feel corporations and government should help to fund Open SSL and not be “free riders”? Let us know what you think in the comment section below.
Brendan Mulligan, co-founder and designer of the community photo sharing app Cluster, recently posted a series of articles on TechCrunch, detailing the importance of live user testing and how a comprehensive plan could be built and executed. The recipe breaks down something like this:
1) Define the parameters of the project:
- What are you testing? (e.g. iOS app, Android app, desktop app)
- Why are you testing? (e.g. functionality, usability, security, localization, load)
- How are you going to test? (define scope, hardware and OS requirements, maybe write a test case)
- Who is going to test? (define desired tester characteristics)
- When are you going to test?
- Where are you going to test?
2) Pre-test admin:
- Recruit, select and finalize test team and testing schedules
- Acquire the needed testing equipment, devices and additional required resources
- Prepare testing spaces, if applicable
- Onboard testers, explain scope and requirements, explain bug reporting and feedback processes
- Run live user tests
- Collect and organize bug reports, user feedback and any related materials like screenshots user videos
- Administrate tester compensation and debriefing if applicable
4) Post test analysis and action:
- Assemble bug reports, user feedback and related materials into consumable, sharable and hopefully quantifiable formats
- Distribute data and information to dev team members
- Collaborate with team members to identify and prioritize actionable items
- Develop the next iteration of the product
- Plan to run that next iteration through another live user testing plan
Rinse and repeat throughout the life of the product.
With small scale live user testing needs, DIY might be indeed be a viable path for many digital experience developers. But with modern-day digital globalization there’s really no such thing as ‘small scale’ anymore – especially when you start factoring in mobile fragmentation and localization demands. This is why we do what we do. After all, your end goal isn’t testing for testing’s sake, it’s to deliver amazing digital experiences – whether it’s desktop, mobile, wearable, web or native app – that captivate, engage, and keep customers.
Off hand, if you’re curious about what your own DIY costs might look like, we’ve got a handy calculator that can do just that.
Last week the Software Test Professional Conference traveled down to New Orleans. Bookended by the French Quarter Festival and the Jazz Festival, I think we all know who brought the real party to NOLA. The four day conference was jam packed with information on test strategy, performance testing, automation testing, mobile testing and leadership perspectives for testers. In addition to standard sessions the folks at STP also debuted a few new session formats, including roundtable discussions and keynote debates.
Tuesday, the first full day of the conference, kicked off with a debate between Rex Black and Cem Kaner. The topic up for debate was, do schools of testing help advance the field of software testing or do they have a negative impact on the industry? It was an interesting conversation and while they disagreed on a lot, ultimately both parties agreed that schools of testing are not inherently negative – as long as discourse remains civil and folks keep an open mind.
The first session I attended was delivered by Pradeep Govindasamy and focused on Mobile Application Testing – Through the Customer’s Eyes. In his session, Pradeep states that prevailing trends point to a steep upward curve in both volume and expenditures on mobile application projects. To that end, organizations must ensure they understand the risks associated with multiple platform and OS usage, and have the proper processes in place in order to stay ahead of this curve.
Unfortunately I was not able to attend any additional sessions on Tuesday, however I did have the pleasure of speaking with many of the conference attendees at the two Sponsor Showcases held that afternoon and evening. We even gave away an iPad Mini to one very lucky fellow – this gentleman won not one but two iPad Minis in the span of mere minutes!
On Wednesday I began my day by being forced selected to participate in a little improv comedy. Nothing gets the blood flowing quite like a game of ‘Moving People’. After being embarrassed motivated I found my way to a session on Interviewing Testers by Rex Black. As Rex points out, a problem employee can consume as much as 50% of their manager’s time, so hiring the right people is critical. In his talk, Rex discusses strategies that will allow managers to overcome hiring challenges and ensure that they and their teams are set up for long term success.
After that, I attended a Round Table discussion on mobile testing. It was interesting to hear that despite the shift toward mobile applications and platforms, in many organizations the infrastructure to support mobile testing is still in its infancy. It’s clear that many organizations still have a lot to learn when it comes to mobile testing which really drives home the importance of knowledge-sharing events like STP.
After the round table, I sat in on my second live podcast with the guys from PerfBytes. If you haven’t had the pleasure of meeting either Mark Tomlinson or James Pulley, you should really check out their pod cast because they’re very knowledgeable (and hilarious).
Once again, the folks at STP put on wonderful event; bringing people together from diverse backgrounds to learn, network and walk away with leadership strategies that will empower them to become software testing champions within their organization.
Endurance, speed, support and training. Not only are these traits a necessity for testing in Scrum sprint (more on this in a second), they are also the traits needed to finish a real marathon in one piece. No one knows each of these points better than Doron Reuveni, uTest’s CEO and Co-Founder.
Today – for the sixth time in as many years – Doron will be running in the Boston Marathon. After steady improvements each year, we fully expect him to win this year’s race. Anything less will be a major disappointment – no pressure! If you’re interested in keeping track of his progress, you can follow his Twitter handle (yes, he tweets mid-race) or search the official Boston Marathon website. Best of luck Doron!
Of course, running 26.2 miles isn’t easy – and as mentioned earlier – neither is testing in a Scrum sprint. So to stick with the running motif, I wanted to share a few scrum testing tips courtesy of testing expert Clemens Reijnen. Titled 5 Tips for Getting Software Testing Done in the Scrum Sprint, this article explains how to avoid some of the pitfalls and confusion that can often occur with what’s come to be known as “agile testing.” Let’s take a closer look at three points in particular (followed by our own take):
Tip #1: Get a Team
This is actually not a tip, it is a must. This is a kind of obvious but not common and the hardest thing to accomplish. Get a team, get testing knowledge in your team. When you don’t have it, you will fail. Teams and companies have failed to reach their agile software development goals only because it was impossible to get different disciplines together in a team.
The three most important concerns (of establishing a team) are:
- A topic closely associated with trust when it refers to people is Identity.
- Collaborative culture.
- A collaborative culture consists of many things, including:
- Collaborative leadership;
- Shared goals;
- Shared model of the truth; and
- Rules or norms.
- A “reward” for successful collaboration is most often of a non-financial nature.
Our Take: Cohesion is absolutely critical to the agile methodology. If testers, developers and product owners are not on the same page, the project is doomed to failure. As Clemens notes in the article, it’s not always easy for testers and developers to get along, as they tend to see the world through much different lenses. But in our experience, this difference is vastly overstated. In any event, make sure that collaboration is a central pillar of your plan. The points noted above will get you started in the right direction.
Tip #2: Use a risk and business driven test approach.
When there is no risk, there is no reason to test. So, when there isn’t any business risk, there aren’t any tests and is it easy to fit testing in a sprint. More realistically, a good risk analysis on your product backlog items before starting to write thousands of test cases is a healthy practice. Risk is also an important attribute in Scrum.
The release plan establishes the goal of the release, the highest priority Product Backlog, the major risks, and the overall features and functionality that the release will contain.
Our Take: Absolutely true. Without a risk-based approach, your QA efforts will be aimless, costly and a likely a waste of time.
Tip #3: Regression Test Sets
Collecting a good regression set is important. There are a lot of approaches how to get this regressions set, most of them are based on risk classifications and business value (see the previous tip).
The principle is that from each test case a collection of additional data is determined into the test cases for the regression test are ‘classified’. Using these classifications all cross-sections along the subsets of test cases can form the total tests that are selected.
Automation of this regression set is almost a must. Making a good selection which test cases to select is a trivial task. With excel you can do some querying for proper test cases but this gets harder when they are in different documents. Testing is more efficient if you have good query tools so you can easily make a selection (and change this selection) of the test cases are part of the regression run.
Our Take: When you’re introducing a new element to your site, or software or app it’s extremely important to make sure it doesn’t break any existing components – especially security related aspects. While manual testing should play a role, automating such tests is usually the most efficient course of action.
What tips do you have for running a marathon (or testing in a scrum sprint)? Be sure to share your ideas in the comments section below.
You’ve tested every aspect of your mobile app – functionality, usability, security, performance and other types. You’ve tested it with simulators and in the wild. You think you’ve covered almost every angle and that it’s essentially bulletproof, but you forgot the biggest cause of app failure: People.
Yeah, those guys. According to PC World, nearly 80 percent of the vulnerabilities discovered in mobile apps are not the fault of the application code itself, but rather the result of human error.
According to the HP 2013 Cyber Risk Report, though, the application itself is not to blame for most vulnerabilities—you are. HP compiled data from 2,200 applications scanned by HP Fortify on Demand and reports that 80 percent of the vulnerabilities discovered were not the fault of the application code itself.
“Many vulnerabilities were related to server misconfiguration, improper file settings, sample content, outdated software versions, and other items related to insecure deployment,” the report states.
In other words, it’s not your fault! That said, there are some things you can do as testers and developers to minimize the risk of human error. Let’s take a closer look at some the causes mentioned in the article:
Both the iOS and Android platforms give developers the ability to encrypt data that’s stored within the mobile app. The problems is, many developers neglect to include this feature and many testers fail to account for it as well. These days, apps that do NOT store some type of personal data are the exception, so if you want to save users from themselves, it’s best to consider encryption as the default option.
Outdated Software Versions
The latest version of your app probably includes a number of security updates, as well as some new features. But guess what? Most users are slow to update their software and apps, which means that in the meantime, they are susceptible to all of the weaknesses in your previous versions. Thus, when you update your app, make it count – and make users aware of the consequences of not updating.
Passwords and Permissions
If your mobile app provides unnecessary default settings – such as a password or username – then your mobile app could be at risk for a security breach. When this functionality exists, it’s possible for a hacker to bypass the log-in process and access both the personal, sensitive information of other users. Of course, many apps do require this feature (and many users will have weak passwords) but if it’s an unnecessary aspect of your app, perhaps you should consider ditching it.
No matter how much preparation your company may devote to development and testing, your users will find a way to ruin it (and possibly damage your reputation in the process). While you cannot account for every instance of human error, it’s your job as software quality professionals to be aware of the many ways in which a user can injure themselves. The items mentioned above are just a start.
What are some other ways that human error leads to app quality issues? Be sure to let us know in the comments section below.
Testers, especially those within the uTest Community, are at the forefront of mobile technology. From iPhones, to Android tablets, to even the latest smartwatches and fitness devices, uTesters often are armed with 5, 10, even 20 devices at a time for various testing projects.
So one would think that if anyone on the planet was going to own a ghastly piece of 1990s technology like a landline phone, it wouldn’t be testers.
But you’d be wrong.
According to a recent poll kicked off in the uTest Community, in fact, 64% of uTesters have landline phones still in their homes, and it’s not just for nostalgia.
According to a couple of testers, there are still practical uses of the landline phone:
I like having an alternate number to give to folks who don’t really need to have my cell phone number, to interrupt every minute of my day just to find out if I was “very” satisfied with their customer service… and enjoy screening those calls appropriately! – Brian S.
I do, but I find myself more and more looking at getting a VoIP solution, as my landline keeps getting more expensive for basic service. I have a cell and do most calls that way, but for the wife and kids, they use the landline. – Tim F.
Given the diverse tester base making up the Community, some of it just boils down to the popularity of landlines in certain countries:
I have one. They still are pretty common in my country, but I mostly use it for Internet, since the only broadband in my area is a DSL service. – Caio B.
It’s still pretty much common in Argentina to have a landline phone. Mostly all families and companies have a landline phone. – Anahi G.
So based on all of this, is the landline phone (dare I say, rotary dial?) making a big comeback like vinyl music sales? Not quite. It’s fair to point out that some of the testers with landline phones begrudgingly own them (including this guy right here) because they’re part of a cable package that includes phone, Internet and TV at reduced rates. Additionally, amongst those in the uTest Community that cut the landline cord, many of them did it upwards of 10 years ago.
Nonetheless, the 64% of testers surveyed that still own landline phones was a surprising number highlighting a bygone area, one that is increasingly becoming irrelevant in a mobile world. I wouldn’t suspect the one-trick-pony in landline phones to be quite as popular in the 2015 or 2016 version of this poll.
Tester Community outside of uTest: Do you still own a landline phone? Do you actively use it? We’d love to hear from you in the comments below.
Just when you thought the mobile app world couldn’t get any more crowded and competitive, along comes Marvel.
The UK startup has come up with a new iPhone app that can turn the average person into a web or mobile-app designer, regardless of design and technical skill. With no coding required, users can easily turn their concept into an interactive prototype, and share it with friends, clients, coworkers, or through social media.
To the seasoned app designer, this might seem like amateur hour. But here are 4 reasons why this has the potential to gain momentum and completely alter the software design (and therefore testing) world.
1. It’s extremely easy.
Draw your screen ideas on a piece of paper, take pictures of the wireframes and use the Marvel app to apply “touch” hotspots to the image. Apply links to screens in order indicate how you would like to app to be navigated and boom – you have a touchable, interactive prototype.
“In the past, if you wanted to see your app or web designs and ideas in anything more engaging than PDFs and PowerPoints, you needed to have the skills and the time to code it into an interactive prototype,” explains Marvel co-founder Murat Mutlu. Now, all you need is this app on your smartphone.
2. It turns the average person into a designer, and reaches a wide audience.
Remember when Instagram turned the average person into a photographer? Users could process high quality photos without needing an expensive camera or experience. People who had never edited a picture before were suddenly part of the craze.
Similarly, Marvel hopes to inspire individuals to “pick up and play” with the app and attract non-designers to give it a try.
Co-founder of Instagram, Kevin Systrom, attributes the success of Instagram to its ability to appeal to a wide audience of individuals and companies alike.
“Instagram is not a market for selling [photography] but I’ve seen an amazing amount of people using their account to promote their business. That’s been inspiring to me.”
Marvel also offers just that. It allows companies to design, review, and test prototypes without writing a single line of code, saving time and money.
3. Shareable and useful for feedback.
Connect to DropBox and start your first project. Once you’re finished, share it using a URL with your clients, teams, or even friends through email, Facebook, Twitter, or text. Since the prototype can be navigated as if it is an actual app, it is great for user feedback.
Marvel currently offers a free service but plans on offering a Premium model that offers other service integrations like team collaboration.
4. Maintain your originality.
Get a leg up on a new wave of mobile app designers with your Photoshop skills. Rather that offering cookie-cutter models that could potentially make every web and mobile app look the same, open your screen images up in Photoshop, make design changes, and share the PSD file to DropBox.
Marvel is not the only company which offers this type of prototyping service. Apps like InVision, which are also supported by DropBox, also have significant funding and headway as well. So although it’s hard to say what company will come out on top, it’s safe to say that app design world is about to become more dynamic and competitive, and the software testing world will have a lot more work to do.
As a tester, what do you think about the “average” person suddenly becoming a mobile app designer? Be sure to share your thoughts in the comments section below.
Perhaps lost amidst the release of the new Fire TV, Amazon also announced that its app store has surpassed the 200,000 apps mark. The Amazon AppStore has shown significant growth since its inception just over 3 years ago. In fact, just last August the app store reached 100,000 apps; meaning that it has doubled in size in less than a year. Of course, this still pales in comparison to the Google Play and Apple App Store which both have over 1 million apps. However, Amazon is clearly becoming a larger player in the app market that developers must pay attention to.
While Amazon is certainly pleased with the overall number of apps available in the store, the company is also making a push to improve quality as well. Amazon’s AppStore Developer Select offers developers incentives for optimizing their applications specifically for Amazon devices. The benefits include preferred placement within the app store and 500,000 ad impressions. To qualify, developers must make sure their app runs in HD, taking up the entire screen, and use Amazon’s own API.
This program serves as a great reminder for developers that they must optimize their apps across a wide spectrum of devices. For Amazon specific apps, this means taking into account Amazon’s own Fire OS, several generations of Kindle tablets from the new Fire HDX to older devices, and different screen sizes including 7 and 8.9 inch models. Add this on top of Apple and other Android devices and you are looking at a diverse range of devices that need to be taken into consideration when testing.
Heartbleed is a flaw in OpenSSL. Occasionally, one computer may want to check on another computer to ensure that there is a secure connection on the other. In order to do so, it will send out a small packet of data that will ask for a response – like a heartbeat.
However, researchers discovered that it was possible to send a well-disguised packet of data that looked like one of these heartbeats to trick the computer at the other end into sending data stored in its memory. To make matters worse, it has recently been realized that the code in SSL has been opened for the past two years and doesn’t leave much of a trace.
This raises several important questions, not only for testers and developers, but also for the average web user. Let’s take a look at a few in particular:
1. Are You Affected?
Probably. Since hundreds of thousands of sites were affected, chances are that you have used at least of them on a fairly regular basis. While there is no way to tell with 100% certainty, many experts are urging people to take the necessary precautions, which leads us to our next key question…
2. How Can You Protect Yourself?
According to Business Insider, the best way to tackle this problem is to assume that the worst has already happened. Most major service providers are already updating their sites and taking proactive security measures, but you should also go through and change your passwords as well and assume that your accounts have already been compromised (as awful as that sounds).
CNET advises that you should check your financial statements over these next few days in order to ensure that your privacy is still intact and that your financial accounts have not been compromised. A hacker that has accessed a bank server, for instance, has likely snagged information regarding recent credit card activity.
3. What Passwords Should I Change?
Mashable has recently launched a list of the sites that you should strongly consider changing your passwords on, including:
- Google & Gmail
- Yahoo & Yahoo Mail
- Amazon Web Services
- Intuit (TurboTax)
4. What Websites Are Affected?
The most popular sites affected by the Heartbleed bug, according to Digital Trends anyway, were:
5. What Is Being Done About This Security Breach?
Thankfully, the Heartbleed bug itself is quite easy to fix. Sites are currently updating their software and security certificates in order to ensure that the bug will no longer harm its users and potentially breach the data that consumers have entrusted with them.
As testers and app quality enthusiasts, we’re interested to get your thoughts on why this bug existed for such a long period of time before being discovered. Have an answer? Be sure to share it in the comments below!
Yet, each programming language has made some type of contribution to the software development world. Most of the posts you read about programming languages are rants, or compare and contrast them.
However, Dustin Marx of Java World recently took a different approach. Marx looked at each programming language individually and how it influenced software development. Here’s a look:
Most software developers I know have written some code in some form of BASIC(Beginner’s All Purpose Symbolic Instruction Code). I remember, long before public availability of the Internet or even mice on PCs, typing in Basic code from magazines I received in the mail with code listings for various simple games and PC utilities. Like many developers, Basic was the language that attracted my interest at a relatively young age to programming. It was from my Basic programming that I learned firsthand the dangers of the goto.
C may be the most influential of all programming languages on today’s software development. In Steve Yegge‘s well-known blog post The Next Big Language, Yegge’s #1 rule for the next big programming language is that it has “C-like syntax.” Many people’s favorite programming languages are themselves (interpreter or runtime environment) written in C and many of these languages provide mechanisms (JNI and XS are two examples) for “escaping” to C for performance gains. C also remains one of the most popular and highly used programming languages in the world despite its relatively old age. Wikipedia even has an entry devoted to C-based programming languages.
Although COBOL is not a language you read much about in blogs or articles these days, there is a huge amount of deployed code written in COBOL (Common Business-Oriented Language). In Cobol doesn’t belong in a museum, Ken Powell writes:
I believe that the spirit of Smithsonian’s Cobol debut is not an indication of its antiquity, but rather a testament to its past, as well as its continued success. Just as Edison’s light bulb was a game-changing invention in its day, Cobol has changed the face of computing, and continues to have a tremendous impact on our everyday lives.
John Breeden II also writes of Cobol’s impact on software development in A toast to Cobol, a true computing hero, stating, “Without Cobol, each early computer might have developed its own proprietary computing language. Instead, we started on a path to interoperability that would come in very handy later on.”
C#‘s status as flagship language of Microsoft’s .NET has made it influential out of the box. C#’s syntax and early features also paid homage to and provided evidence of the influence of C, C++, and Java. Although C# borrowed heavily from those languages in its early versions, it also brought its own advancements that were emulated by other languages (in particular by Java). It was Microsoft’s plan for migrating legacy Visual Basic applications to the .NET framework (and making use of C# libraries) that demonstrated on a large scale the advantages that the JVM already offered but were rarely used. The multiple language paradigm on the JVM has become huge in recent years, but Microsoft’s use of the CLR seemed to be the first to bring this idea to mainstream awareness even though the JVM existed before the CLR.
C++ was the object-oriented language for a while, is still heavily used, and has inspired other highly popular object-oriented languages such as C# and Java. C++ has dominated the “system programming” market and changed how many of us think about programming from completely procedural to object-oriented thinking. C++’s direct influence as a popular language in its own right and indirect influence via “child” languages that have reached their own popularity heights are proof of this language’s dramatic influence on software development.
The IBM article Fortran: The Pioneering Programming Language states that Fortran(FORMula TRANslator) “became the first computer language standard, ‘helped open the door to modern computing,’ and may well be the most influential software product in history.” This is an interesting read that I highly recommend for learning more about Fortran’s impact and influence on software development. Fortran has also been called ”the first successful high level programming language.”
Along with Lisp, one of the first programming languages many of us think of when discussing functional programming is Haskell. As languages such as Scala, Clojure, and even Java 8 bring functional programming concepts to the JVM, it’s not difficult to see the roots of these features in languages such as Haskell and Lisp. The Why Haskell matters Wiki page states, “Haskell is a modern general purpose language developed to incorporate the collective wisdom of the functional programming community into one elegant, powerful and general language.” There’s even a free online book called Learn You a Haskell for Great Good!
David Chisnall calls Lisp “arguably the most influential programming language of all time” in his post Influential Programming Languages, Part 4: Lisp. Reasons he cites to justify this claim include Lisp being “the very first programming language to provide automatic garbage collection,” Lisp’s introducing “the idea of the read-evaluate-print loop (REPL),” Lisp’s early use of closures/lambdas, and Lisp’s “inspiration for pure functional languages” and “inspiration for a number of object-oriented languages.” In Why Lisp?, Peter Seibel states, “So, on one hand, Lisp is one of computer science’s “classical” languages, based on ideas that have stood the test of time. On the other, it’s a thoroughly modern, general-purpose language whose design reflects a deeply pragmatic approach to solving real problems as efficiently and robustly as possible.”
Like Basic, Pascal is influential on software development because of its wide use as a “learning language.” Aspects of Pascal are also seen in other languages. For example, the Oracle database procedural programming language PL/SQL has always felt eerily similar to Pascal. One might argue that Pascal’s influence is felt more today indirectly via languages such as PL/SQL than via direct use. On a personal note, Pascal is the first language that I used in more than hobbyist fashion (that was Basic’s role for me) as I had high school and college courses that used Pascal and I wrote my first “commercial” application (a sports trading card inventory control system) in Pascal. I still think Pascal offers numerous advantages as a “learning language.”
Perl has been a significant contributor in a wide variety of contexts, especially in early web development (CGI scripts) and in Unix/Linux scripting and development. Perl was often the first taste of a dynamic language for C-style language developers. It also helped many developers to realize the advantage of writing scripts in a language that could be used in all shells rather than using shell-specific scripts. Furthermore, it can be argued that Perl, perhaps more than any other language, has brought the power of regular expressions to the forefront of software development along with some powerful and concise features of sed and awk.
I have no evidence to back this, but it feels to me like Python is the language taking most developers away from using Perl for scripting. There are still countless scripts written in Perl and still be written in Perl, but Python seems to be gaining on the percentage of new scripts being written. There are Python libraries for all types of different domains. For example, in my post Significant Software Development Developments of 2013, I wrote about Python and Big Data. Python seems to appeal to a wide variety of developers in the Java, .NET, C/C++, and other development communities where Python is not the predominant language.
Ruby / Ruby on Rails
Although Ruby on Rails is a framework rather than a language, it is Ruby on Rails that seems to have made Ruby famous outside of Japan and so it’s difficult to talk about Ruby’s influence without considering Ruby on Rails’s influence. Ruby has popularized many object-oriented concepts that were available in other languages that never reached Ruby’s level of adoption. Ruby’s treatment of everything as an object (no primitives) and its powerful use of dynamic mechanisms in conjunction with object-oriented principles made combined object-oriented structure with a dynamic language in ways that Perl’s bolted-on object-orientation could not achieve. Ruby on Rails popularized the concept of configuration by exception that is prevalent today, but was lesser known (Maven, Hibernate, and JavaBeans for example) before Ruby on Rails and the specific and catchy nomenclature of “convention over configuration.”
If we were to measure programming languages by the ratio of influence on other languages and frameworks to existing code base written in that language, Smalltalk might have the highest ratio of them all (though ALGOL would give it a run for its money in terms of code still deployed today). For its relatively small deployed code base, Smalltalk has had tremendous influence of frameworks and much more widely used programming languages (including Java and other object-oriented languages). Smalltalk has influenced other languages’ syntax and concepts (such as everything is an object) and has had obvious influence of today’s IDEs.
I won’t talk much about Visual Basic here because I’ve already touched on it at least tangentially in the Basic and C# coverage, but it has been one of the world’s most popular programming languages at one time and influenced many developers who got their hobbyist and professional starts with that language. It has also influenced software development through early IDE innovations that provided a glimpse of what Java and other programming language IDEs could (and would) become.
Researchers reported that an estimated 66% of the world’s servers have been affected by a real world crypto bug that could expose all types of sensitive data. This hits everything from online retailers, to banks who offer online banking – you name it.
According to Dan Goodin of ARS Technica, the defect is in the cryptographic software library an estimated two-thirds of Web servers use to identify themselves to end users and prevent the eavesdropping of passwords, banking credentials, and other data:
The warning about the bug in OpenSSL coincided with the release of version 1.0.1g of the open-source program, which is the default cryptographic library used in the Apache and nginx Web server applications, as well as a wide variety of operating systems and e-mail and instant-messaging clients. The bug, which has resided in production versions of OpenSSL for more than two years, could make it possible for people to recover the private encryption key at the heart of the digital certificates used to authenticate Internet servers and to encrypt data traveling between them and end users. Attacks leave no traces in server logs, so there’s no way of knowing if the bug has been actively exploited. Still, the risk is extraordinary, given the ability to disclose keys, passwords, and other credentials that could be used in future compromises.
‘Bugs in single software or library come and go and are fixed by new versions,’ the researchers who discovered the vulnerability wrote in a blog post published Monday. ‘However this bug has left a large amount of private keys and other secrets exposed to the Internet. Considering the long exposure, ease of exploitations and attacks leaving no trace this exposure should be taken seriously.’
The researchers, who work at Google and software security firm Codenomicon, said even after vulnerable websites install the OpenSSL patch, they may still remain vulnerable to attacks. The risk stems from the possibility that attackers already exploited the vulnerability to recover the private key of the digital certificate, passwords used to administer the sites, or authentication cookies and similar credentials used to validate users to restricted parts of a website. Fully recovering from the two-year-long vulnerability may also require revoking any exposed keys, reissuing new keys, and invalidating all session keys and session cookies. Members of the Tor anonymity project have a brief write-up of the bug here, and a this analysis provides useful technical details.
OpenSSL is by far the Internet’s most popular open-source cryptographic library and TLS implementation. It is the default encryption engine for Apache, nginx, which according to Netcraft runs 66 percent of websites. OpenSSL also ships in a wide variety of operating systems and applications, including the Debian Wheezy, Ubuntu, CENTOS, Fedora, OpenBSD, FreeBSD, and OpenSUSE distributions of Linux. The missing bounds check in the handling of the Transport Layer Security (TLS) heartbeat extension affects OpenSSL 1.0.1 through 1.0.1f.
The bug, which is officially referenced as CVE-2014-0160, makes it possible for attackers to recover up to 64 kilobytes of memory from the server or client computer running a vulnerable OpenSSL version. Nick Sullivan, a systems engineer at CloudFlare, a content delivery network that patched the OpenSSL vulnerability last week, said his company is still evaluating the likelihood that private keys appeared in memory and were recovered by attackers who knew how to exploit the flaw before the disclosure. Based on the results of the assessment, the company may decide to replace its underlying TLS certificate or take other actions, he said.”
This is the type of real world defect that only white-hat security hackers could stumble upon in-the-wild. Share your thoughts on this big security news in the comments section.
Sometimes in software testing you are finding and fixing coding errors, sometimes you are addressing requirement gaps, and sometimes you have to deal with spiders.
Spiders? Exactly. And no, I don’t mean that as a metaphor for some new fancy software issue. I just mean, sometimes you are actually dealing with spiders.
Mazda has recently announced a voluntary recall of 42,000 Mazda 6s, due to… spiders. The yellow sac spider or Cheiracanthium, for those of you that are arachnid enthusiasts, are attracted to hydrocarbons and gasoline. These adorable little guys have taken a liking to Mazda’s vent lines. The webs restrict air flow and can potentially cause cracks in the fuel tank, which ultimately could lead to fires.
Mazda first addressed this “more common than you’d think” problem a few years ago with a mechanical solution, aimed at keeping the spider out of the lines. However, they proved to be persistent and continue to breach the Mazda’s security. So Mazda has now turned to new software. They offer the free upgraded software to Mazda owners which regulates the pressure level and notifies the owner if there is a problem. True, it is not an actual solution to the spider problem; however it is great to see that Mazda is looking to software proactively to ensure the safety of their customers. It should also be noted that although the problem has persisted for a few years, no injuries or fires have been reported as a result of pressure build up related to spider webs.
I did a quick Google search for “Most common software testing problems” and found it strange that “spiders” did not crack this top 20 list. Maybe next year, spiders. I imagine it would have been fairly amusing to see the reaction of Mazda’s software testing team when they were sat down and directed to create a new software upgrade to battle spiders. However, as the world becomes more technical, software is lending itself to a greater number of solutions every day. And clearly some that may not have been considered possible previously.
In response to why Mazda in particular was having such problems with the pesky little spiders, one representative replied “Don’t ask me, I’m terrified of the damn things”. Me too, Mazda representative, me too. But thank you for developing software that proactively prevents them from damaging cars in addition to giving me the heebie-jeebies.
Have you encountered any “less than usual” software testing situations? Be sure to share in the comments!
Ever since the first cell phone hit the commercial market in 1983, the mobile market has rapidly innovated from a handset that weighed over 2 pounds and could only make one phone call at a time, to a modern-day smartphone that weighs barely 5 ounces and can hold enough apps to practically run your entire life. In this course, uTest guest author Anand Ramdeo outlines ten ways that testing mobile apps differs from desktop and web testing, and points out the complexities and nuances that make mobile testing a unique skill for testers.
We have witnessed transition from desktop to web and are witnessing another transition from web to mobile. Before I delve deeper into the subject – it is important to understand how testing mobile applications is different from testing browser / desktop applications. If we understand the distinction and challenges of testing mobile apps, it will be a bit more easier to tackle them.
1. Supported platforms and devices mean you have more combinations to test.
Desktop apps were usually targeted for specific platforms and it was relatively easy to access those platforms. Web based applications made it a bit more challenging by adding another dimension: browsers.
Mobile applications take complexity of supported platforms to the next level by adding devices. Ensuring that mobile apps are working on all type of devices (smartphone, tablets, and phablets) supplied by major brands (various models from Samsung, Sony, Nokia, HTC, Apple, etc.) and on all the platforms (iOS, Android, Windows, BlackBerry, etc.) is challenging. On top of that, new devices are hitting market so often that it becomes impossible to cover all the major devices.
In the mobile world, it is important to create something on the lines of graded browser support used by Yahoo to ensure that major platforms are covered.
2. Adaptability and limited space mean screen size is changing constantly.
Pretty much all the major players are changing screen sizes of their phones, tablets, and phablets to figure out what works or in response to the competition. How applications adapts themselves for various screen sizes, layout, and configuration is a challenging task.
Apart from adaptability to different screen sizes, mobile applications have to deal with the limited screen size. Limited screen size means that user can not be given 30 different options on a single screen – usability, similar experience, on-screen help, inability to use search or other applications easily, etc. – poses different challenges and as a tester we need to think beyond what is developed and always think of who will use it and in what circumstances.
3. Complex user interaction means more than one way to do everything.
User interaction in desktop and browser based applications was pretty much limited to mouse and keyboard. Mobile applications on the other hand are trying to make user interaction as fluid as possible. We had touch screen and with new phones from Samsung, you can just wave your hand to give commands. Siri is becoming more and more advanced and gives us a glimpse of future that voice commands may become part of every application in future. Devices are smart enough to understand complex gestures, eye movement, direction, tilt, movement, acceleration, GPS coordinates, surroundings, sound, and so on.
As a tester, we need to ensure that application works as expected when user interacts with the app in different ways.
4. Application type – HTML5, Native or Hybrid – means applications are merging.
In the desktop and browser world, applications were straightforward. They were either desktop or web applications. However, with the adoption and support of HTML5, the applications are merging. On all the mobile devices, it is not difficult to find HTML5 applications, native applications and hybrid applications. Testing for hybrid applications would be different from testing native applications and it is important to understand that difference.
5. Dependency on emulators and simulators means true representation is lacking.
For the desktop and browsers, developers always had access to the platform or browsers they were targeting with their applications. Also, virtualization has become more or less commonplace and can be trusted for desktop and browsers.
Mobile devices on the other hand relies on emulator and simulators. However, they are still not true representation of the devices. It is also not possible to replicate advanced user interaction on these simulators. As a tester, we have to be aware of the capabilities and limitations of these emulators and simulators and figure out what can be tested (reliability) on them and what cannot.
6. Security and privacy concerns mean a greater emphasis on misuse of data.
Though most mobile applications live in their own sandbox but many platform features are accessible to them. For example, applications such as phone book, pictures, and videos are accessible to many other applications. These are all personal user data, and any defect around the (unintentional) misuse of this data can jeopardize trust of the application.
In mobile world, it is important to ensure that applications are secure from the intruders, and it is equally important to ensure that applications are not intruding or accessing data unintentionally.
7. Dependency on networks and carriers means more variations in testing.
In desktop and web world, most users were either on LAN or Wireless. These network were not predictable, but compared to mobile networks, they were very predictable. Many connected mobile applications rely on the network – how application responds to 3G, 4G, weak signals, no signals, powerful signals, switching from cellular to wireless and vice-versa or when user is moving at different speeds, etc. – can affect how the application will behave. It is often not possible to come up with or simulate real life situations for mobile applications.
Apart from the variation in signal strength and type, mobile apps can respond differently to different carriers. As a tester, it is important to understand if there are any difference or not and whether application works for all the major carriers or not.
8. Rapid installations, removals, and updates mean staying on top of the latest apps.
Mobile apps are installed, removed, or updated more frequently than desktop applications. Also, underlying OS and platform is updated more frequently as well. As an app developer and tester in the mobile world, you have to be on top of what changes are coming in the next revision of OS / Platform and how it might affect the application.
Usually for most of the applications, user data is stored on the servers and not on the devices. It makes installation a bit tricky. What if the user has multiple devices? What if multiple devices have different version of applications?
Things like backward compatibility, simultaneous support for multiple versions, data preservation, restoring state and data, the ability to install / upgrade multiple times are all part of important checks for mobile application testing.
9. Session management and interruptions mean ensuring that the app behaves properly.
Handling interruptions are the way of life for mobile applications. Apps and users are constantly interrupted by calls, SMS, push notifications, and so on. How applications handle these interruptions and how they maintain their state are important, but it is also important to see how many interruptions the application is generating and what triggers those interruptions.
As a tester, it is important to ensure that application behaves properly when it is interrupted and it is also important to ensure that the application does not interrupt unnecessarily and works according to the boundary defined by the platform or the users.
10. Mobile-specific non-functional testing means there are many more dimensions to testing.
Mobile applications add many more dimensions to the non-functional testing. Old school performance of the application is the obvious one, but there are many other factors as well which should be considered.
How much data your application is consuming? How much it would cost the user (data usage) to use this application? How much battery is consumed by applications? Does it behave differently in high battery and low battery conditions? How much space is it occupying? How much trail is it leaving? How is it clearing the trails / logs, etc. are important non-functional factors which should be considered as part of mobile testing strategy.
Stop me if you’ve heard this before: Users are becoming increasingly uneasy with the way in which apps collect, store and share their personal information. It’s a story we’ve discussed a lot here on the uTest Blog over the years (and more recently, on the Applause Blog), but it’s a story that isn’t going away anytime soon unfortunately.
Late last week, MEF Global Chairman Andrew Bud penned a thoughtful guest post for VentureBeat on this very topic, where he argued that trust in apps is on a downward trajectory. In his view, it all has to do with personal information.
In many ways, the apps economy runs on personal information. It’s the currency – the lifeblood – and the main reason why apps can succeed with a freemium model. As Bud argues, it’s also the reason why trust is quickly declining. He writes:
What underpins this transactional relationship is consumer trust and it follows that, for the mobile industry, this should be the watchword for how mobile businesses build and retain customers. The less confidence people have in their mobile device, the less they will use it and the apps on it. That’s bad news for everyone.
Yet for almost as long as apps have been on the market, consumers have been bombarded with stories in the press and across social media platforms that raise privacy concerns about the way apps gather and store and use personal information. As an industry we have a long way to go.
He backs his opinion with some hard figures from a recent MEF/AVG Technologies study, which found that:
40 percent of consumers cite a lack of trust as the reason they don’t purchase more via their mobile — by far the most significant barrier. And it’s getting worse. In 2012, 35 percent named trust as an obstacle compared to 27 percent in 2011.
Second, 37 percent claim a lack of trust prevents them from using apps once they’ve installed them on their phone. Third, 65 percent of consumers say they are not happy sharing their personal information with an app.
Hard to argue with numbers like that. So what’s to be done? While Bud places a small amount of the burden on users – arguing that they should be more aware of the threats – he places most of it on the industry as whole: marketers, developers, publishers, aggregators, executives and so forth.
And to that I would add software testers.
Just as quality cannot be tested into a product, neither can trust. It has to be a shared value on the part of the brand and/or app publisher. That said, there are a few areas in which testers can ensure a higher level of security – and hence, trust – trust among current and prospective users. Here are a few areas in particular:
One perk of creating a mobile app is the slew of device features available for apps to access. However, this can be a tricky thing to navigate and leads to some non-traditional security considerations.
Developers have historically been liberal in asking for permissions, typically requesting more access than is strictly necessary for the app to function properly. In early 2012 it came to light that apps were accessing address books and other data and features without any good reason. This practice was exposed by the media to much public backlash on the part of users, resulting in many operating systems keeping a closer eye on permissions.
When testing an app, carefully consider which features the application truly needs to access. Apps should not access device features (such as the camera or address book) or gather data that is not necessary to the app’s function. Also be careful when using outside libraries. Be sure to validate the origin to ensure the library is secure and its inputs are not compromised or malicious.
With the rise of BYOD, companies, as well as individuals, will be keeping an eye out for apps that collect unusual data, work with suspicious libraries or access excessive permissions, particularly in relation to contacts or camera/recording features. Superfluous permission requests will often get your app flagged by official reviewers or keen-eyed users.
As mentioned above, some apps collect user data for marketing or research purposes. This is not in-of-itself bad – much of the information these apps gather is valuable for improving the app itself or fixing bugs. However, apps should always make users aware that data is being collected and inform them about how the data will be used. Apps should also notify users which permissions are being granted to the app. This is required by some app stores and even legally required by some states (California, for example). If you are testing an app, be sure you are prompted to grant feature access and data collection permission upon initial launch.
Part of creating a secure app is making sure data isn’t accessible without the right permissions. This goes beyond the realm of authorization and authentication and into the little places you might not think of.
Side Channel Data Leakage appears in OWASP’s Top 10 Mobile Risks. This leak occurs when little trails of data are “left behind” in different places that developers may not realize. Caches, logs and temporary files are all common culprits. When security testing an app, be sure that potentially sensitive information isn’t left unprotected in any of these scenarios.
Just as bad as data leaks is storing information – like API keys or proprietary logic – inside its own code. Apps can be reverse-engineered and shouldn’t contain anything in the code that is sensitive.
Of course, many security issues are not the result of careless behavior on the part of users, but rather careless behavior on the part of the app publisher. Specifcally, failing to properly encrypt sensitive data.
How secure is the data created or stored by the app? You should ask yourself this question before launch.
Even if you think the data is secure, it’s best to encrypt any sensitive or user-generated data – including usernames, passwords, personal information, shopping history, etc. – for an extra layer of protection. Even without leaks, unencrypted or poorly encrypted data is exposed to multiple risks, especially when moving through potentially vulnerable mobile networks.
Sensitive data should be encrypted by the app and then decrypted with a user password. If you are dealing with truly sensitive information, consider if it really needs to be stored or transmitted. If it is necessary, consider only storing partial information or using hash data. That way, if data is leaked the damage will be mitigated. If you do have a leak it’s best if no one can decipher the data.
Even casual apps should encrypt data to avoid unintentionally leaking user information. At the end of the day, most users assume apps are secure and any leaked information (even something as innocent as game scores) will cause users to second guess your company’s integrity.
User trust in apps might be diminishing, but that doesn’t mean it cannot be regained. With the right philosophy – and the right testing processes – users can and will trust their apps once again.
For more great security testing tips, be sure to check out our Security Testing Whitepaper.
Yesterday, the Guardian reported that one-third of wearable devices are abandoned by their users. A lot of us around the tech community have been abuzz wondering if wearables are off to a false start. Was the hot buzzword of CES 2014 just a mirage, destined for the same fate of 3D TV or is their real promise here?
Well, it may be too early to tell. Many wearables today are limited to a single function such as fitness tracking or notifications. The article argues that this is due to the primitive nature of the devices and that lack of integration or an exciting killer app has stalled the market potential. But maybe that’s just where we are in the wearables evolution.
Neither the MP3 player nor the smartphone were runaway successes until someone came in to disrupt the market and make us rethink what these devices should be. The last two rounds came with blockbuster products from Apple, the right combination of hardware and software. But the game is still anybody’s to win. The key to success will be striking the right balance between appeal and usefulness.
Wearable apps and hardware have to be unobtrusive to succeed. That means notifications and monitoring at the right time without reminding users that they’re wearing a computer. For successful growth, these apps and devices have to get out of the way of what users are doing. No one wants to think about charging their watch or glasses or syncing their fitness trackers, they have to just work.
But none of this is a surprise to most early adopters. Technology revolutions typically come out of iterative evolutions until there is that blockbuster hit. It just so happens that this time around there’s more media attention looking for the next big thing, but as developers and producers get in line to figure out what that next big thing is, there will be a couple of toads along the way. Just make sure you’re not one of them and instead delight your users. Check out our whitepaper on challenges and opportunity in the wearable space.
For most companies, April 1st is a less-than-ideal date in which to launch an app or a major update, as consumers, media and other interested parties might take it to be a prank. Google is not most companies.
The tech giant just released a mini-game in the update of its “Maps” application. Unlike most updates, this one incorporates a healthy dose of Pokémon. For those unfamiliar, Pokémon is a Nintendo-owned media franchise involving card games, video games, cartoons and movies that feature trainers capturing wild “Pokémon” creatures with special abilities. Once captured, they are trained to fight and pitted in battles against one another. At least that’s what I’m told.
Of course, Google is known for being quite a prankster, with a long list of similar April Fool’s Day pranks (seriously, a LONG list), however they have also peppered in a number of real releases on April 1, including Gmail. In fact, Gmail was thought to be a hoax, because at the time a free email service with a gigabyte of storage was an entirely new concept. Safe to say that one worked out pretty well.
So is this recent Pokémon update to Google’s Map application a hoax or the real deal? It seems a bit of both – at least we hope! The video promo they put together shows Poke-enthusiasts travelling the world, and “finding” Pokémon using an incredible looking augmented reality app within Google maps to capture their very own Pokémon. The video also promises any person that can capture all 150 Pokémon will have a chance to work at Google, with the title of “Pokémon Master”. Unfortunately, it’s a pretty good bet that these aspects are the hoax portion of their prank.
If you’re willing to take that chance in order to become a Pokémon Master, here’s how to get started:
To start becoming a Pokémon Master, go to your updated Google Maps app, tap the Search Bar, and then tap the Pokeball icon that says Start. You’ll be transported to Isla Santa Cruz, which is a remote cluster of islands, that are apparently teeming with Pokémon wildlife. You can then catch Pokémon by tapping them. There is a Pokedex you can fill with 150 different types of Pokémon, though I’m unsure what happens when you succeed.
Regardless of whether the feature will get pulled after April Fools (it’s hard to imagine running into Pokémon while searching for a hotel on vacation) it’s given users a new reason to check out Google Maps and all of its new features. For Google, I would suspect that it has led to a sizeable increase in usage over the last 24 hours. Everyone wins!
There is a lot of speculation as to whether or not Google is up to something bigger with this prank. Some have suggested a geo-caching project in the works, while others have mentioned some sort of augmented reality app. I guess we’ll have to wait and see.
Either way, it seems that Google has once again reminded the world that they remain the king of April Fool’s Day pranks.
So what can new app developers do to stand out?
Gil Dudkiewicz, of The Next Web, recently pulled together a list of 5 things app developers need to know. Here’s a look:
“1. Imitation is not always the sincerest form of flattery
If your product is good, people will copy you. The better it is, the likelihood of being ripped off increases exponentially. This is a multi-industry reality and it’s the first thing you should keep in mind as you develop your mobile app.If you know you have an excellent product in the works, a strong launch is critical. The initial loyal user base you attract as a result of high visibility will help you stay on top when the imitators eventually end up publishing similar products.
The more active users you have, the better your app holds its ground in the store. Additionally, those are the users who convert to paying customers.
#2. It is far too easy to get lost in the crowd
One of the biggest challenges mobile app developers face is discoverability. With more than a million mobile apps in each of the app stores (Apple and Android), it is becoming harder and harder to generate organic users.
To overcome this, you should plan on putting time and effort into app store optimization techniques. The app name, icon, description and screenshots – all of these need high attention and professional care to reach the best results.
Invest time and money to produce a unique presentation of your app before it is downloaded to grab the attention and pique the interest of users.
#3. You don’t have to play by the rules to go viral
When it comes to distribution, developers often think the only path to topping the charts is through organic results. This is usually not the case! Going viral is rare, so developers should not be shy about opening their pockets and buying some downloads.
Set a budget and contact a solid network, target your audience, and get those users. This is particularly crucial for your launch to ensure a strong start.
Another area in which to exercise a bit of creativity is monetization. Do not be fearful of trying new monetization solutions. Far too many mobile app developers “settle” for the generic solution of placing a flat, boring banner in their ad because they feel it’s the only solution. Wrong! Get your creative juices flowing to come up with an innovative solution.
For example, users are far more tolerant of in-app advertising than you may think, particularly if your app is well-made and solves a problem for them, or even provides a few moments of fun.
A well-integrated, well-timed full-page ad, app wall, or video can generate revenue in a way that compliments the app experience rather than damaging or distracting from the experience.
# 4. There is a best time to launch your mobile app
You’ve probably heard the expression, “Good things come to those who wait.” This is especially true when it comes to choosing the right moment to launch your mobile app.
If you are accustomed to publishing on the Web, toss everything you know out the window, because the best times to publish mobile apps are during the summer and the December holidays. People are on the road and glued to their devices. Use this to your advantage and plan to boost your app just before the holidays for a massive wave of fresh users.
#5. The new kids on the block are the most popular
Before you release your app, ask yourself the question, “What problem does this app solve?” Why will users be attracted to it? There are plenty of strange viral app sensations out there. They end up topping the charts but do not frequently last. The apps with staying power are the ones addressing a need in the lives of their users.
When people say, “I wish there was an app for that” and a search reveals your app, this generates excitement. Further, everyone loves being “the first” to know about a cool new product so they can tell their friends and colleagues about it. This can only help your user base grow.”
What do you think is the best way to make your app stand out in an app store sea of applications? Share your thoughts in the comments section.
Most development teams today have found the agile methodology to be a success – helping teams to increase flexibility and thus develop better, more intuitive software. But when we say teams, we are usually talking about those nimble, fast-moving teams within a smaller organization.
So how can large enterprise brands scale agile and make agile work? Felipe Brito, of IT Business Edge, recently pulled together a list of 5 ways to scale agile for enterprise companies. Here’s a look:
# 1 Establish an enterprise-wide conversation
Agile, and especially enterprise agile, is all about change. And to create an environment that embraces change, you must establish an enterprise-wide conversation to foster transparency, engage cross-functional teams and create champions. Be sure to involve leadership – they must lead by example and promote autonomy and trust by instilling a problem-solving mindset and encouraging responsible risk-taking. You will see significant strides when the leadership team and development team are connected because of the agile shift across the enterprise.
# 2 Be obsessed with your customers
Because what are you without them? Fixating on your customers just enough is a powerful component so make sure you do these three things:
- Understand your customer: All areas of the enterprise must be driven to comprehend customer needs. Involve cross-functional groups and implement a product canvas methodology. Encourage field exploration, group design thinking and journey map analysis of different personas to fully understand your customer. Only then can you tap into technology to devise a solution.
- Design for your customer: Don’t make the mistake of thinking you know enough – engage your customer early and often to create the best solution. Evolve your user experience and enhance the customer relationship by connecting with influencers. Don’t push narrow-sighted solutions. Pull confirmed needs.
- Deliver for your customer: Adopt a business value framework and stick with it. Prioritize business and technical features to deliver a value stream aligned to customer expectations. Be disciplined enough to establish cadence, but nimble enough to embrace change. Inspect, adapt and grow, always obsessed with business outcomes.
# 3 Foster organizational learning
The concept of self-organized teams shows us that agile tackles the fragilities of older, prescriptive methodologies with more discipline, not less. And as agile is extended through the enterprise, discipline must be extended as well. Give your teams freedom, but make sure they are trained and leverage validated methods and tools. This fine balance between autonomy at the team level and integration at the organizational level is essential for success. You must also build communities of practice, establish collaboration tools for globally distributed teams and always source and provide feedback.
# 4 Technical challenges need a strategic response
Complex programs that require technical integrations of multiple components experience frequent architectural issues. When connecting archaic legacy systems and newer/disruptive technologies, enterprise architecture proves daunting, and performance, infrastructure and security issues occur often. To alleviate these pains and others, establish an enterprise architecture roadmap in advance. Stimulate innovation so that new products and services can ride in the express lane within the organization.
# 5 Don’t be dogmatic
While believing in the technical improvements available from an enterprise agile implementation, it’s important not to forget that at its core, the success of any enterprise agile project (or any project, for that matter) hinges on communication – clear, direct, regular communication across the organization. When multiple teams are engaged, alignment is a big challenge and a big risk. While scrum is a perfect solution at the team level, daily standup meetings are obviously not enough. Use Kanban at strategic and program levels to manage inter-team coordination. Fight for continuous business and technology alignment and insist on frequent demos to the business. Find a chief product owner who has accountability and authority with the different groups to oversee the entire program. Establish and evolve metrics that lead to actionable insights.
As you deal with this continuous transformation, delivering large programs to internal or external customers, you will realize that scaling agility inside the enterprise is an evolutionary and enthralling endeavor.
Listening to your users and focusing on finding the real world bugs before your users do are hugely important – to not only a successful software development process – but to the success of a company as a whole.
What tips or best practices do you have for scaling agile across an enterprise? Share in the comments section.
Huawei, one of the world’s largest smartphone vendors, revealed plans to launch an Android-Windows dual-OS mobile device at the Mobile World Congress in Barcelona last month. But now there’s a small change of plans: They’re not doing it anymore.
“Most of our products are based on Android OS, [and] at this stage there are no plans to launch a dual-OS smartphone in the near future,” Huawei said in a statement to FireWireless. However, they will continue to support Android and Windows phones separately.
This comes as a blow to consumers looking forward to running both Android and Windows operating systems on their phone, but mostly to Microsoft, whose Windows Phone usage lags behind Google’s Android OS and Apple’s iOS.
Partnering with Android was supposed to expose Windows Phone capabilities to a broader audience. There was a better chance of consumers buying the phone if there was Android on it too. But there is apparently not enough incentive for Google to allow Microsoft’s OS to coexist on the same device. It seems as if the vision for this phone was all too narrow. Dual-operating systems might seem twice as cool, but it would have also made a software tester’s scope of operations twice as complicated.
The first list outlines the benefits of having a dual-OS device. The second outlines why this system may not have been be so beneficial after all.
- The ability to organize between two OS. Business by day, personal by night, perhaps?
- Compatibility. The customer can use software/hardware even if it’s only supported on one OS.
- Share programs between the different OS. Only those which are compatible with both, but yes, you can share.
- Share your Hard Disk Drive. Although you can use two, you can save everything to one HDD if you wish.
- Impress your friends because instead of one OS, you have two.
- Testing and developing for one mobile operating system is hard enough. Imagine testing a phone that has two! Think of the checklist this device will have to pass before entering the market: Performance, compatibility, security, seamless user experience, processor speed, battery life, boot time, to name a few.
- New unforeseen security issues. As technology advances, testing will always become more complicated. Ensuring that two operating systems are secure will also be twice as complicated.
- Sharing programs between the different OS. As mentioned before, only those that are compatible with both operating systems can be shared. It’s a bit frustrating when you can’t run a program, yet you can click on it in the directory.
- Share your Hard Disk Drive. Essentially, you are cutting the hard drive space in half. If you are partitioning one HDD into two partitions, it is time consuming and once created, quite complicated to increase the size of one partition if necessary. Usually, it’s recommended to just install two hard drives anyway.
- User friendly? For the not-so-tech-savy, this phone is not so friendly.
The incident with Huawei is not an isolated one. This past year, Asus also faced pressure from Google and Microsoft to “indefinitely postpone” plans to sell their tablet equipped with Android and Windows OS.
It seems as if the dual-OS concept is being dismantled altogether, especially when it comes to Windows and Android.
What other testing challenges would you have expected from the dual-OS phone? Do you wish it was still being launched? Tell us why in the comment section below.
The proliferation of smartphones, tablets and computers has put TV sets to the test. Now, according to Dawn Chmielewski, of Recode, studies show that the TV screen may be falling out of favor for some:
“A new study from Deloitte finds that teens and young twentysomethings spend more time watching movies and television shows on their computers, smartphones and tablets than they do on their TV screens.
“The idea that TV is only watched on a TV isn’t true anymore,” said Gerald Belson, vice chairman of the firm’s U.S. media and entertainment practice.
Deloitte surveyed more than 2,000 U.S. consumers about their media consumption habits and technology use as part of its annual Digital Democracy Survey (PDF).
Although viewing habits have been changing as the number of screens in the typical home multiply, this marks the first time these devices have eclipsed TV for any segment of the population, Belson said.
“It’s an indicator of how the market is reacting to the introduction of technologies,” Belson said. “Clearly, a large segment of the population is quite comfortable using any number of devices to watch content. The speed with which it’s happening takes some people by surprise.”
The TV is still king of the castle in most American homes, with Generation X, Baby Boomers and mature viewers saying they spent the majority of their time watching movies and TV shows on the more familiar living room screen. Even older millennials, those aged 25 to 30, say they tune in to the TV more than half of the time.
“The fact that we have some demographics watching television, but not on TV, is significant,” Belson said.
This shift has profound implications for networks, and Nielsen, which are working to find ways to measure TV viewing across multiple screens. Nielsen announced plans to begin incorporating mobile into its traditional ratings with the 2014-15 season.
For media and entertainment companies, the shift puts added pressure on having a quality experience across devices. And that is much easier said than done, especially for entertainment brands. Ensuring a quality experience via television is simple – compared to knowing how your video content loads across devices, in different locations and under real world scenarios. Luckily, in-the-wild testing your video content will help root our these problems before users stumble upon them.
For more resources on in-the-wild testing, download the free whitepaper here>>