import test blog

Young people, between the ages of twelve and twenty-five are generally the most competitive and prefer competitive game play. Competitiveness then drops off as age goes up. People become more interested in games that are mind challenging, such as strategy games or games designed to enhance mental faculties. It’s odd, but the older we get the more interested we become in training our minds.   

While it is true that teenagers play the most, about half of adults also play video games.  It’s just that their motivations are different. Adults are generally under more stress and so their motivation is often to find a game that is stimulating but not stressful. Stress free game play is important to them and it doesn’t seem to matter if it is solo or social play.

Although teenagers are the single biggest game playing demographic in terms of percentage, it is millennials who are leading the way. After all, millennials were raised in a world of ever expanding digital technology and they’ve grown accustomed to it. The oldest millennials are now reaching their mid-thirties. So, it’s no surprise that despite the fact that around ninety-seven percent of teenagers play online, the average age of the online gamer is thirty-five. It also comes as no surprise that the smallest percentage of players are those over sixty-five. Only twenty-three percent of seniors are online game players.

Video gaming is also in the process of moving beyond the console, which was the major platform in the not so distant past. The smartphone is now the most popular platform, followed by the PC with the console bringing up the rear. Online gaming is going increasingly mobile.

And there is no doubt that digital technology will continue to expand how games are played in the future, no matter who is playing them.

Test often so defects can be caught early and fixed before they become expensive problems. Fixing and retesting should be an ongoing part of the development cycle. Testing often also minimizes the chance of defects becoming buried in the system, where they are difficult to remove and may not show up until later.

Perhaps one of the most important aspects in the art of bug retesting is to eliminate the need to retest by minimizing bugs in the first place. While it is impossible to completely perfect the development process, approaching perfection is possible.

One way to approach perfection is to notice when the number of bug reports goes higher than normal. If a certain module seems particularly buggy, it's important to do more than just try to push forward through an avalanche of bugs. Don't just focus on fixing bugs. Find out why there are more bugs than expected. Look for flaws in the development process and fix those. It could be anything from a green developer to a problem with code review or even erratic or incorrect policy.

The art of retesting goes beyond procedure, it's a holistic approach that includes more than just correcting bugs.  It includes the rest of the development process as well. Testing should extend across the development cycle. Catching problems when they are small and new means less retesting later and less retesting means faster delivery and less chance of bugs being missed and causing problems after release.

Retesting requires detailed observation. It's more than just retesting against failed tests. The person doing the retesting must look for small details and variations in functionality in order to ensure that changes in code do not have a subtle and unpredicted effect on the system under test. This makes retesting a bit of an art and requires a well developed testing skill set.

Keeping testers happy and motivated is not always easy.

Hazy test requirements, monotonous work, and impossible timelines have become the status quo for many organisations - essentially setting testing teams up for failure - yet it’s testers who are often thrown in front of the bus when issues arise!

The result is a culture of frustration, poor performance, burnout and employee turnover.

Below we look at five secrets of highly-effective digital teams and the strategies they use to empower testers, increase job satisfaction and boost digital quality. 

We have also included tips to help you create an environment that will ensure your software testers are as effective as they can be, while keeping them, and their proprietary knowledge, on your team long term.

Secret #1: They rethink mundane, repetitive tasks

Perhaps the most common problem testers face is monotony.

As applications become larger and teams become more focused on particular areas, the software testers are likely to test the same aspects of the application iteration after iteration, release after release.

At first, this seems like a good thing. After all, if they are experienced in a particular area, why change?

The problem is complacency.

As testers test the same code over and over again, they will begin to take certain things for granted. Certain user experiences may become commonplace to them and get ignored, letting issues and defects slip through to production.

What you can do about it...

The most obvious solution to combat monotony is to mix things up. Rotate teams so that software testers will test different aspects of each release. Not only does this keep the work fresh, it also ensures that all software testers have a broad understanding of the application as a whole.

When it makes sense, change testing methods. If testers aren’t able to switch areas of expertise, encourage them to approach the testing from another area of the application. This will facilitate testers putting themselves in the mindset of a person who has never seen the application before.

