Every once in a while I read something like this:
Yeah, [TDD|BDD|ATDD] is great. But how do you convince [your manager|your employer|your colleagues] to get the time to do it?
In the past week I decided that I need something to point folks to when this questions comes up again. So, here it is.
First of all, I think it helps to apply a lesson that I learned years ago as a swimming trainer. I had several exercises in my repertoire that were a bit unusual, and at times hard to do. These included variations of swimming strokes in unusual positions.
Every now and then when I gave out one of the exercises to the kids, some or all of them were complaining: “this doesn’t work”, “I can’t swim like that”, etc.
What the kids didn’t know was that I had learned to try out these exercises on my own first to get a grasp of how difficult they were. Thereby I also knew that they were possible to do. Over time, I realized that “this doesn’t work” could be easily translated to “I don’t know how I can make this work”, and tada, let me see how I can help you with that.
Today, I apply the same lesson to TDD. Whenever someone tells me that TDD does not work in his code base, well, I make the mental translation to “I don’t know how TDD works on my code base”, and off we go.My boss won’t let me
Yeah, right. Here’s a hard message for you: are you telling your carpenter how to hold his hammer? Are you telling your plumber how to use the pipe wrench? Are you telling your car mechanic when to replace the oil filter?
Seriously, why is your boss, your project manager or whatever excuse you have not use TDD telling you how to do your job? I thought you are a highly educated knowledge worker. If you are convinced about the effectiveness of TDD, then no boss or project manager should be telling you how to do your job.
Oh, sorry, there actually is one case when this might be appropriate for your boss to tell you. When you are not able to deliver working software that adheres to the business goals using TDD.
But remember: that’s feedback about how you use TDD, not about how bad your boss or project manager may be. So, better practice applying TDD and helpful design practices to be able to better serve the projects you are working on.TDD does not work with my [language|framework|etc.]
Sure. That’s an easy excuse. Yeah, those darn language or framework programmers weren’t helpful. That’s how it’s going to work.
Uhm, wait a minute. What do you think how old TDD actually is? A thing from the Smalltalk community? It turns out, not quite right.
A while ago, Arialdo Martini wrote a blog entry on how old TDD actually is. Click that link, go there. Make sure, to read it up until the end. I’ll wait here with my rant.
Surprised? So was I – to some extent. Besides the fact that things like TDD have been mentioned in papers and publication by Dijkstra, and the first NATO conferences, TDD actually is way older than that.
Also note what Jerry Weinberg says in this interview with Michael Bolton about TDD:
Michael: [...] I’ve learned about both from conversations that I’ve had with you and other smart people. I remember once that Joshua Kerievsky asked you about why and how you tested in the old days—and I remember you telling Josh that you were compelled to test because the equipment was so unreliable. Computers don’t break down as they used to, so what’s the motivation for unit testing and test-first programming today?
Jerry: We didn’t call those things by those names back then, but if you look at my first book (Computer Programming Fundamentals, Leeds & Weinberg, first edition 1961 —MB) and many others since, you’ll see that was always the way we thought was the only logical way to do things. I learned it from Bernie Dimsdale, who learned it from von Neumann.
When I started in computing, I had nobody to teach me programming, so I read the manuals and taught myself. I thought I was pretty good, then I ran into Bernie (in 1957), who showed me how the really smart people did things. My ego was a bit shocked at first, but then I figured out that if von Neumann did things this way, I should.
John von Neumann was a lot smarter than I’ll ever be, or than most people will ever be, but all that means is that we should learn from him.[...]
So, the next time your boss approaches you asking to leave out those unit tests or stop that TDD thing, tell them the story on how Jerry Weinberg learned it from Bernie Dimsdale who learned it from John von Neumann. Then ask them that you don’t consider yourself smarter than John von Neumann.
Oh, and besides, even though some of our hardware became more reliable, most of our software hasn’t. When answering the question why we ever gave up something that John von Neumann taught us, I wouldn’t accept that excuse either.What if all of that doesn’t work?
A couple of years back, I attended a Code Retreat session in Bielefeld. We worked all day using TDD, in six consecutive sessions, always deleting our code at the end, since we strived to learn about TDD, not to come up with a beautiful solution to a long solved problem.
At the end of the day, we held a quick retrospective. Everyone shared what they learned that day, and what they would be doing differently back at work next Monday. One guy stepped forward and said that he would change jobs on Monday since he never would be able to use TDD at his current job. Now, after he experienced it, he never wanted to do anything else.
That said, of course the “change your organization or change your organization” phrase also applies to TDD. If you are convinced about the approach, and never want to do anything else, and your environment currently doesn’t support it, well, move ahead.
In case you want to learn more, attend one of the events for the Global Day of Code Retreat in two weeks. Since I always learn one little thing at each of these events, I will be attending the one in Bielefeld, Germany.
There’s always one day out of the year the uTest Community Management team can count on to dress up and look pretty ridiculous. Leave it to Halloween.
Yesterday, as part of each department of Applause’s goal of an individual costume theme, the uTest Community Management team went ‘Under the Sea.’ Enjoy some of the hilarity — and general unsettling nature of — yesterday’s office Halloween antics.
Happy Halloween.Click to view slideshow.
There’s growing research that suggests that sitting down all day is bad for you so in a bid to live longer and see my sons growing up I’ve started using a standup desk at work. A few others here at NewVoiceMedia are also using standing desks. I also thought I’d have a go at building a standing … Read More →
We have been covering code for over a decade. During that time, we have learned a lot from our customers on how to make the most out of implementing meaningful code coverage to teams. We thought it may help if we put together some of the highlights we have learned about the best practices of .NET code coverage and share them with you.
This webinar outlines four categories of best practices, with examples, to guide development efforts and improve overall code quality. The first category focuses on code coverage metrics and the three we rely on in our own organization. The second category outlines how code coverage best practices can be employed as a team. The third category reviews techniques for effectively capturing code coverage data. The fourth, and final category, relates specifically to NCover and how to keep your system optimized.This webinar outlines four categories of best practices, with examples, to guide development efforts and improve overall code quality. Previously recorded and available for immediate viewing.
It’s 4 days until the Melbourne Cup, a horse race that literally stops a nation. It’s the single biggest betting event in the sporting year, and a huge percentage of the population will have a little wager. What’s the easiest way to place that bet? Online… So I thought I’d run some tests on the […]
The post Form guide – which betting agency website will win the Melbourne Cup? appeared first on Dynatrace APM Blog.
Peter Kim has been in the information security industry for the last 10 years and has been a penetration tester for the last seven. He is the author of the best-selling computer hacking book, ‘The Hacker Playbook: Practical Guide to Penetration Testing.’ He was the lead penetration tester for the U.S. Treasury and Financial Management Systems.
In addition, he was a penetration tester for multiple utility companies, Fortune 1000 entertainment companies, government agencies, and the Federal Reserve. He also gives back to the security community by teaching penetration testing courses at a community college, and creating and maintaining one of the largest security communities in the Santa Monica, CA area. He has also spoken at multiple security conferences. You can find him at his blog Secure Planet.
In this Q&A, uTest spoke with Peter about some of the more memorable vulnerabilities he has come across while hacking web apps, what he thinks of Apple Pay, and why his book is used in college coursework. Stay tuned at the end of the interview for a chapter excerpt from ‘The Hacker Playbook,’ currently the number one-selling software testing book on Amazon.
uTest: You’ve been in security and pen testing for a while now. Without giving out too many specifics, what was one of the more surprising or memorable lapses in judgment you have come across while ethically hacking web applications?
Peter Kim: I could write a book just on this question. I mean, I’ve seen it all, from a single company having 20+ different SQLi vulnerable public web applications, default credentials into their whole camera system, PII data leaks from major e-commerce sites, all the way to having access into equipment that controlled certain types of SCADA utility networks.
The funniest one I came across was about five years ago. A major AV vendor had all their clients talking back to their central web application over HTTP APIs. Sniffing the traffic, I was able to gain the administrative credentials in clear text from a client. Once I logged into the web application, I was able to modify the update agents within the web interface to force the end user to download a malicious file and execute them on the host systems.
We all had a good laugh, because what was meant to protect the network allowed us to compromise the network, and, ironically, the companies that advocated security had one of the worst IT security practices.
uTest: With all of the data breaches in the news, are organizations not investing enough money in their security strategies, or are they just not investing enough in the right security strategies/programs such as extensive penetration testing?
PK: This is a tough question to answer. I think everyone is looking for the golden egg answer, but it’s much more complex than that.
What I’ve been seeing as the problem is that corporations are becoming tool-dependent. We have host/network-based monitoring, antivirus, malware detection, vulnerability scanners, managed services, application filters, email proxies, and web proxies. Yet, our users are still getting infected with malware, clicking on spear phishing emails, and aren’t able to detect and stop C2 traffic properly.
People focus too much on words like APT, zero-day, PCI, and checkboxes. I’ve worked with security teams where the analysts spent most of their type fighting adware and junk. This isn’t where we should be today, and we should have our analysts focused on identifying anomalies and locking down networks.
With the recent large breaches, like on those Point of Sales (PoS) devices, those networks and systems were only designed for a single purpose. Time should have really been spent detecting any anomalies and alerting on any changes on those systems. If systems are specifically made to do XYZ, it should be very easy to identify and alert when a system decides to anything suspicious.
I also believe we are still failing at user education. This isn’t just the responsibility of the security department, but it should be everyone’s job to be part of the solution. Users need to be able to identify malicious attacks, know how to report these incidents easily, and to stop clicking on malicious email links.
uTest: Do you think programs like Apple Pay are going to be a savior for a retail industry that has been so hard hit with breaches at Home Depot, Kmart and Target, amongst others?
PK: The great thing about hacking is that it’s always about doing what they say is impossible. With that said, what Apple is doing with things like Apple Pay, is in the right direction. By removing the need for third-party credit card number storage, requiring multiple factors of authentication, and not having to hand your credit card to a random stranger for purchases (like at restaurants, grocery stores, and gas stations), it provides many different additional layers of security for the end user.
Just remember that the bad guys adapt just as quickly, if not quicker, than the good guys. So if credit card cloning becomes hard, what about spoofing NFC, what about attacking jailbroken devices with financial-purposed malware, or attacking iTunes accounts associated with your credit cards?
It also really comes down to adoption. With Google going in one direction with payments and Apple going in another, without mass adoption, we might not see the full potential benefits of these systems.
uTest: You’ve mentioned that your book ‘The Hacker Playbook’ has been used as core university materials in some colleges. Could you tell us a bit about which programs it is used in, and where it fits in with the curriculum as an educational resource?
PK: Although the book wasn’t originally developed to be used as college resource, it seems to have ended up aligning with many different undergrad and graduate programs.
Graduate courses like “Advanced Topics – Penetration testing forensics” at George Mason University have incorporated it as the core book for their course. In addition to being added to multiple U.S. universities, it has also been incorporated in multiple universities in other countries (Sheffield Hallam University, Asian Institute of Technology, and Algonquin College). The great part about security is that it isn’t language/culture-bound. Attacks in one country are just as prevalent in another country.
I see this book as a good fit in the advanced network security courses. Whether it is forensics, incident response, or penetration testing, this book gives students a real-world view in what both professionals and unethical hackers are doing. Being able to understand and replicate these attacks allows students to prepare for the types of attacks they’ll encounter in their professional career.
uTest: The book doesn’t read like an encyclopedia – it’s a story walking a tester through the entire penetration testing process from network layer to Web application layer. Could you describe why you laid the book out the way you did, and whether it’s designed for the security rookie or a seasoned veteran?
PK: I’ve read a ton of different security books and they were always laid out by tool or by protocol. I never really came across a book that walked me through an actual penetration test. The other thing I didn’t see too often was a book breaking out of the norm by trying to incorporate and push creative attacks that might not have been fully polished. This allows the reader to continue his/her research and progress their own skills.
The layout was also developed based on needs I’ve had when performing my own penetration tests. Many times, I’ve gotten stuck at a particular point during a test. For example, I might have compromised a host as a regular domain user, but wasn’t able to get that domain admin account. I just pop open ‘The Hacker Playbook’ and skip to “The Lateral Pass” section, and review all of the different options I have. Other times, I get caught up by a certain AV vendor and turn to the “Quarterback Sneak” section and bypass AV.
As the book was originally written as a collection of my lifetime of notes and tips, it’s not targeted for those without any experience. Those that benefit the most are the ones that have played around with Metasploit and Meterpreter. The most surprising part was that a lot of senior penetration testers have come back to me and said that they were really surprised to have learned a bunch of new things from my book. That alone makes it all worth it.
Hunched over your keyboard in your dimly lit room, frustrated, possibly on one too many energy drinks, you check your phone. As you squint from the glare of the bright LCD screen, you barely make out the time to be 3:00 a.m. “Great”, you think to yourself. You have 5 more hours before your test is over and you haven’t found a single exploit or critical vulnerability. Your scans were not fruitful and no one’s going to accept a report with a bunch of Secure Flag cookie issues.
You need that Hail Mary pass, so you pick up The Hacker Playbook and open to the section called “The Throw – Manual Web Application Findings.” Scanning through, you see that you’ve missed testing the cookies for SQL injection attacks. You think, “This is something that a simple web scanner would miss.” You kick off SQLMap using the cookie switch and run it. A couple of minutes later, your screen starts to violently scroll and stops at:
Web server operating system: Windows 2008
web application technology: ASP.net, Microsoft IIS 7.5
back and DBMS: Microsoft SQL Server 2008
Perfect. You use SQLMap to drop into a command shell, but sadly realize that you do not have administrative privileges. “What would be the next logical step…? I wish I had some post-exploitation tricks up my sleeve”, you think to yourself. Then you remember that this book could help with that. You open to the section “The Lateral Pass – Moving through the Network” and read up and down. There are so many different options here, but let’s see if this host is connected to the domain and if they used Group Policy Preferences to set Local Administrators.
Taking advantage of the IEX Power Shell command, you force the server to download Power Sploit’s GPP script, execute it, and store the results to a file. Looks like it worked without triggering Anti-Virus! You read the contents of the file that the script exported and lo and behold, the local administrative password.
The rest is history… you spawn a Meterpreter shell with the admin privileges, pivot through that host, and use SMBexec to pull all the user hashes from the Domain Controller.
When I started looking into Nginx, I was very impressed by the high performance of this lightweight HTTP server. But more and more I’ve become keen on the ease of its configuration. I have successfully used Nginx for serving PHP applications for quite a while, this article is about the lessons I have learned. I’m […]
At some point during your recruitment drive you’ll likely use recruiters. The problem is that some recruiters are creating a bad first impression of your company. Your recruiters are often the first point of contact a potential hire has with your company. Here are some ideas on how to help your recruiters create a great … Read More →
The post How to help your recruiters create a great first impression appeared first on The Social Tester.
Well, another outstanding year of Dynatrace Perform activities has come and gone. In 2014, we touched over 3,000 customers with Perform events! As the head of the customer success organization, one of the most exciting moments for me was our public announcement of Dynatrace’ Net Promoter Score―an amazing 89%! Compuware has a long history in […]
Thanks to everyone who participated in the “Managing Automotive ISO 26262 Compliance with Seapine TestTrack” webinar. The webinar recording is now available if you weren’t able to attend or if you would like to watch it again.Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon
I believe we need a lot more examples of software testing. They will be key in transferring tacit knowledge (they will not be all that is required, but an important part.) They work best when done live, so you can discuss, but that doesn’t scale very well.
So I have created a few examples in video or text format:
Exploratory Testing Session – Spotify Offline
Scenario Testing – LibreOffice Compatibility
Test Analysis – Screen Pluck
I am very interested in knowing if they are useful to you, and how.
Which other public testing examples are your favorites?
STARWEST presenter Robert Sabourin – a 30+ year veteran and well-respected member of the software development community – took that nugget of conventional wisdom and put his own unique tech spin on it in his course on Testing Lessons Learned from Sesame Street.
While the topic was fun and lighthearted, Rob took his subject matter seriously and impressed on attendees just how important it is to learn and master the basics. But what are “the basics”?
Let’s take a closer look at what you really need to know to build a solid software testing foundation.
Rob’s presentation focused on two main areas of professional – and personal! – development: cognitive skills and social skills. Developing your cognitive skills allows you to think more analytically, to develop efficient models and lay out precise explanations for your processes and reasoning. Strong social skills elevate your ability to collaborate to a whole new level of effectiveness and can help grow your reputation as a thought-leader.
Think of your team as a “neighborhood.” To be successful, people take on many diverse roles which require them to focus on various short-term goals. You may all be working toward the same end goal, but to get there, you’ll have to be sensitive to diversity and understand how successfully navigating it can enhance the overall quality of the end product.
Much as John F. Kennedy asked in his 1961 inaugural presidential address, “ask not what your country can do for you; ask what you can do for your country,” Rob Sabourin encourages testers to ask themselves and their teams:
Ask not what the system can do for the user; ask what your user does with the system.
Testers often find themselves in the position of defending their work, proving the whats and whys and hows. We can learn a lot from Big Bird and his struggle to help justify the existence of his imaginary friend Mr. Snuffleupagus. How did Big Bird prove he was real? Garnering and presenting proof of his friend’s existence parallels a tester’s role in reporting an issue found while testing a product. It requires persistence, evidence, and continuing advocacy for the bug.
Oscar the Grouch – while seen negatively by many – can actually be a great role model for software testers! Oscar thrives in a messy environment, where there’s plenty of “trash” (bugs!) and he excels at breaking things (knowledge of inducing failure modes). Oscar’s goal is to travel the unhappy path since that’s where he can best employ his talents in disrupting the flow, similar to how a great tester will learn to step outside the comfort of the happy path, dig deep and think creatively to uncover valuable issues.
And, of course, there’s Kermit the Frog. We can’t forget him! Like a good bug-hunter, Kermit is the ultimate reporter; he knows how to observe, blend in, gather facts, and report them in a factual (non-emotional) way. One of the biggest lessons we can learn from Kermit is that “it’s not easy being green,” where “green” is synonymous with the progressive, persistent investigation that makes excellent testers so valuable.
Kudos to Rob Sabourin on creating and delivering an excellent – and enjoyably creative – STARWEST 2014 session presentation!
Want to see the full slide deck from Rob’s presentation? Check it out on the uTest forums here, then answer our poll asking which Sesame Street character you best identify with and chat with other testers about it!