CrossBrowserTesting.com

A Design, Development, Testing Blog

Don’t Limit Diversity to Just Your Browsers

By Leave a Comment

Angie Jones Software Testing Diversity

Everyone understands the need to test their applications on a diversity of browsers and devices. Yet, it seems many still don’t understand the value of having diverse people involved in the development and testing of the software.

I recently stumbled upon a thread in a technical forum where the opening poster asked how hiring for diversity helps a company succeed. The number of commenters who believed diversity hiring to be nothing more than the politically correct thing to do was frightening. Many even resented that companies are making extra efforts to find diverse talent.

There were several commenters in this thread who were software developers and believed that writing code is a task that does not require a diverse perspective. Perhaps there’s some validity to that statement when considering the most narrow of use cases, which are typically what developers have in mind when coding. Most times, developers are coding just enough to pass the acceptance tests that are provided by business analysts who typically get their requirements from a specific client or from market research. However, traditionally, testers have done a great job of considering the many different usages of the software, and having a diverse group of testers ensures that a variety of perspectives and scenarios are examined.

Here are a few use cases that show the importance of diverse technical teams, particularly testers.

Mistaken Identity

A couple of years ago, Google introduced a “smart” photo tagging algorithm that would use image recognition to identify the contents of uploaded photos and automatically tag them. The feature was developed, tested, and released, and while in production, it mistakenly identified Black people as gorillas. How did this happen? The system was trained with photos of humans but apparently, no one thought to use photos of dark-skinned humans in the training or testing, therefore the system had no idea how to recognize people of color.

Similarly, in New Zealand, when an Asian man attempted to submit a photo for his passport application, the Department of Internal Affairs’ website rejected the perfectly good photo because it mistakenly thought the man’s eyes were closed. This is another case of the software not being trained to recognize racial differences.

Having a diverse set of testers can help avoid embarrassments like these, but it becomes even more critical as the future of artificial intelligence has to make vital decisions and are taught to value human life over everything. We certainly want our algorithms to be trained and tested to be able to correctly identify who is human.

The Unheard Consumer

Because many technical teams are dominated by White males, not only is racial diversity unaccounted for but in many cases, so is gender diversity. Back in 2011, a woman reported about how her fancy new voice-controlled car system doesn’t recognize many of her commands, although it had no problem understanding everything her husband said. These systems are designed to eliminate distractions and the need to work with devices while driving. However, when it doesn’t work for women, it promotes the dangerous behavior it’s designed to avoid — forcing them to resort to working with their device while driving.

However, this was six years ago. That’s practically a lifetime in technology. One would assume that voice recognition is much better in recognizing women’s voices today. Rachael Tatman, a sociolinguist who studied Google’s speech recognition software, disagrees. Her research into the software still shows a striking difference in the accuracy of recognizing a man’s commands compared to that of a woman. Much like with image recognition, Tatman blames the lack of diversity in the data set used to train the speech recognition system. Women make up half of the world’s population and are often times unaccounted for when developing and testing software in the male-dominated tech industry.

Cultural Influence

It’s natural for people to surround themselves with others who are like them. One argument that is often made by White male engineers (including the aforementioned thread) is that hiring underrepresented people and expecting their views to represent everyone of the group they identify with is fallacious. I can agree, however, I don’t think it’s fully appreciated that an underrepresented person does have a much better understanding of their group than outsiders do, and more than likely have a greater representation of members of that group in their immediate networks. So while it may not be everyone’s view per se, they are at least aware of lots of different views from people of their group.

For example, I’m a Black tester who works at Twitter. As a whole, the way Black people use Twitter is so different from everyone else that it has its own cultural identity known as “Black Twitter”. While I certainly cannot speak for all Black users of Twitter, my understanding and immersion in Black Twitter is extremely valuable to the company. Not only am I sensitive to how potential changes can affect them, I am also in a position to make recommendations for features that can lead to increased activity by this group. Arguably most important, I am a first-hand early witness to how this group uses the product, and as a tester, have real life scenarios that employees who are not a part of this group may have never noticed.