If monotony stems from large amounts of routine testing, consider outsourcing some of the testing. Third party testing solutions, like Bugwolf, can take some of the weight off of software testers, so they can focus on more specialised sections of the application.

A fresh set of eyes may even see issues that someone who’s been analysing the same code day in and day out could miss and overlook.

Secret #2: They take a pragmatic view of schedules

One of the key aspects of the agile development methodology is ensuring that sufficient time is allotted for testing. Each story should have tasks for testing, but each release should have time set aside for large scale testing and regression of the work about to be released.

Sometimes QA estimates are viewed with scepticism or scorn. Some features and stories may be very light on development, but could require extensive regression testing of the applications and websites affected. It can be difficult for software testers to increase the size estimate of a story if they feel that their estimates aren’t respected.

When teams aren’t given sufficient time to test, mistakes will happen and defects could make it through to production. This will not only affect the public’s perception of your websites and applications, but it also requires you to derail teams from new work to revisit what was just completed, which pushes scheduled for new projects further behind.

What you can do about it...

Get testers involved in key projects as early as possible. Make sure they are present as features are being groomed so they can weigh in early with QA estimates and concerns. The sooner the stakeholders and developers are made aware of heavy QA requirements, the more likely they’ll expect and respect the time requirements.

Take advantage of nights and weekends. While the development environments can be in flux during the business day with frequent deployments, nights and weekends give QA a reprieve from these changes to test code. Again, third party testing providers can take advantage of these times.

Secret #3: They have well-defined features and stories

There are few things worse than opening up a story for testing and seeing a blank screen. No acceptance criteria (AC), no specific requirements. When software testers write test cases for stories, they often look to the AC, writing a test case for each point, ensuring that each is met.

When none are available, software testers are left to either track down the stakeholders and developers to determine the intent of the story or, even worse, attempt to determine the intent themselves. At best, this wastes the time of the engineer and the developers, undermines the concepts of agile development, and slows productivity as they have to locate product owners to determine the AC. At worst, the real intent of the story is never tested, and a flawed user experience can be deployed to the public.

What you can do about it...

There’s no harm in having QA involved with every aspect of the backlog refinement and grooming processes. They know what they’ll need in order to create effective test cases and can guide stakeholders and product owners into creating succinct and clear AC.

Ensure that a process is in place for creating and defining initiatives, features, and candidate stories. Involving developers and software testers early makes hitting the plan’s goal possible.

Secret #4: They're have the tools they need to succeed 

Keeping up with the ever growing number of devices can be incredibly costly

It’s very difficult to test adequately when guidelines aren’t in place to tell testers which OS’s, browser versions, and devices should be supported.

Without adequate resources, testers will have to pass code blindly, not being able to test fully in all the devices and browsers that management wants to support.

The proliferation of connected devices has made cross-device compatibility testing more crucial than ever before. If you’re not supporting testers with a deep device lab that mirrors your customer’s usage habits, you’re setting them up for failure.

What you can do about it...

Clearly define your requirements. Before any code is written, developers and software testers should have a clear understanding of what devices, OS, and browsers you expect to be supported. This allows the developers to write code that will both function properly, and which software testers can test properly. When the testers know what to test, productivity and quality will increase.

Have the appropriate devices and emulators available to the testers. This is another case where a third party tester could be helpful. Third party testers will have the necessary devices and infrastructure. If your team can pass off test cases to another party to test across all devices, their time is freed from repetitive testing to move on to the next project in the pipeline.

Secret #5: Their feedback is valued

In my experience, software testers have a very comprehensive understanding of the code base and the application. Developers can tend to focus on a single component or module, working through specific issues.

I’ve seen developers who are so content to have solved a particular pain point in the code that they fail to consider all of the implications of this code. Testers have to approach the module as it fits into the whole.

Despite this understanding, however, testers are often given a secondary role, if not outright ignored during grooming and planning. Their input during testing regarding user experience is often dismissed, completely ignoring their in-depth knowledge of the user flow through the application.

If the input of your team is not taken seriously, the greater business may not have a full understanding of the complexity of the tasks. This quickly leads to unrealistic expectations and the view that the testing team is a bottleneck.

