Compared to traditional functional testing, security testing requires testers to develop the mindset of real attackers and pro-actively look for security vulnerabilities throughout the software development lifecycle. Using live demos, Frank Kim shows you how to think-and act-like a hacker. Rather than just talking about issues such as Cross Site Scripting (XSS), SQL Injection, and Cross Site Request Forgery (CSRF), Frank shows-live and in color-how hackers abuse potentially devastating defects by finding and exploiting vulnerabilities in a live web application. Find out how attackers approach the problem of gaining unauthorized access to systems. Discover the tools hackers have that you don't even know exist and how you can find critical security defects in your production apps. In this revealing session, you'll learn how to become a better tester and find serious security vulnerabilities in your systems before the bad guys do.
DevOps is an increasingly popular development approach focused on ensuring that delivered code is immediately stable and works as expected. DevOps team members must be multi-skilled and are expected to perform all the activities of development, testing, and SysAdmin tasks. Manoj Narayanan shares how to implement testing using DevOps tenets and how it differs from its more popular cousin, agile development. To work productively with developers and SysAdmins, testers must develop knowledge of development and design principles, programming languages, and continuous integration. Manoj explores the critical role that functional and regression test automation plays in enabling testing organizations to be more productive. Manoj concludes with an analysis of the cultural impact DevOps has on the testing organization and its interaction with other critical stakeholders-business, developers, operations, and customers.
By next year, 90 percent of large enterprises will include open-source software as business critical elements of their IT portfolios. However, most software development organizations have limited capability to govern the process of selecting, managing, and distributing open-source components-leaving them exposed to unforeseen technical and compliance risks. Larry Roshfeld examines how open-source components-and their dependencies-may expose your company to unforeseen and unnecessary vulnerabilities. He outlines the significant threats to software quality, stability, performance, security, and intellectual property that have occurred using such components. Then, Larry shares an action plan for balancing the risk/reward trade-offs of open-source software in the enterprise. Find out how to ensure that your organization uses only the highest quality open-source components and avoids the common vulnerabilities.
Quality in delivered software is very different from quality in physical goods. You can see it or touch it, except in the code. When classes and methods are cohesive, non-redundant, well-encapsulated, assertive, and explicitly coupled, they are less prone to developer mistakes and far easier to debug, test, and maintain. David Bernstein asserts that paying attention to code quality helps developers focus every day on the key principles, patterns, and practices expert developers use. Even more, if you don’t pay attention to critical code quality attributes, iterative development practices can quickly degrade code into a maintenance nightmare. Join David and your peers to take a deep dive into the code quality attributes that make software more maintainable and less bug friendly. Learn to create software that provides value now and, in addition, is easy to change and extend so it can continue to deliver value far into the future.
The question of how much design to do up-front on a project is an engaging conundrum. Too much design often results in excess complexity and wasted effort. Too little design results in a poor architecture or insufficient system structures which require expensive rework and hurt more in the long run. How can we know the right balance of upfront design work versus emerging design approaches? Alan Shalloway shows how to use design patterns-coupled with the attitude from agile of “don’t build what you don’t need”-to guide your design efforts. The trick is to identify potential design alternatives, analyze how each may affect the system in the future, and then find the simplest approach for isolating those potential affects.
Quality in delivered software is intangible and very different from quality in physical goods. Some external attributes of quality software-free from defects and easy to maintain-are reflections of the code's internal qualities. When classes and methods are cohesive, non-redundant, well-encapsulated, assertive, and explicitly coupled, they are less prone to mistakes and far easier to debug, test, and maintain. David Bernstein asserts that paying attention to code quality helps us focus on the key principles, patterns, and practices used by expert developers. If you don't pay attention to critical code quality attributes, iterative development practices can quickly degrade code into a maintenance nightmare. Join David and your peers to take a deep dive into the code qualities that make software more maintainable and less bug friendly.
The question of how much-or how little-design to do up-front on a project often leads to a conundrum. Too much design often results in overkill engineering that results in extra complexity and wasted effort. Too little design results in insufficient system structures that result in extra complexity and wasted effort. So, how can you determine the right balance for a given application or system? Alan Shalloway offers a proven approach to determine how much design work to do before beginning the code-build steps in a project. Alan has learned that the trick is to discover and ponder what you don’t know, how it may affect you, and then how to isolate these risks in your code in the simplest way possible.
Have you heard any of these from your development staff or said them yourself? "Our software and systems are too fragile." "Technical debt is killing us." "We need more time to refactor." Having quality code is great, but we should understand why it matters and specifically what is important to your situation. Joel Tosi begins by defining and discussing some common code metrics-code complexity, coverage, object distance, afferent/efferent coupling, and cohesion. From there, Joel takes you through an application with poor code metrics and shows how this application would be difficult to enhance and extend in the future. Joel wraps up with a discussion about what metrics are applicable for specific situations such as legacy applications, prototypes, and startups. You'll come away from this class with a better understanding of code metrics and how to apply them pragmatically.
Assaults against digital assets are unquestionably on the rise. If you create applications that handle valuable assets, your code WILL be attacked. In addition to lost revenue and productivity, the consequences of compromised systems can include loss of trust, a tarnished reputation, and legal problems. Much like quality assurance, it’s important to have a holistic approach to security that unifies people, process, and technology. Cassio Goldschmidt introduces defense techniques that measurably reduce the number and severity of software vulnerabilities. These include secure coding techniques, minimizing the use of unsafe functions, use of compiler and linker security options, and specialized static analysis tools. Enrich your development lifecycle with threat modeling, security code review, penetration testing, and vulnerability management.
The question of how much design to do up-front on a project is an engaging one. Too much design often results in overkill, complexity, and wasted work. Too little design results in insufficient system structures that require rework, additional complexity, and wasted effort. How can we know what the right balance is? Alan Shalloway shows how to use the advice from Design Patterns coupled with the attitude of not building what you don't need from Agile. The trick is in discovering what you don't know, how it may affect you, and then how to isolate these risks in your code in a simple manner. Alan describes the essence of emergent design–that is, starting with a simple design and letting it evolve as the requirements evolve. He also demonstrates how to refactor to better designs and how this is different from refactoring bad code.