Tools of the Trade
There are a great number of different tools people use for building websites, but to be frank most of them are nothing more than overpriced bloated nonsense, that does nothing more than teach you how NOT to build websites. So let's go through and explain what works, what doesn't, and what should be avoided at all costs.
Editors
A decent code editor is a must-have, and there are plenty of good and bad choices.
For the most part any flat text editor, or so called "programmers editor" will do the job. I prefer Flo's Notepad2 when working on Windows, since it lets me disable a lot of things that annoy me like tabs (step backwards in editor functionality) and colour syntax highlighting (an illegible acid trip) -- but that's more a personal preference.
Setting aside my personal preferences, here's a short list of Windows editors that do a fine and dandy job.
There are dozens if not hundreds of others. While I don't use other operating systems for development, editors like gEdit (linux), TextWrangler (OSX), and so forth also work just fine.
There are even people who use vi/vim or even emacs -- I consider that crowd a few wrestlers short of a pay-per-view, in an antiquated outdated or even counterintuitive way of doing things; but even so there's nothing wrong with using those if you're comfortable with them.
...and they're all FREE!
On the flip side, pretty much anything with a "preview pane", "WYSIWYG editor", or other visualization built into it is rubbish. Microsoft Web Expression, Dreamweaver, Frontpage, the only thing you can learn from these is how not to build a website.
The most popular of this halfwit bull has to be Dreamweaver; sad since most everything it does 'for you' it does wrong, most every one of it's templates and example codes are filled with laundry lists of how not to do things.
Preview Panes, WYSIWYG Editors,pretty much anything involving
"visual design"
Worst is the WYSIWYG aspect, as the simple fact is with the range of different screen sizes, resolutions, available fonts and font rendering technologies what you see is almost guaranteed to NOT be what the visitor to your site is going to get. There is more to developing a website than the screen you happen to be seated in front of, and the non-semantic non-graceful degrading inaccessible messes vomited up by WYSIWYGS and other "visual design methods" is nothing more than a giant steaming pile of manure.
Another flaw even if you don't use the 'preview' part to plug in content, is that most often they bear no resemblance to how actual browsers behave. Far, FAR too many times I've seen people 'finish' an entire layout, then go "Why doesn't it work in ____ browser?" WHY? You didn't test it in real browsers as you went!!! We'll get to more on that shortly
It's really laughable when programs like Dreamweaver don't even behave like the browser engine they are allegedly using; old versions used to be based on "Presto", the engine that used to be behind Opera - while new versions run webkit, the engine behind Safari and what used to be behind Chrome. You'd never know it, and honestly, that's a problem!
...and don't even get me STARTED about things like "wizards" to generate things like menus for you. Again see Dreamweaver with its idiotic "mm_swap" scripting asshattery; used to perform image swaps when your cursor 'hovers' over an item, they are basically using JavaScript to do CSS' job!
Many such programs also have 'templating systems' built into them that are bad for two reasons - first it delays you from learning to do things properly server-side using languages like ASP or PHP, but worse they quite often introduce rendering bugs due to using things like comments to say where things begin and end. Sad as it is, comments -- yes, the parts browsers are supposed to ignore -- can trip rendering bugs in some versions of IE and FF.
Of course, after being filled with bad advice, bad practices, bad code, and leading people down the garden path to failure, a lot of the companies have the giant pair of brass to charge hundreds of dollars for this garbage! That anyone is dumb enough to shell out money for this trash is akin to fixed fortifications -- a testament to the stupidity of mankind.
Browsers and Testing
When it comes to testing, there is no such thing as a bad browser; even if from a developers standpoint some of them are... well... pretty damned bad. Browsers are free, and at least when it comes to modern choice, there's no excuse not to install all of them you can get native to your computer's operating system.
The problem is not all browsers are available to all OS. Apple stopped making Safari for Windows, there is no IE for Linux or OSX... So what can you do?
The first option kind-of sucks. Go out and buy one computer of each major flavor. You have a windows machine, a Linux machine, and a OSX machine. This is expensive, annoying, and generally it's a waste of time to physically get up and change computers.
The second option is really versatile, "Virtual Machines" - software like Oracle VirtualBox, Microsoft Virtual PC, Parallels Fusion and VMWare can let you boot into another OS in an emulated environment, with a window on the "Host OS" acting as the display of the pretend system. Basically it's like running a whole other 'pretend' computer in a window.
If you're on OSX, this gets pretty simple as you get one of the above, install Windows in it, and boom, Windows in a window. Install Linux, boom, Linux in a window... and you can test OSX native.
If you are on Windows, things are a bit more complex. Unlike Microsoft, the simple fact is Apple are total pricks about letting you run their OS on anything other than their hardware. It CAN be done, and there are distributions and installation software to let you pull it off. I'd LIKE to go into more detail on this, but as it is a violation of Apples EULA to do so, well... 
It's actually one of the contributing factors to why I'm not exactly Apple or Apple user friendly; alongside all their other sleazy practices like vendor lock-in, proprietary design, active discouragement of third party development and ridiculous price-gouging ... and that's before we talk about them basically telling their userbase that you don't actually own any of the hardware they sold you, but that you are just "renting the experience". 
In any case, I consider the following a list of the browsers that you should be testing for as of 2015. The latest each of Firefox, Chrome and Safari in both OSX and Windows, as well as every release of Internet Explorer from version 7 upwards (which of course is Windows only).
I also suggest that you at least give a casual look at what a page does in IE 6, and possibly even 5.5. A number of mobile devices still use those browsers as Windows CE / Windows Mobile didn't even get to IE6 until late 2007, and didn't have support for anything newer until 2010. Generally speaking the page should be navigable and delivering the content in a useful manner in those browsers, but do not waste time trying to make it look like a modern browser. Users of such outdated software should be thankful we bother to think about them at all.... and a great many developers have pulled the plug on support for those older browsers altogether.
I often laugh when people call supporting those older browsers "hard" -- but there's a difference between supporting them in terms of functionality, and delivering the same experience as a modern browser. Don't waste your time on that, as it's an unrealistic goal. If you use HTML for what HMTL is for, plan your CSS to be accessible... well... there's no legitimate reason for it to be any extra effort than building without that support. Takes you more than ten minutes, you've done something wrong with your markup or layout concepts.
In that same way, don't worry about IE8/earlier not getting the fancy bits of newer layout and design technology. They don't get drop-shadows, rounded corners and so forth, OH WELL. Let the page gracefully degrade, as there is no reason to waste time throwing a bloated "shim/shiv/polyfill/whatever they're calling them this week" at it. Which is also part of why I'm not wild about HTML 5's new tags...
But most importantly TEST, TEST, TEST... -- and when you think you've tested enough, you're only halfway there!!! When I say that, I mean to do so as you go. Every time you write a major section of code and style, test it in every browser you can lay your hands on; this way you can correct the problem as you make it, instead of blindly trying to track it down later. You finish the whole layout without testing, and you've done nothing but make debugging a painful, agonizing teeth-pulling process. A few "alt-tab F5's" is usually far easier than having an entire completed codebase and then trying to blindly figure out where you went wrong.
Image Software
First, we need to make something clear. Paint Programs like Photoshop, Illustrator, Gimp, Paint Shop Pro, Pixel, etc, etc, ARE NOT WEB DESIGN TOOLS, STOP USING THEM AS SUCH! Dicking around drawing goofy pictures of what a website might look like before you even have semantic markup and a working CSS layout is putting the cart before the horse, and such a back-assward way of building websites the end result is most always an inaccessible train wreck. To be brutally frank, most people who call themselves "designers" and do nothing but draw pretty pictures in Photoshop don't know enough about HTML, CSS, emissive colourspace, accessibility, or even user interfaces to be designing anything more complex than a paint by numbers kit.
That said, I'm not saying paint programs don't have a place in site development. You're going to have content images, you'll need to crop and resize those. You will likely want background images, you'll need to work with those. Original images and logo's if you can't afford a professional artists -- guess what you're gonna need to do those?
Now, I'm usually pretty harsh on Adobe products; Dreamweaver is halfwit trash, Fireworks serves no legitimate purpose, ColdFusion is an abortion best left in the previous decade, I wish to hell people would stop using PDF's as an online format since it's not meant for that, so on and so forth... BUT...
Photoshop is the de-facto gold standard for image editing software. It is the first choice of professional artists for a reason, and really it's why for all intents and purposes Photoshop is Adobe's cash cow. If you can afford it ...or finagle it, Photoshop is hands down the best tool for the job except for one MAJOR shortcoming.
When it comes to creating files that are optimal in file size for web transmission, Adobe wouldn't know image optimization from the hole in their DVD's. Files saved by Photoshop are ridiculously bloated, and it lacks some basic tools that could be used to do things a bit better.
Some of the alternatives, while not as fancy or feature packed, do a far better job. The GIMP (Gnu Image Manipulation Program) for example does a fine job. Another program I favor - Corel Paint Shop Pro - has one of the best "save time" optimizers. When you go into file>save as, it has a "options" button that opens up a dialog letting you play with color depth, dithering, colour selection method, palette depth, and even palette transparency right there when you're saving it.
For the most part, Paint Shop Pro can do the majority of what Photoshop can, at one tenth the price. It's even compatible with a Photoshop's plugin format. I really can't sing it's praises high enough. Good for a laugh, I'm still using version 7 from 2000 back when it was still "JASC Paint Shop Pro", as it's lighter, leaner, faster loading and far more stable than any of the modern equivalents. Thankfully it runs just as good under Windows 7 as it did under Windows 98. Sometimes you just don't need fat bloated bleeding edge software.
Even with the best paint program though, you really should consider running files through an online optimizer. They most always give you smaller files, though in some cases (like greyscale PNG with an Alpha channel, or palettized PNG with Alpha) they will mangle the images. Really it's a craps shoot as to if the result is worth deploying, but it is generally worth the time and effort to at least TRY them. Properly compressing your images can be the difference between a slow loading site nobody visits, and a speedy successful one.
Testing Servers
It is usually advantageous to have a 'pretend' server running on your development machine. This way you can test server-side code without uploading it to your 'live' server. Doing it this way reduces the risk of screwing things up too badly on your live copy and is also faster than constantly uploading changes via FTP.
There are three ways you can go about this:
- If on a *nix based OS like Linux or OSX, install the actual server software locally.
- Run the same OS and server configuration in a virtual machine
- If on Windows install a testing server environment like XAMPP or WAMP.
The first of these I don't actually advise -- they allow your testing environment too much access to the host, and quite often fail to accurately represent what a real server will do with your code. Generally speaking non-Windows OS are so crippled in terms of web development in the first place (thanks to browser testing) you might as well just put Windows in there.
As one needs to test Windows anyways, (well, that and I find *nix and OSX to be pathetically crippled in terms of UI) if you aren't on Windows as your host OS you will likely have to have some form of Virtualization software installed to run Windows in for browser testing. In that case creating a simple Linux environment is the most robust route. If you are going to be hosted online with Linux it's usually no big deal to configure that virtual machine identical to how your online server is set up.
To that end I highly recommend Oracle VirtualBox. While there are other alternatives, some of them (like Microsoft Virtual PC) that are aging like milk and for some stupid reason dropping legacy OS support (one of the entire reasons to use them in the first place) while others (like VMWare) sink their tendrils so deep into the host OS even when not in use, it causes massive slowdowns and stability headaches.
Testing environments for Windows like XAMPP and the various WAMP stacks are great as you can simply edit and develop right out of their htdocs directory locally. While you would think they would face the same issues as the first of our approaches, they go to decent lengths to ensure that you get a properly viable testing environment. Even so, I would only use them for quick safe changes and rapid development, and still test in a VM long before uploading it to a real server.
Which brings us to another subject -- live testing. A LOT of (idiotic mouth-breathing dumbass) tools actually advertise "live editing" of websites - aka directly making changes on the live copy - as a feature and something people should do. This has to qualify as one of the DUMBEST pieces of advice out there. You screw up the live copy and it's out there for the whole world to see. Generally speaking in terms of server maintenance and upgrades you'll have enough egg on your face without breaking out the ostrich sized ones! Worse, you screw up the live copy on something simple, where's your backup? Maintaining a development copy locally to test changes before deployment is one of the most sane and rational things you can do. Making changes directly to a live copy? That's just special... in the same way some Olympics are "special"!
Statistics Tracking
There are a LOT of choices in how you track traffic on your website. ASSUMING you are using a mainstream server software like Apache or nginx, every access to your page and every error is logged, and a well configured server will archive old logs. There are tools like Webalizer, Analog, and AWStats that can go through those logs and give you ALL the meaningful statistics you could ever "really" need.
Sadly, marketing types and ignorant nubes have been duped into thinking they need more than that. The most common of "other tracking" approaches is JavaScript driven tracking like Google Analytics. Generally speaking these just make your pages take longer to load, offer zero legitimate extra information over what can be gleaned from the server logs, and are more often than not little more than vague numbers that scam artists can twist to make all sorts of noodle-doodle hoodoo-voodoo sound legitimate. NOWHERE is this more commonly found than amongst SEO "experts", most of whom do not know enough about HTML, CSS, JavaScript, web technologies, accessibility or even professional writing to be flapping their gums on the topic.
Running just one of these packages on a fairly lightweight site can be fairly innocuous, so if you feel the need or desire to see all that extra nonsense use one, and ONLY one. I've lost count of the number of times I've seen people have five or six different tracking packages trying to load at once, resulting in massive slowdowns of every page. Really though -- assuming your hosting is worth a flying purple fish -- there is ZERO legitimate reason to waste your time with any of that nonsense.
Summary
Generally speaking that's it for tools you actually "need", and what to stay away from. A flat text editor, a decent image editor for use AFTER you have a working HTML and CSS to provide some extra eye candy, actual browsers to test rendering in, and a proper testing server environment. Anything more than that is a waste of time and effort, and most likely means someone is blowing smoke up your backside.