Listening to the feedback and suggestions from your QA team will increase their morale by showing them that their feedback is valued. When your team’s suggestions are validated, the testers will take more pride in their work, which has been shown to increase effectiveness and productivity.

What you can do about it...

Listen: understand that these people have valuable and informed opinions, and approach them with an open mind.

Give QA a platform: encourage them to speak up during planning meetings and design reviews so that they can effectively apply their knowledge.

Solicit impartial opinions: Sometimes it’s more effective to hear something from someone outside the company. Hearing a third party echo the concerns of your own team of software testers will lend credence to their opinions in the future.

With the amount of proprietary knowledge software testers gain over time at a company, of applications, infrastructure, and methodologies, replacing them can be as costly as replacing a software engineer.

While the cost of recruiting a replacement has been estimated at 13.4% of that employee’s salary, some estimates have the cost of onboarding a new employee at 150% of that salary.  The cost of replacing a software tester can be even higher, as their onboarding will affect the productivity of the entire team.

It literally pays to keep them happy. Tackling some of the frequent problems and headaches they have to deal with by adjusting processes and bringing in third party resources like Bugwolf allows your engineers to truly focus on what matters: delivering a quality product to your consumers.

The APAC region is currently witnessing a flurry of activities in the FinTech space. According to a report by Frost and Sullivan, the FinTech space will expand to $70 billion per year by 2020.

This growth is driven by an eclectic bunch of startups, accelerators, and enterprises. Today we bring you a list of APAC influencers in these organisations.

Follow these thought leaders to keep your finger on the pulse of the APAC FinTech environment:

Lucy Peng (China)

One of the founders of Alibaba, she has been the CEO of Ant Financial Services (a part of the Alibaba Group) since March 2013. For 3 years before this assignment she served as CEO of Alipay.

Simon Cant (Australia)

He is the president of FinTech Australia and the co-founder and managing director of the Reinventure Group which has invested $50 million in startups operating in Australian and New Zealand markets.

Janos Barberis (Hong Kong)

Recognised as a top-35 global Fintech leader, he founded FinTech Hong Kong, a platform billing itself as the “ single point of access for Hong Kong's FinTech scene”, and the SuperCharger, a FinTech accelerator.

Renu Bhatia (Hong Kong)

She is one of the founding partners and MD of SuperCharger. She is also co-founder of Asia FinTech Angels which is Asia’s first angel investor network for the FinTech industry.

Mike Cannon-Brookes (Australia)

He is the co-founder of tech startup Atlassian which now boasts more than 43,000 clients, including some of the biggest names in banking, finance and technology such as Citigroup, eBay, and NASA.

Alex Scandurra (Australia)

He is the CEO of Stone and Chalk, an independent and not-for-profit FinTech hub based in Sydney. It’s stated mission is to support a wide variety of Australian FinTech startups. S&C startups have collectively raised $101 million in their first year at the hub.

Jennifer Zhu Scott (Hong Kong)

She is the cofounder and principal of Radian Partners, a VC fund and covers FinTech, blockchain, and AI.

Vladislav Solodkiy (Singapore)

He is Singapore’s FinTech evangelist and the the founder of Life.SREDA, a FinTech-only fund which also sponsors Finovate and Money2020 conferences. He is one of the authors  of the annual FinTech-research report: “Money of the future” (2013, 2014, 2015, 2016 in Feb’16).

Vincent Turner (Australia)

He is the CEO of Sydney based FinTech startup named Uno. With Westpac as the majority shareholder, Uno provides a digital mortgage service which algorithmically matches users with the home loan based on the exact needs,

Mikaal Abdulla (Hong Kong)

He is the Co-Founder & CEO of 8 Securities, Asia’s first robo-advisor and $0 commission trading service. The firm operates out of Hong Kong and Tokyo and holds $700 million  in customer assets.

J. P. Ellis (Indonesia)

Based out of Indonesia, he co-founded and currently leads the Compare88 Group, Southeast Asia’s largest financial e-commerce group serving 3 million customers monthly.

Charlotte Petris (Australia)

She is the founder and CEO of Timelio, Australia’s largest peer to peer invoice finance platform. Timelio helps users get paid faster, and has processed $40 million in invoices and is growing at 30% MoM.

Vijay Shekhar Sharma (India)