Recently, a Black Twitter user manipulated the product in a way I have never seen before. He used the features of the site to set up an interactive and immersive scenario. I do not follow this user, his tweets had not gone trendsetting viral, and yet because of my association with this group, I became aware of this new use of the platform within hours. The use was so creative that I’m sure it will catch on and others will do the same. As a tester, I became aware of this real life customer scenario before it became a mainstream use case and can do my part to ensure that we as a company are ahead of the curve in planning for this.

This type of insight is not restricted to Black Twitter. The Japanese also use Twitter in a very different way than most. Having testers who understand these cultural nuances and can keep them in mind when designing and testing new features is extremely valuable.

Again, no one debates whether testing software on the browsers and devices that their customers use is beneficial for the business. It’s a no-brainer. I don’t believe it’s that far of a stretch to find similar benefits and advantages in also aiming to comprise your technical team with people who can relate to your customers and better understand potential scenarios and use cases.

 

Angie Jones

About the author: Angie Jones is a Sr. Automation Engineer at Twitter who has developed automation strategies and frameworks for countless software products. As a Master Inventor, she is known for her innovative and out-of-the-box thinking style which has resulted in 22 patented inventions in the US and China. Angie shares her wealth of knowledge by speaking and teaching at software conferences all over the world and leading tech workshops for young girls through TechGirlz and Black Girls Code.

12 Reasons to Pursue a Software Testing Career

By Leave a Comment

Reasons to pursue a software testing career

Software testing gets a bad rap. But, people that don’t think a software testing career is rewarding, challenging, and fun surely aren’t software testers. In fact, most testers really love their jobs, and wouldn’t give it up for any job in the world.

When considering which direction to take your career next, here are a few reasons you should think about pursuing a software testing career.

  • It’s challenging – Testing is not easy — there are constantly puzzles and problems to solve. The job will likely bring something new every day. If you prefer a boring job where you don’t have to think too much then don’t pursue a software testing career. But if you want a job that keeps you on your toes, anyone will tell you that testing is a really great choice.
  • It’s important – Testers don’t always get enough recognition for the work they do, but we’d be lost without them. As a tester, you’re advocating the end user and making sure that they’re being delivered a quality product. Without someone to find bugs before software is delivered, many businesses would be suffering from poor reputations and unloyal customer bases.
  • It’s creative – You have to get a little innovative when testing. The process isn’t going to be spelled out for you — in fact, it takes a little detective work. By acting as the end-user, you’re the one who has to get creative when thinking of places there may be inconsistencies.
  • It’s data-driven – One of the coolest things about a software testing career is that it’s just as technical as it is creative. While most testers need to have a foundation of developing and coding as a baseline, they’re also analyzing day-to-day data and product trends. Having a knowledge of computer sciences is imperative,  as you have to be someone that knows the ins and outs of software and the way it works.
  • You’re constantly learning – Whether you’re starting to code, automate, or security test, there’s always more to learn in a software testing career, and you likely have a very supportive team behind you to make sure you have all the resources you need to be the best. Plus, your work will never be stagnant, as you’ll be continuously growing and improving your practice.
  • You get to test the limit – You can’t go around smashing people’s laptops, but you do get to explore software to see where it stops working. Of course, testers don’t actually break software, but it can be really fun to find a bug no one thought existed in software everyone thought was working perfectly. It takes especially critical eyes to find these kinds of problems and solve them.
  • It’s in demand – If you want a high growth, high paying career, QA is the way to go. As a software tester, you’ll always be needed and will find no lack of leading companies trying their hardest to recruit you, and there are constantly opportunities to grow in your career to reach a managerial level.
  • There are many paths – Every company that uses software needs software testers, which is to say, pretty much everyone needs software testers. Testers are valuable in basically any industry, from healthcare to retail to video games. Additionally, you can choose whether you want to go into manual testing, automated testing, performance testing, etc.
  • It’s a specialized skill – Despite misconception, not anyone can test. Most testers start in a similar field and find themselves being drawn to the role, but it requires in-depth knowledge of UI/UX design and development patterns and practices, as well as analytical and communication skills. Not everyone will find that they have what it takes to be a tester, but those who find it’s their calling are sure to fall in love with it.
  • It’s rewarding – You’re essentially helping your company build a better product. If you take pride in your work and these people you work for, then testing is an exceptional way to make a measurable difference in your organization’s goals, objectives, and bottom lines. In fact, you’ll probably see your impact every day on the job.
  • You’ll love your colleagues – As the software industry increasingly trends toward concepts like Agile development, Continuous Integration, DevOps, and automation, communication becomes a highly important skill for software testers. This means that throughout the day you’ll always be collaborating with smart, interesting, and passionate people who share the same interests as you at every level in the organization.
  • There’s a strong community – Additionally, one of the best things about being a tester is the insanely supportive and robust community. From StackOverflow to Twitter, testers are a tightly knit group who have each other’s backs and always enjoy discussing best practices and trending topics in the industry.

