In every realm of work, there is a uniqueness that demands recognition. This truth shines brightly in the world of software testing. It is critical to understand that no two software development projects, even those sharing a technological DNA, can truly be considered identical. Various variables - from the environment within which they're created to the team orchestrating their inception – build unique compositions of software ecosystems. And for us, the software testers, it is paramount to understand and consider these peculiar compositions.

Let's dig a little deeper into some specific examples. Picture this - a software product is on your testing radar. You must determine its peculiarities that could significantly influence test execution. First, you have to understand the technology underlying your product. Is it a web application? A mobile application? Perhaps it's a comic mixing of both? You need to understand what languages and software libraries are used, the platforms the product operates on, and the product’s unique architecture. Is there an API serving as a bridge to the client? How does it store data: is it in a relational or a document database? Also, try to grasp how the software is integrated with other systems and the nature of these interactions? Are they real-time integrations, or defined in batches? Finally, ask yourself, is the software custom-built, or is it an off-the-shelf solution being installed? More...

From my more than two decades of expertise in software development, DevOps, and system administration, one lesson I’ve learnt is the importance of software testing. It’s not by chance that this post tackles the significance of learning software testing theory and techniques. In my tenure, testing has proven to be the backbone of software development- for both test specialists and developers.

Software testers often find themselves thrust into the field with little formal training on the same. The lack of structured learning on software testing for testers equates to a missing puzzle piece in the grand scheme of software development. While it might seem to work fine for developers, the long-term impacts are evident. More...

Continuous Integration is extremely important part of software development process, but is also the least used at the same time. Even at relatively big software shops, the continuous integration usually is something, that everyone heard of, but that’s it.

Among all the things you can do to shift the focus of your software developers to what they really have to do instead of what they have to do now, the continuous integration is perhaps the most rewarding. More...

Once your Team Foundation Server is performing automated UI testing on daily basis, it starts to check your code when needed. When Team Foundation Server finds that your software is doing something unexpected, it automatically creates the bug work item. This time we are going to talk about these bugs, how to get most out of them, and how to use that functionality to boost the effectiveness of your software development. More...

Microsoft Visual Studio 2010 Team Foundation Server has two most important features – the source control and the build automation. Although other features are very important as well, these two are pretty much enough to consider the purchase of the Team Foundation Server.

Today we are going to talk about the Build Management system of Visual Studio 2010 Team Foundation Server. More...

What could be easier, for a software developer, than to write a kiosk application? You set the rules, you have only 4 buttons to deal with and users just can’t do anything bad or unexpected. What could be wrong with such solution?

The absence of proactive thinking.

More...

This is part 4 of Visual Studio Team Foundation Server 2010 for Developers walkthrough. Last time we were speaking about the unit tests, and that was useful, but very basic foundation of what you can do in terms of Test Driven Development. However, we can conventionally separate testing in Visual Studio and Team Foundation Server to 3 levels. So today we are going to talk about the second level – Advanced Testing techniques, such as Test Impact Analysis, Coded UI Tests and Load Tests.

If that’s only the middle layer of complex testing in Visual Studio 2010, what’s in the last one, you might ask? There will be test automation using Hyper-V virtualization with Virtual Machine Manager and yes, we will discuss it later as well.

But today we’ll begin with Test Impact Analysis. More...

This is the 3rd post in a series of articles about Visual Studio Team Foundation Server 2010 for developers. And this time it is about test driven development. Previous one is available here.

Test Driven Development is the concept, which dictates creating unit tests before actually writing the code. To help you to understand this, let’s assume that you are writing the calculator program. And that whole calculation process is done by a separate class named Calculator with functions such as “Addition”, “Subtraction”, “Multiplication” and “Division”.

Now, according to Test Driven Development process, you should first create the test project, and write your tests for each of these functions. Since you know what result should be given for what input (like – “2 + 2 = 4”) you can make your tests to assert, that if you are running the Addition function with parameters of 2 and 2, the result is 4. If the result is different or exception occurs – the test is failed. More...

This is my second post about Microsoft Visual Studio 2010 Team Foundation Server for Software Developers. The previous one is here.

Now that you know how to submit your code to the source control, associate work items and use that information in your daily work, it’s time to learn the rest two things we skipped in the first part. The Branching and the Shelving.

Team Foundation Server is an Agile-oriented platform, and therefore many of it’s concepts supports the existing models of Agile Software Development. One of such models is Source Code Promotion Model, which basically means that your code moves through 3 stages – development, testing and production.

A word of warning: each model of Agile is a double bladed sword. It expects you to meet the conditions which will make this model effective, and if you fail to comply – you’ll get ineffective implementation, which could ruin your software development efforts. In case of Promotion Model, make sure you have a dedicated team of testers – not just developers from other project who came to rescue, but professional testers who are not doing any development. If you don’t have dedicated testers – forget about Promotion Model. More...

Rather short note for pen-testers.

Sometimes you have software which is contacting some web services – especially interesting when it’s about transferring files.

Sometimes some software packages, especially custom ones, made for a small number of customers, may have web services open for consuming by that software.

Pay attention to it. Sometimes there are exposed functions which could be exploited in a way that developers were not able to imagine.

For example, during my most recent pen-test, I was able to put files, delete and execute on server using only functions of exposed web service. Needless to say, I wouldn’t need any hacking tools or social engineering to penetrate networks of their customers as well.

This topic is rather omitted in CEH and similar courses, but with some base knowledge of programming you could kill the whole family of rabbits with one shot.

Also, as a side note about pen-testing. I noticed that even when you’re using simplest technique, a “no-brainer” one, customer will call you “hacker” or “genius” just to not call their developer or system administrator an idiot.