He is the the founder of Paytm, one of India’s biggest electronic wallets and e-commerce marketplaces, valued at $5 billion.

Mehedi Hasan Sumon (Malaysia)

He is the founder & CEO of MyCash Online, a FinTech startup which offers secure and online services like booking tickets or topping up mobile data  to unbanked migrants living in Malaysia and Singapore.

Matt Symons (Australia)

He co-founded SocietyOne, Australia’s first financial marketplace which connects lenders with borrowers based on their credit score.

What do you think of our list? We will keep on periodically updating this list, and would love to hear from you on who else could have been included.

The first thing to check is how quickly your website loads. Today, people expect sites to load almost instantaneously and they have very little willingness to wait. This is why cross browser testing and testing for mobile friendliness is important. Make sure that all images on the site are optimized for quick loading.

The irony is that it usually isn’t the technology that is the problem. It’s the little things that can cause the most problems. Have you ever been reading through a book and collided with a typo? A typo can throw you right out of the reading experience. No matter how carefully prepared your sales copy might be, one typographical error can cost you a conversion. So make sure there are no typos. Not just in sales copy, but throughout the site. This includes navigation, buttons, calls to action, and forms.

Speaking of content, make sure there are no inadvertent font codes that scramble words or make them look odd. While this isn’t a fatal flaw, it does lower the credibility of your site.

Forms should have an easy flow with accurate and simple instructions that don’t cause the customer to get stuck along the way. Remember that a conversion isn’t a conversion until the sale is made. Anything that slows the customer down, especially in the final part of the sale, can cause an abandoned shopping cart.

Perhaps the single most important factor is navigation. You must understand the customer’s journey on your site and make that journey as easy as possible. This goes beyond just making sure that all links go where they ought to go. It’s a matter of understanding your customer, and this might take some research.

Also, make sure all pages have meta tags and and meta descriptions. These may sometimes be ignored, but they are an important resource for search engine spiders to crawl.

Pre-release website testing should be as thorough as possible to ensure smooth operation and maximum conversions. And it doesn’t hurt to bring in a fresh set of eyes just to be sure.

This doesn’t mean that the software tester trusts no one. It’s perfectly okay to trust the developers, it’s just not okay to trust the product. When it comes to software testing, skepticism reigns.

Software is developed to solve problems or facilitate actions. Developers and designers must approach development and design with the assumption that these goals can be reached. They are required to be optimistic. While the tester, on the other hand, is required to be pessimistic. A successful software tester is often considered nitpicking and anal-retentive by his or her colleagues. It’s the price you pay for being a good tester.

There are all sorts of reasons why a tester must be critical and skeptical. For example; the pressure to complete a project can cause developers to overlook sometimes ambiguous results. If the tester doesn't sniff out these potential problems, they will end up in the end user’s lap. We are all familiar with horror stories of what happens when software is put on the market prematurely.

So, it's important to work with developers in a friendly and open-handed manner. There is nothing wrong with honest criticism and no one should take offense. We are all on the same team. However, it is vitally important to make certain that the software reaches the market as clean and functional as possible. The reputation of everyone involved is at stake, as well as the future profitability of the company.

It's better to find the bugs in testing, than to fix a crash in the field.

User experience testing is an example of nonfunctional performance testing.  It exists to determine how well the user can interact with the application and so such testing goes beyond the application itself and enters the realm of the environment that application is intended to function within.

Performance testing is perhaps the most important form of nonfunctional testing.  In performance testing, the application is tested against a real world sized database to determine if response time and other important processes fall within acceptable parameters.  Load testing is another form of nonfunctional testing.  The application is put under the pressure of many users accessing at once in order to replicate the environment that the application will be functioning in.

Other forms of nonfunctional testing include stress testing by pushing the system beyond its designed limits.  This isn't the same as load testing, which deals with the maximum designed load, but is an attempt to determine how the system will handle a load greater than it has been designed for.

Nonfunctional testing pretty much addresses anything not directly addressed by functional testing.  This includes things like scalability, where the capacity of an application to be scaled up is tested.  Or it may include other things such as speed, stability and reliability.  It may even include the classic smoke test, where the application is run just to see if anything goes wrong.