Why did you become a software tester? What’s your favorite thing about your job? Share with us in the comments!

Establishing Your Scrum Team’s Definition of Done

By 1 Comment

Kanban scrum definition of done

When talking about building culture in the software development process, deciding on a team’s Definition of “Done” has become a major component in the shift to Agile — most commonly in Scrum — that ensures every player works together toward the same end goals.

For example, if a developer is working on a certain user story and tells the product owner they’re done but it hasn’t been tested, this will backup product release once the mistake has been realized, or potentially affect reputation if a buggy app is deployed without being caught.

While one person may be finished with their tasks, that does not mean the project is done as a whole, and saying so can limit progress if it’s not done in all parts and stages. Teams that do not consider this groundwork often find that it severely impacts productivity.

The Definition of Done for Scrum Teams

When Agile strives for iterative development, fast feedback, and adapting requirements, having limited communication will delay a team’s acceleration and pace when pushing a project or feature set to market.

Maybe you feel factors like testing, reviewing, documenting, releasing, or even collaboration should go without saying, but many team members will consider tasks done based on whether or not they fulfilled their individual role.

Because Scrum has lightweight management overhead and bi-weekly check-ins (Sprints), having a Definition of Done becomes even more important to your team’s efficiency. Nothing kills team chemistry and collaboration quicker than having tasks done “half-way” only because another teammate thought they only had to scope out a project, and not actually supply mocks or a rough draft.

Coming up with a Definition of Done is about the bigger picture organizational process of your team. By looking at projects as a collaborative effort instead of dividing responsibilities among different departments or one leader, you encourage the communication and transparency that’s necessary for Agile.

This is why creating a Definition of Done should be a starting point for Scrum teams. Your organization should essentially have a checklist of specific criteria and requirements that need to be fulfilled before the user story is done. However, the definition will likely differ from organization to organization based on the size of the teams, different fulfilled roles, and different project requirements.

Criteria to Consider When Defining Done

  • Prioritizing tasks – Having an order and process in place should be a prerequisite for defining done. This means having a set expectation for every time a task moves throughout your Kanban flow, whether something is selected for development or in code review. Also, this includes deciding whether a Definition of Done should just be attributed to user stories, or features and epics as well.
  • Including testing – Testing is often the most overlooked step. Is more manual or automated testing needed for this particular project? Are you using regression tests throughout development or just at the very end? Have you tested across multiple browsers? What processes do you have in place for analyzing risk and evaluating security?
  • Involving every role – If your developers have a different Definition of Done than your testers, for example, projects aren’t going to be done by everyone’s standard. This also includes product owners, project managers, scrum masters, designers, automation engineers, QA, or any other role. Furthermore, the definition should not be prescribed by one team member, but instead agreed upon by everyone.
  • Coming up with a timeline – How many iterations are you striving to make throughout the day? How many are you committing to at the end of the day? What are the goals during your sprints? How do you keep track of this and what happens if a task is not completed in time?
  • Ask what makes the process complete – Is it done when the product goes through a last round of testing, is it done after a last once-over by the product owner, or is it when it’s released to the end user? Having an end point is just as important as having a designated place to start.
  • Document the definition – Have the information easily accessible for people to reference, even if it’s printed out as a checklist. This way, everyone can double-check before they move a task into “done.” Additionally, in the same way, that Agile is adaptable, your Definition of Done should be, too. Make sure to return to the document and reassess processes that need to be adjusted according to changing requirements.

How do you decide when a project is “done”? Share your thoughts in our comments!

