Tag: engineers

  • How Much QA is Enough in Software Development?

    How Much QA is Enough in Software Development?

    People working in quality assurance as testers, managers or engineers know what it’s like having to justify their existence; it’s been part of the job for many years. QA experts have had to fight the perception that what they do is a bottleneck, overkill and it slows everyone down.

    Finally, however, QA is getting the attention that it deserves. Companies are gradually investing more in QA skills and tools. This began with the onset of Agile and DevOps—methodologies which have now infiltrated mainstream software development practices everywhere. Since those practices focus on speed, efficiency and quality, engineering leaders have grown to understand that great products are not achievable without adequate QA checks and balances. Another risk is the unflinching nature of high user expectations: Thanks to social media, one user complaint can quickly escalate into others across the web, creating an uncomfortable perception problem for the software provider.

    Robust testing practices can prevent egregious flaws in the software that result in poor user experience and performance—or, worse, a breach. True, testing can sometimes get in the way of speed. Yet no matter how fast you release a product, if it doesn’t work well, no one’s going to buy it, much less use it.

    Nevertheless, we can continually improve the QA practice to fit into modern development teams’ workflow. Testers need to work with developers and master automated testing, while developers need to sometimes engage in testing; everyone should think about the appropriate level and amount of testing. You can have too much of a good thing.

    The Right QA Balance

    The below ideas can help your organization reduce conflict between QA aficionados and those who would rather code and release as fast as possible.

    1: Assess, analyze and report. Developers and testers alike are highly technical; they like numbers. Therefore, the more that the QA team can quantify the risk of an application, provide evidence as to the effectiveness of current QA practices and use metrics to show the need for more QA resources when warranted, the faster that everyone will get on board.

    There are plenty of tools that can deliver common quality metrics such as total number of defects, defect leakage, test coverage, test pass/fail rates, test completion rates, code coverage and application uptime. It’s important to share and discuss these metrics throughout the development team and with product and business managers. What constitutes high quality for the development team may not be the case with executives who are closer to the end user/customer.

    2: The gut check. After metrics, take into consideration the comfort level of your team and company concerning product flaws. In regulated spaces, or for applications that collect sensitive private data, the tolerance for bad code and security gaps is usually low. Gather feedback from different perspectives and roles in the organization for a balanced perspective on the QA practice and areas for improvement.

    3: Get people involved. Quality assurance is no longer a separate activity from development; especially when you are practicing Agile and DevOps, the responsibility for quality is shared. Therefore, developers, business analysts and operations managers all should be doing their work with an eye to quality, delivering feedback regularly to the QA team. Provide opportunities and incentives for any team member to attend events and training related to software quality.

    4: Streamline testing. Test automation tools are helping product teams be more comprehensive in testing, by automating low-risk test cases so that testers can focus their exploratory and manual methods on high-risk or new features. This is a positive development, although testers must take time to learn how to use the tools. Some other ways that can help teams be more efficient in testing include:

    • Conducting more testing early in the sprint. This avoids the 11th hour disaster of finding a major flaw right before the release deadline.
    • Per Agile methods, dividing development tasks into smaller chunks with team members from different disciplines to ensure testing is being done all the time and with visibility by all.
    • Using test driven development (TDD) or behavioral driven development (BDD), which requires that QA, developers and business stakeholders meet at the beginning of a project to agree upon requirements and test cases. Developers then write code against the test, until it passes. New tools are helping bridge the gap by writing requirements and user stories in plain English.
    • Outsourcing part of the testing load during a major project, which can help increase coverage and reduce stress on your team. However, understand that too much outsourcing will undermine any efforts to develop QA as an internal best practice and “mindset” for software teams.

    If your team is committed to QA as a best practice, not an afterthought, those at the top will need to invest properly in the right tools, training and people to get results. Misconceptions about QA still exist; contrary to the view of some DevOps experts, we can’t (and shouldn’t) automate every test. As well, even though developers are now testing the code they write, you still need experienced testers on your team. With the pace of innovation and the high stakes in the marketplace, organizations need more—not fewer—people engaged in testing.

    For testers who love their job, as many of them do, it’s an exciting time to be in the field. Companies increasingly are seeing the value of QA and testers continually are gaining more tools and tactics to excel at helping their organizations produce really great software.

    About the Author / Kyle McMeekin

    Kyle McMeekin is Senior Sales Engineer at QASymphony. Prior to QASymphony, he was a programmer analyst at Cognizant Technology Solutions. Connect with him on LinkedIn.

  • Building DevOps Careers: One Man’s Journey, Part 2

    Building DevOps Careers: One Man’s Journey, Part 2

    In Part One of this two-part series, we introduced former SlideShare and LinkedIn software engineer Sylvain Kalache, who shared his career growth within the two companies. In this second part, we’ll look at San Francisco-based The Holberton School of Software Engineering, which Kalache co-founded to better prepare students to work in a DevOps world.

    School Founder, Still a Coder

    Kalache still uses much the same coding skills in his new role as he did as an engineer. “I still manage machines, the ones that host our website and intranet and the iMacs that students use,” he says.

    The Holberton School of Software Engineering founders removed every manual step possible, using software to automate the admissions process and any process that they could. Even in the classroom, automation rules: Computers automatically review student work on projects.

    “Computers test that students’ code works as expected by simulating user interaction, checking syntax and assessing how fast the code executes. For infrastructure in code, computers check for stability, response times and security breaches. By using multiple ratings parameters that are linked to specific skills, the computers collect detailed data about the strengths and weaknesses of each student,” says Kalache.

    “We have a lot of our own secret sauce in software automation running the school for us,” he adds. “This requires all the technical skills I used in my coding days including designing, building, configuring, testing, deploying and maintaining software and systems.”

    Teaching Methods

    The Holberton School of Software Engineering engages students in building each skill they will need for careers in software engineering through use of industry-standard teaching methods. “Methods include deep learning in building features into software products and classical teaching in clear, documented code,” Kalache says. “We have a team of 150-plus mentors who make sure our curriculum is up to date and in sync with what the industry actually does and who coach and share their knowledge with students.”

    The Holberton School of Software Engineering uses fully practical methods with no formal teachers or lectures, only mentors. “Mentors are like managers in a workplace. I mentor, coaching students in their learning journey and giving advice when there are issues,” he says.

    Students engage in peer learning, working collaboratively on software projects, which encompass the skills they will need to demonstrate in their careers. Successful completion of projects, including solo projects, is proof of attaining the required skills. “Students must defend their projects before mentors with mentors ensuring that every student can present and explain the technical aspects of the project; if even one student can’t explain it, then the group fails on that project,” says Kalache.

    “We teach problem-solving and how to learn new skills because there will constantly be new technologies and concepts for our students to understand and master in their careers in the tech world,” he adds. “Professionals who cannot adapt and retrain themselves will quickly fall out of date with technology.”

    Readying Students for Careers from Day One

    The Holberton School of Software Engineering prepares students to be ready to work when they start their careers. “Graduates of other programs whom I have spoken with have no idea what it is to ship code to production and run a production environment. They are used to academic projects that teachers correct for them,” Kalache says. “That is not how it works in the industry.

    “Even boot camps and universities provide minimal practical experience that will make job hunting difficult,” he continues. Smaller organizations don’t have the money to pay someone to learn before starting them working in production. Thus, he says, startups need to execute fast using professionals with mature skills. “Though our students will fail and struggle, they will do it at the school, which will have a much smaller impact than doing it on the job,” says Kalache. Students are exposed to creating, shipping and working with code in production for two years before graduation.

    What’s more, real, workday DevOps requires effective communications skills. “Whether it is to introduce the last tool you built, explain what happened during an outage or convince your managers that your solution to a problem is the right one, you need to have oral and written communications skills,” says Kalache. As such, the school runs students through a series of exercises in public speaking, technical writing and documentation, as well as post-mortem communications when dissecting an outage, prepping them even further for their careers and the world beyond the classroom.

  • Building DevOps Careers: One Man’s Journey, Part 1

    Building DevOps Careers: One Man’s Journey, Part 1

    In 2011, Sylvain Kalache was a software engineer at SlideShare, which LinkedIn acquired in 2012. Kalache was a senior systems reliability engineer (SRE) at LinkedIn, doing project management and planning, documenting and sharing knowledge tools, and adapting himself and his work to the LinkedIn organization and its technology.

    Today, Kalache is helping build DevOps careers as co-founder of Holberton School of Software Engineering in San Francisco, where students learn to code through “project-based and peer learning,” according to information from the Holberton School website.

    This is Kalache’s DevOps career story, how he worked in and then transitioned from a career in DevOps to a personal and professional investment in helping students to build their DevOps talents toward a lifetime of coding and contribution in software engineering and, hopefully, successful careers.

    Software Engineering at SlideShare

    “SlideShare was a very small company when I joined. The San Francisco office had only 10 people; I was only the second engineer at that location,” says Kalache. But the DevOps mindset was strong there, he says, and the company had bet everything on DevOps methodologies. In fact, it was the commitment to DevOps by SlideShare and its CTO at the time, Jon Boutelle, from which Kalache learned of the development approach and took to it so quickly.

    “Boutelle was looking for full-stack or aspiring full-stack engineers and I was a junior programmer and eager to learn. In a small company like that where you are encouraged to work on every aspect of the product life cycle, it became very clear that I was in charge of taking care of my mistakes,” says Kalache, adding SlideShare expected him to take ownership of his code from design to production.

    “Because I was eventually in charge of a lot that was going on with the infrastructure at SlideShare, I had to build and maintain a lot of systems that were serving billions of slide views per month at what was one of the top 100 most visited websites in the world,” says Kalache.

    People from the Dev and Ops teams there did not only their own work, but also the work of their companion team. In essence, Dev was both Dev and Ops and, likewise, Ops was both Ops and Dev.

    “The SlideShare people were writing their own configuration management code, setting up monitoring of new services and features as they built them, deploying their own code, and troubleshooting code in the production environment,” says Kalache. Ops people helped developers design sound code for acceleration while also giving their code a second look to ensure fitness for operations.

    Project Skynet

    “The most exciting project I built for SlideShare was Skynet, an automated tool to monitor, scale and auto-heal a system in the cloud,” says Kalache. Skynet was developed to meet several challenges in the day-to-day work of simply being SlideShare and doing what SlideShare does. SlideShare acted on, renamed and translated countless files from one type to another to share them on the site. As with other slide technologies, the tool was a fit for teaching and presentations.

    There was no way to know exactly how much users would upload, access or view any slide content at a given time. “There were peaks and valleys in upload traffic with mornings seeing high traffic and low volumes in the evening and on weekends. The SlideShare infrastructure had to scale quickly to encompass and convert common document files at speed. This required adding many hundreds of machines to the infrastructure,” says Kalache, which were virtual  machines that spun up in minutes in the AWS EC2.

    One purpose of Skynet was to enable precise analysis of log files for transparency into everything from individual file conversions to changes in the entire machine cluster as the environment scaled up or down. The other purpose of Skynet was to use the analyses to auto-heal; in other words, to restore the cluster back to its initial size once the peaks were over.

    With many thousands more employees at LinkedIn than at SlideShare, Kalache left many of his duties at SlideShare to others while he dove much more acutely into specific aspects of his work.

    Co-Founding a School That Builds Careers

    In speaking with his colleagues and representatives from various enterprises, Kalache continually confirmed that organizations using DevOps are in need of lots of engineers but they can’t find candidates who are knowledgeable and experienced. “I was actually recruiting for SlideShare and for LinkedIn. What saddened me was to see a graduate who had just spent half a decade and a lot of money on a master’s degree only to be far from employable,” he says.

    Kalache found it hard to find people who knew basic software engineering, DevOps, and how to be an SRE for LinkedIn. “We instead had to hire early graduates who had coding skills and an interest in operations and train them on being an SRE,” he says.

    Kalache decided to combine an awareness of alternative teaching methods with his passion for the coding and ops communities to find a solution to how to better prepare software engineers for careers. “After mulling it over for two years, I decided to quit my job at LinkedIn and create the Holberton School,” says Kalache.

    In Part Two, we dive headlong into the teaching and learning experiences at the Holberton School of Software Engineering to help students learn and understand the DevOps methodologies and increase their chances for success in their respective careers.

  • 3 Skills Developers Should Master in 2016

    3 Skills Developers Should Master in 2016

    The era of mobile and web is upon us, which has caused nearly every business decision-maker to ask the question, Is now the time to hire a developer to build our app or website? In 2016, businesses are going to be looking for the best developers to join their team and help scale their business. We’ve already started to see this trend, as a recent Harvey Nash Technology Survey 2016 found that developers are the most sought-after of all technology personnel.

    To stand out from the pack, developers must master the critical skills businesses are looking for. The most valuable developers will be those who can adapt to the changing technology landscape and further hone their craft to help companies scale and solve specific business challenges.

    To stay competitive in today’s market, developers need to invest in these three skills to be relevant in 2016 and beyond.

    Master the Skills to Scale a Product or Service

    Startups increasingly are evolving from early stage concepts to building a growth model to take their business to the next level. To be an asset today, developers need to master and specialize in scaling technologies that are key for businesses looking to expand their customer base and focus on technological innovation.

    There is a demand for developers that have not only a breadth of experience in bringing an organization up to scale but also depth in their technical skill set. Having the ability to work on major systems, support large amounts of traffic and customers and maintain the system for several years are critical competencies that companies will be looking for.

    Also, having a data model or database experience is very important—NoSQL solutions such as Cassandra, CouchDB or Riak, as well as traditional data sources such as MySQL, are in high demand. Middleware languages such as Java and Golang also are an important part of a developer skill set when building services and APIs.

    Understand the Customer Perspective

    When building a technology solution, an engineer must be able to look at the product from a customer’s perspective to understand what problem the product is fixing. While technical skills in developing a product and user experience (UX) are very important, the ability for a developer to understand and create a product that solves a customer challenge far outweighs the focus on building the most elegant software.

    Engineers who are able to demonstrate project management skills and have experience around scaling infrastructure and ensuring the platform is robust will be in high demand. Businesses increasingly are seeing a need to support growing customer bases and traffic with utmost end-user reliability.

    Become a Subject Matter Expert

    There is a gradual shift in the developer community, in which engineers are focusing on specializations and becoming subject matter experts. There is an opportunity for developers to create career highlights by merging their talent and passion with opportunities.

    Developers are encouraged to identify an area they are passionate about and focus on refining those skills. By being able to find these opportunities that build on their passion, these developers can demonstrate they are able to solve a challenging problem for a large number of users—a competitive skill in high demand across the industry.

    The overarching strategy of a successful developer career is to invest in learning how to scale a product or service, understanding the customer perspective and becoming a subject matter expert. Investing in your skills as a developer in 2016 can lead to a longer, more fulfilling career.

    About the Author/Sha Ma

    Sha Ma_SendGridSha Ma is the senior director, Software Engineering at SendGrid. She led development teams at both startups and Fortune 500 companies prior to joining SendGrid. In her current role, she drives strategic planning, development and management of large scale projects. Ma is a graduate of MIT where she earned both her bachelor’s and master’s degrees.