Performance testing begins by documentation of the important requirements through interaction with stakeholders such as project managers, architects and developers and of course users. Requirements are then set and a test strategy is planned and carried out at various points during software development depending on what is to be tested, such as application architecture or user experience.  This includes the use of performance test scripts.

Nonfunctional performance testing exists to demonstrate that the application meets the intended performance criteria.  In the process, it can gather information that enables fine tuning of the system. Nonfunctional testing also improves user experience, informs stakeholders as to the status of the application and, most importantly, demonstrates when the application is ready for delivery.  Nonfunctional performance testing gives us an understanding of how a given system will perform in the real world.

Be brief and specific

Yes, a test plan is necessary but it doesn’t have to be a paperweight that no one reads.  The test plan defines what testing will be done in specific terms. A single page test plan in any format works. The test plan provides a method of planning rapid testing in an effective manner.

Conduct risk based testing

Rapid, valuable testing needs to be risk based. Your QA resource won’t be able to cover multiple types of testing thoroughly in a rapid test cycle. The first step in the test plan is having the team define which areas must be tested because they inherently contain the greatest risk of failure. iOS8 features cover new MDM related administrative options and significant security testing impacts.

Define test types and unit testing

Define the type of testing based on risk that you can test. Based on the new features in iOS8, functional and security testing are critical. Handling the certificate usage, the handoff between devices and transferring confidential data means security and data sharing issues. It’s possible to combine testing into a single test suite covering multiple high-risk areas and  imperative to include developer written unit tests to assist in test coverage. If you plan it out in advance, you’ll know what functionality you are testing and how thoroughly.

Continuously test

Testing never stops. Continuous testing is executing all the other testing you didn’t have time to do. For example, the optional features in iOS8 mean you need tests when features are turned on and when they’re turned off as well as random combinations. Additionally, performance, compatibility, interface, services and operational testing may be options you need to plan for and execute between release cycles.

As software development has evolved into the agile model, testing for quality assurance has adapted to the challenge.  Where once the waterfall model put everything in its place, including quality assurance, QA has become integrated into the development process along with other forms of testing.

Quality Assurance is changing in a number of ways.  Where once it was an activity that took place primarily at the end of the development cycle, it is now an integral part of the cycle and increasingly takes place throughout development as modules come on line for testing.

Testing has become more and more integrated and the line between different types of testing have started to blur.  Quality Assurance now folds into areas of functional testing, that QA was once considered separate from.  In fact, Quality Assurance is no longer so much a type of testing, but the process of assuring quality throughout the development cycle, using whatever testing methods are appropriate.

And, Quality Assurance is in the process of becoming a stand alone entity, not siloed or a seperate department so much as a designated quality assurance team that overlays both development and testing. This change is increasingly visible as subject matter experts are increasingly brought in as part of the complete development/testing cycle, rather than only in the user acceptance phase.

QA is now included very early in the development process, even in early planning sessions.  Planning for Quality Assurance right from the start makes assuring quality easier throughout the development cycle.  This is because quality does not have to be imposed as an afterthought but is part of the entire process, from concept to final delivery.

Unit testing for screen configurations

Developers can code to control an application’s UI for both screen size and density – at least for known screen sizes and densities. The code may need to have a separate UI module for each screen configuration of size and density. Add screen size verification tests as unit tests and have them execute automatically each time a release build is created. You’ll get the screen size tests built into the code and the tests will be executed frequently. It won’t all cover all of your iOS8 testing needs for screen size, but it is an effective and continuous testing method.

Test using visible state transitions

Include in QA testing coverage for screen size, density and orientation. Tests can be developed to cover all three at once so that testing is consolidated to cover maximum ground. Because screen size and density are generalized into set sizes within the code, testing manually is the best method of catching defects on actual devices. 

Test using error guessing techniques

iOS8 has a larger screen. Test all paths that you think users are particularly likely to follow with your application at least on large, medium, and small screen sizes. Verify what seems like simple display items such as buttons and if users need to scroll side to side rather than just up and down. Use error guessing to test areas you feel are likely to be affected by sizing differences or changes. Test the orientation by rotating the device in ways you think it will fail using direction, speed, and repetitive actions.