How Leading Tech Companies Are Implementing Accessibility Testing

By Leave a Comment

Accessibility testing

After Ministry of Testing featured the 30 Days of Accessibility Testing Challenge, we wanted to take the opportunity to further examine what it means to make your website or application accessible in today’s digital landscape.

At CrossBrowserTesting, we believe that software and design should be of the highest quality no matter what browser or device you’re on. But even more than that, we also know that the best software is optimized for every audience and every potential user.

When the smallest details such as the shade of blue in a link can affect how well someone can view your content, it goes to say that these elements suddenly become crucial to creating an equal user experience.

Keep reading to learn more about how tech organizations are focusing on accessibility testing and how you can similarly develop more accessible software.

A Culture of Champions at Slack

Since Slack first began their mission to approach accessibility, they’ve released features like sidebar themes, screen reader improvements on iOS and Android devices, adjustable zoom preferences, and the option to stop automatic animations. They also have plans for upcoming keyboard navigation support for people without a mouse.

Each one of these features has in mind a different disability or assistive technology that had not been supported previously.

“The attitude we’re adopting at Slack is that building an accessible product makes for a better product overall,” said Slack Accessibility Product Manager George Zamfir.

“When you consider how different the user experience is for a blind person using a screen reader or a person with limited fine motor skills who relies on their keyboard to navigate, it quickly becomes clear that addressing accessibility needs can’t be left to the end of the product development cycle, they have to be factored in from the beginning.”

When talking about making accessibility a part of the culture, Zamfir suggests that providing training for people that are invested in the idea of accessibility testing helps them become “champions” for the cause, and in turn, they advocate the practice throughout their teams.

By communicating the value that fostering accessibility in those products brings to the organization as a whole, people in any role from design and QA to customer experience can contribute to the overall quality of service Slack provides for differently abled people.

Best Practices in Salesforce Accessibility Testing

Salesforce is another top company that not only adheres to accessibility guidelines and standards but goes above-and-beyond to make their platform valuable to everyone.

“[Disability] can include people who are blind, color blind, or have low vision, those who are Deaf or have hearing difficulties, people with mobility impairments which may be temporary or permanent, or people with cognitive disabilities,” said Principal Accessibility Specialist Jesse Hausler.

When considering which audience to design for, Hausler makes it apparent that making a universal product is the only acceptable solution. “Design for people who are young, old, power users, casual users, and those who just enjoy a quality experience,” he said.

A few things he says designers can keep in mind when thinking about accessibility testing include making sure there’s enough contrast between text and background, not solely relying on color to convey information, defining and labeling form fields, optimizing menus and autocorrect, attributing images, and making links more visible.

The process of making things accessible isn’t always an easy fix, however, and there can be a lot of testing to make sure that adjusted design is actually an improvement. In fact, one Salesforce Product Designer helped build a tool called ColorSafe to help designers better choose accessible contrast colors and make the task less repetitive.

Shopify Self-Reflects On Its Mission

Shopify has also shared how they make an effort to establish accessibility testing.

“At Shopify, our mission is to make commerce better for everyone. […] To us, a quality web product means a few things: certainly beautiful design, engaging copy, and a fantastic user experience, but just as important are inclusivity and the principles of universal design,” said Shopify Front End Development Lead David Newton.

“We take our mission to heart, so it’s important that Shopify products are usable and useful to all our users.”

Instead of creating an “Accessibility Team” they instead focused on creating a more inclusive and accessible culture and implementing new processes into already established product teams. Additionally, a large component of this culture shift was dispelling the myth that accessibility meant lacking function or design.

Shopify acknowledged that making things more accessible was certainly a challenge since it wasn’t something they regularly thought about before. However, just by making some small changes like writing more semantic HTML, applying closed captioning, or just documenting common accessibility requirements, they were able to outline clear expectations for developer and designers, while making the organization more accessible to a larger audience.

With the help of accessibility testing tools such as AChecker, Color Oracle, NoCoffee, and WAVE, it was also much easier to go in and adjust the components that were already working well without starting over.

Additionally, as designers became more accustomed to including accessibility testing, it also made them better designers as they were more intuitive to the details that go into creating a great user experience.

Including Accessibility in Your Testing

With numerous disabilities come numerous assistive technologies; from screen readers to modified keyboards, accessing a website through these various methods is going to create a different user experience for each person.

When one front-end developer points out that testing your website with every assistive technology would be the equivalent to testing your product with every device, browser, and operating system, we can relate to this manual tediousness at CrossBrowserTesting and don’t recommend going to this extent.

However, as we’ve discussed, there are many simple fixes, new methods, and tools that you can implement into your website to help your site design be more universal, while also making your team into better developers and your product of higher quality.

Which companies have you noticed are making strides in accessibility? Tell us about them in the comments!

Talking Transformative Culture at Selenium Conference 2017

By Leave a Comment

 

Ashley Hunsberger is a Test Automation Architect at Blackboard, a virtual learning environment and course management system for top institutions worldwide.

Her Selenium Conference 2017 presentation, “Transformative Culture” reviewed how Blackboard established departmental goals, built teams that would ensure quality and success, and slashed execution times, while transforming the way the company thinks about software quality.

Not only was this presentation a favorite among conference attendees, it also serves as highly valuable information for any company that’s undergoing a culture change.

Ashley Hunsberger Transformative Culture at Selenium Conference 2017

Ashley Hunsberger at Selenium Conference 2017

A Cause for Change

A year ago, it took an hour to run Blackboard’s 400 tests, and 370 were unreliable. So, not only was the time to execute high, but the builds were constantly failing and developers had stopped caring about them.

Hunsberger quickly realized that the root of the issues they were having centered around culture and the way different departments thought about quality and communicated with each other to deploy projects.

She wanted to make a company-wide change that would enable the development team to own testing and quality and hoped to get the entire organization to put more care into test suites and maintenance.

The very first step to transform the department was a simple one. They would not longer be referred to as QA, but instead Engineering Productivity.

Hunsberger also wanted to re-establish the department mission to “Reduce the time from concept to deliverable by providing our product development teams with the tools, practices, and support to increase their productivity while maintaining high-quality standards.”

She also wanted to clarify that Engineering Productivity would not take over writing tests for other teams, but instead be a resource to support the automation strategy.

The next move was to set goals including:

  1. Provide an easily maintainable and extensible framework that would enable scrum teams to add and remove tests.
  2. Enable the automatic and early detection of failures within the software under development.
  3. Prevent the source of detected failures from moving any further downstream.
  4. Accommodate all of this without impacting the engineer’s time.

Enter, Team Shangri-la

After realizing this transformation would only be possible with a proper leadership team to own the automation strategy, Hunsberger introduced Team Shangri-la, where she acted as the project owner alongside a scrum master, SETs, a feature engineer, and a CI/CD team member.

Team Shangri-la had to first establish their definition of “Done”, as Hunsberger found that in the past, a lot of teams were saying projects were done without them actually being testing, reviewed, documented, and released.

They also had to outline test suite definitions to get everyone speaking the same language:

  • Goals – What was the intent for each suite?
  • Trigger – What would trigger tests?
  • Gates – What happens if tests fail?
  • Requirements – What are the requirements for each suite?

Once the guidelines were determined, they had to work on containerizing environments for faster feedback and implementing project guardrails to provide support for nine different scrum teams.

Additionally, one prominent area of Shangri-la’s strategy was risk analysis, where they aimed to prioritize what tests would be executed and how they would be written.

By rating the likelihood of a bug occurring and what the impact on customers would be if the feature didn’t work, it became easier to evaluate and what areas need to be included in the test suite and which did not.

Charting and tracking the results also helped the team decide what kind of testing needed to be executed, as well as how the tests would be monitored and maintained.

Transformative Results

Hunsberger and her teams saw the 33 stable tests and 370 unreliable tests that ran in an hour turn on its head to now run 165 stable tests in 30 minutes.

Along the way, Hunsberger learned that not everyone has the same idea about what’s critical, and you can’t test everything. These small realizations ultimately initiated a complete culture change that encouraged them to be better communicators so that they could establish goals and meet them.

By focusing departments to be a company-wide effort, Hunsberger was able to affect better testing to support development, optimize testing, and ensure uncompromised quality across Blackboard’s projects.