Posted by admin on Oct 4, 2010 in
code,
tips,
VSTS

Visual Studio 2005
Yesterday I brought into work an application that I had developed at home. The application was written in VB.Net using Visual Studio 2008.
My work Development environment is Visual Studio 2005 and I needed to update the source code so I tried to load up the solution file and I received the error “The Selected file cannot be opened as a solution or project. Please select a solution file or project file “.
I know from past experience that .sln (solution) files are just text files with references to other code and the development environment.
So if you ever receive the above message and your moving code from Visual Studio 2008 to 2005 then load the sln file in a decent text editor (Notepad ++ will do)
change the top to lines from
Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
to read
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
save the solution file and now open it in your 2005 development environment.
You may have to refactor some code if you have used new objects or syntax which are new to 2008.
However you should be able to to just code as normal.

Liggat Authentication Fail
This post will be a disclosure on how to not design and implement a login processes.
Ligatt Security and Gregory Evans the main man behind Ligatt has come under quite a bit of flack recently for doing things like alegedly making threats to other researchers and also for alleged plagiarism .
While all of this Internal Security Industry bickering is beyond me and this post. I would not trust a company with protecting my data if they can’t even protect their own.
And with that said. / Month Of Full Disclosure item 3 = Ligatt Security and how not to write an Authentication Process.
Text Version Here
Ligat Security – Authentication Bypass
————————————-
Vulnerability ID: Month Of Full Disclosure 3 = MOFD3
————————————
Product: LocatePC
————————————-
————————————-
Vendor Tag Lines: Cyber Security is never an issue with LIGATT on your side
————————————-
Vendor Notification: 05 August 2010
Public Disclosure: 05 August 2010
————————————-
Vulnerability Type: Authentication Bypass
————————————-
Status: Public Disclosure – Not Fixed, Vendor Alerted,
Awaiting Vendor Response
————————————-
Risk level: High
————————————-
Credit: Martin Hall – TheTestManager
————————————-
Vulnerability Details:
If you visit the LocatePc page
in a normal browser you will be redirected to the login page.
However if you visit the same URL in a browser where Follow Redirects is turned off
then you will not be redirected and you will be able to use the LocatePC functionality.
Instructions Follow for Opera.
Click on Tools
Click on Preferences
Click on Advanced
Click on Network
Untick “Enable automatic redirection”
Click on OK
Now follow this URL

Ligatt Authentication_ByPass

Show me where that PC is
————————————-
Sample URL’s
————————————-
Solution:
Currently I’m not aware of any vendor-supplied patches or other solutions.
If you are aware of more recent information related to this issue please notify me at: martin@hb-help.com
————————————-
Other Miscellany Information
Posted by admin on Jul 22, 2010 in
Interviews,
Testing,
tips

Landing a Dream Job
I’ve recently been interviewing for a Lead Tester to join my Team and I’ve been a little dismayed about how unprepared some of the candidates are for interviews be they telephone interviews or face-to-face interviews.
So I’ve decided to put together a few little hints and tips to hopefully help candidates in the job market land their dream job.
- Firstly make sure you customise your CV for each job you apply for. Never send a generic CV to a company and expect it to be good enough. Look through the job specification and list of requirements and tailor your CV to match what they are looking for. Go through your past roles and pick out the parts of the role that matches what you think match the Job Specification.
- Now lets take a look at the cover letter. They do have a bearing on if you will get noticed and virtually all potential employers will look at your cover letter before they look at the CV so make it count. It needs to be about you on a personal level as the CV will tell them all they need to know on a professional level. Hopefully you’ll be like myself and have a real passion for testing if that’s the case then you need to make sure that it comes across in the cover letter.
- Do your homework on the person who you be looking at your details and also the department where you would like to work for. Doing your homework on the company alone is not enough. Anyone can visit the company website and read the blurb however you need the edge so research as much as possible and then use all of that research to let them know you’ve taken the time and effort to find out more than the average Joe about what they do.
- If the Company in question has a Careers or Job offers page or sub site then make sure you register and upload your details before sending in your CV. Not only does it show your interested, it will also show them that your serious about working for them and you are not just sending in your details to every company that comes along.
- If you go to a Careers Fair make sure you have your customises CV with you. It should be no more than 1 page of A-4 you may use both sides if you must however try and bullet point to one side. This CV version is just for the company staff member or Test Manager to see if they think they would like to know more.
- At a careers fair tell them about you and not about your CV they can read the CV however what your CV will not say is what type of person you are and what things excite you.
- Make your CV results oriented. It will mean more if you state I did this and the positive result for the business was this, over I this this.
- Please show some emotion. You may not believe it, but it’s hard work interviewing all day. It makes it much easier on the both sides if the interviewer can see that the interviewee is excited about coming to work for their company.
- Remember not to be so nervous, I always tell interviewees that an interview is a two way process and that they should be interviewing us to see if we match up to their ideals as well as us interviewing them to see if I think that they would be a good fit into my Testing Team.
- Keep a note of who you have applied to and if you had a Telephone interview then during the conversation make sure you note down any keyword which you think may be relevant. You can relate these back to the interviewers in a face to face interview.
- Look into Forer Effect Statements / NLP / Confirmation Bias and Subjective Statements. However before you attempt to use any of these techniques make sure you know what your doing as they can work against you if you do not know how to use them correctly. Once mastered you’ll find them indispensable not only in interviews, they can help out also in every day business.
- Look for yourself in a Search Engine and make sure that what you find is suitable. This means that if a potential employer Googled you, would they get a positive result or not?.
- Salery Negotiation – Make sure you know how much it would take for you to leave the place you are currently working and if asked never answer with an “Urmmm” or “I’m looking for something around” . Let them know how much you would like and have a reason why you think that you are worth that amount.
- The most import and last one is BE HONEST.
Good Luck
Martin Hall
Tags: cover letter, cv, dream job, employment, interview, job specification, qa, recruitment, telephone interview, Testing, tips and tricks
Posted by admin on Jul 5, 2010 in
code,
productivity,
Testing,
tips,
tools,
VSTS

Visual Studio Webtest Logo
I use Visual Studio Team Testers Edition everyday at work and one of the things that seemed really strange to me was that Microsoft had missed so many tricks when they decided to release it.
Maybe they just decided to build in reasons for users to upgrade, knowing that there will always be another version of VSTS around the corner.
One of the things which is sorely missing is the ability to verify HTML source code against a datasource. Sure you can load a data source and then verify what is returned on the page when that row of the data-source is called however there is no functionality to check that the value of the row that you have submitted is returned somewhere in the HTML source (known as the response in VSTS).
So as per usual when you need something doing then, do it yourself, and hence I wrote a small piece of code that looks at the source code and then checks the value of the datasource row to make sure that the item you are submitting is returned in the HTML response.
All the data is dynamic from your source so you can’t just hard code validation rules, as there could be thousands of rows.
For an example take a Google search test. Imagine I want to check that my datasource of 10,000 records is retuned on every response.
So if I search for “System Testers” as a parameter value
“Parameter Name = q” and
“Parameter Value = Google DataSource.Directory_03062010#csv.SearchParams”
In the above QueryString Parameter you can see
the Datasource is called “Google DataSource”
the Actual FileName is “Directory_03062010″ (and it’s a CSV file)
the Column name is SearchParams
I’ve commented my code to make it easier to understand however if you need any help just ask.
Code Below.
‘———————————————————————
‘Author = Martin Hall
‘Purpose = To load text from a DataSource and then to compare that text
‘ against the source code on the page your testing.
‘Date = 07th June 2010
‘———————————————————————
Imports System
Imports System.ComponentModel
Imports Microsoft.VisualStudio.TestTools.WebTesting
Namespace RegressionSampleWebTestRules
Public Class RegressionAllHeadingLocationsRule
Inherits Microsoft.VisualStudio.TestTools.WebTesting.ValidationRule
‘———————————————————————
‘ Specify a name for use in the user interface.
‘ The user sees this name in the Add Validation dialog box.
‘———————————————————————
Public Overrides ReadOnly Property RuleName() As String
Get
Return “RegressionAllHeadingLocationsRule”
End Get
End Property
‘———————————————————————
‘ Specify a description for use in the user interface.
‘ The user sees this description in the Add Validation dialog box.
‘———————————————————————
Public Overrides ReadOnly Property RuleDescription() As String
Get
Return “This should Compare text from a datasource parameter in a CSV file against the page sourcecode.”
End Get
End Property
‘ The name of the expected string
Private ExpectedStringValue As String
Public Property ExpectedString() As String
Get
Return ExpectedStringValue
End Get
Set(ByVal value As String)
ExpectedStringValue = value
End Set
End Property
‘———————————————————————
‘ Validate is called with the test case Context and the request context.
‘ These allow the rule to examine both the request and the response.
‘———————————————————————
Public Overrides Sub Validate(ByVal sender As Object, ByVal e As ValidationEventArgs)
Try
Dim result2 As String
‘———————————————————————
‘we only want request2 to match the source code on the returned web page.
‘the SourceCode could be different on the other pages.
‘———————————————————————
result2 = (e.WebTest.Context(“Google DataSource.Directory_03062010#csv.SearchParams”).ToString())
‘———————————————————————
‘This should check the response for text
‘The text in question is the ParamValue we are supplying as new fake
‘parameter name and value
‘———————————————————————
If e.Response.BodyString.ToLower.Contains(result2) = False Then
e.IsValid = False
e.Message = (“fail – - “) & result2
End If
If e.Response.BodyString.ToLower.Contains(result2) Then
e.IsValid = True
e.Message = (“pass – - “) & result2
End If
Catch ex As Exception
End Try
End Sub
End Class
End Namespace
/End Code.
The above script is in Visual Basic.Net and it should work for you and if you need any help in how to install and run it then either send an email or reply in the comments.
One last thing to mention is that the values from the data source are loaded in a fake Parameter Name (Just make one up) which will be ignored by the Website however it will show as a Context Name in the Visual Studio Web Test, so we are really just comparing two Context Names
Good Luck
Martin H
Posted by admin on Jun 2, 2010 in
Testing,
tips

Why we need testers
As I promised in my last blog post, here is the presentation that I gave a couple of years back on why we need testers in development teams.
please note that everything about this presentation is rough as it was never meant to be publicly shown or distributed, it was created for a small in-house audience.
I’ve posted the headline text for the slide-show in this blog post and then link to the powerpoint file below. You’ll have to fluff out the main text as it’s only main headlines so I knew what text was coming for which slide.
DOWNLOAD THE POWERPOINT PRESENTATION
If you wish to make a similar presentation in the future you’ll have the slide-show above and the headline text below to refer to.
Text for the Slide-Show =
QA – Why we need Testing and Testers
2) Jigsaw story or why developers shouldn’t test
3) What is Quality and how to measure it?
Well we sometimes take quality to be subjective and we expect that others will know what we mean when we say that a product has quality.
But in an example of an car one user may say that the car has quality because of leather seats and air con – yet another may think otherwise and base the quality upon the engine specifications etc. However quality can universally be measured by the way a product meets its specifications.
If a finished product meets its design specs 100% then it can be argued that it is a quality product as it has been built exactly the way it was supposed to be built.
4) BAD CODE = Creating poorly written code
Even after decades of advancement the software industry, the quality of software produced remains one of the biggest problems. This coding bad practice started mainly during the dot com boom as new start ups rushed to produce a working example of the “next big thing”, Even in today’s market we have a large focus on “time to market”, not only this but also the sheer growth and volume of software being developed, and the amount of amalgamated new technologies to absorb, it really is no surprise that software development houses still continue to face quality problems. There are two main sides to these quality problems: high defect rates and lack of code maintainability.
5) ROI – Return on Investment
Speeding up Development time and less cost.
Almost every organisation in the world be they schools – governments or Nasdaq/FTSE100’s rely on software to help them with their daily processes. A vast majority will depend upon the software industry for product development, production, marketing, support, and services.
Spending on software development is very costly but there is a great way to partly reduce that cost and that it efficient testing processes. For example if there is going to be more that 3 iterations of software then it will usually be financially viable to start an automated regression testing process.
Better company image.
There can be nothing worse than using a piece of software and it crashing in front of a user. Especially if it does it in a messy way (losing data etc.)
Imagine buying a piece of software and having it fall over constantly because you put an apostrophe in a name field (O’Donnell for instance). This type of thing will happen on badly coded systems with SQL back ends (SQL Injection).
But with through testing the system should never fall over in front of the user and if it ever does the error should be captured and the user given a helpful message. With wide spread use of the internet its also possible to have automated bug reporting built into programs so that they not only provide the user a decent message and close correctly but they will also automatically report the bug to the software house with a small process tree list and provide the user with a defect ID.
This goes back to the car and idea of a quality product. If it does what it says on the tin then it should be OK.
But of course we can’t just test using this “on the tin” approach we have to try and break our product by first doing what it says “on the tin” (the design specifications) and then by doing everything else (lookup equivalence partitioning).
This can include buffer overflows. Out of range integers – non syntax types – e.g. text in a date field etc.
6) But I said we need testers before I mentioned automated tools so can’t we use these test monkeys find these bugs?
Well the answer is NO –
Bugs are found during manual testing based on a testers desire to deliver quality product. Verification is conducted while the testers are operating the applications and comparing the actual results with the results they expect. However, some bugs are still not detected with manual testing. Therefore, it is desirable to automate as many of the manual testing tasks as possible.
But these automated tools lack the common senses of a human being. Manual testers are still needed to test the high-risk areas of the products.
Test monkeys however do have a purpose and are often used in addition to human tests. Test monkeys are automated tools. Their testing actions are randomly performed without a user’s bias.
Benefits of them can be
1) They will run and run until they crash a system (fuzzing being my favourite kind)
2) They can be put on an old or slow system
3) They don’t get bored or care if they GUI has changed. (they can run test scenarios for days on end non-stop)
4) Microsoft said that 20% of all its defects found were by using monkeys.
Not all automated tools are dumb monkeys in fact the majority of tools used are partly AI based.
7) The Perfect tester
What makes the perfect tester? In my opinion it’s the same hacker mentality of Steve Jobs, Steve Wokniak, Bill Klaxton and Bill Gates the old school hackers who helped to create the systems we use. They took a look at what systems existed (virtually everything back then was IBM or listed as IBM compatible) and wanted to change those systems by making them better.
It’s wanting to know how something works and wanting to see if you can beat it.
This beating it for me is finding a bug.
If any of the above is used in any presentations then I’d love to see/read your take on why software needs testers.
Posted by admin on Jun 1, 2010 in
productivity,
Testing,
tips

The Testing Jigsaw
A couple of years ago I was asked to present a talk at a testing conference.
I did a whole presentation that I will post up to the blog in a week or two. The one part of the presentation that seemed to grab everyone’s attention was a story I told about the Developer / Testing Jigsaw.
I think the reason it was so widely accepted was because its given in the form of a story, and we all like a story right?
So if your all sitting comfortably then I’ll begin.
There was once a small boy and his father sitting down together one Sunday afternoon. The father said to his son I have a small surprise for you. I’ve made you a little jigsaw puzzle, its of a tree with grass and sky as the background. Wow, said the little boy as his face lit up, can we do the jigsaw now please?.
Of course said the dad.
So the dad tipped out all of the pieces onto the mat and begun attempting to put the jigsaw together. The son asked his dad if he could help by looking at the picture on the box and advising his father on where he thought the pieces were meant to go.
However his father said “no need – I created this puzzle so I know exactly how it should go together”.
The father struggled on for another 3 hours and wasn’t really any closer to getting the puzzle finished. He then got in a mood and said that he gives up and some pieces must have got lost.
The son then took over and compared each piece to the box making sure that he was putting the pieces where they were meant to go. He did the smart thing first by putting all of the corner pieces where he thought they should go. He looked at the box once more and thought to himself that blue is the sky, the green is the grass and the brown is the tree. So he separated the coloured pieces in 3 piles
He eventually finished the puzzle in about 45 minutes.
There is an obvious key to what is happening above in this story.
The Son is the Tester
The box is the Functionality Specification Document.
The Dad is the Developer.
The jigsaw is the piece of software that has been developed
Yes developers can test code, in fact I encourage it (peer reviews of other developers code and Unit tests), however they should not be the sole testers of code, especially if the code is written by them. Going down that route is a recipe for disaster.
The son who had never seen the jigsaw before managed to finish it in a faster time than his father and also in a more methodical manner.
Testing is a mindset. It’s an art that I, and many others spend every day attempting to perfect. Developers spend most of their day writing code, (also testing their code – Unit tests etc.)
I’m all for test driven development, however lets not forget that with specialisation comes speed and efficiency savings.
Posted by admin on Mar 16, 2010 in
code,
SQL,
Testing,
tips
I was recently testing a rarely used piece of functionality on one of the sites which belong to the company I work for. The test DB was very old as releases for this part of the system come very few and far between.
The system is written in such a way that data is only returned to the end user for data for a the last 12 months , (1 Year). The database in question had not been updated for about 18 months and it would have taken about 5 days for me to get a decent backup from the live system restored to test.
The data in the Test Database was valid it was just a little too old to be returned via the front User Interface (GUI).
What I needed was a nice and easy way to bring the date column in the database forward by year.
Obviously for good practice I also requested the live DB dump to be sent over just to completeness of testing. But to test this piece of functionality it wasn’t needed.
The following is the SQL query (Transact-SQL) I cobbled together to get the job done.
It will do a select first to see if you have any data in a particular financial year (2009 and 2010).
It will then update all 2009 data to read 2010. So 01-Feb-2009 becomes 01-Feb-2010 and 23rd June 2009 becomes 23rd June 2010.
It will then carry out the same select query it did before. If all has gone well the 2009 data should be blank and the 2010 field should be populated.
In any update script I write I always input a select before the update and the same select after the update. This way I and any other users using my script can see if the update has worked.
Now the code.
SELECT YEAR(ColumnName) AS ColumnNameYear
FROM TableName
GROUP BY YEAR(ColumnName)
HAVING (YEAR(ColumnName) = 2010) OR
(YEAR(ColumnName) = 2009)
UPDATE TableName
Set ColumnName = dateadd(yy,1, ColumnName)
WHERE DATEPART(year, ColumnName) = ’2009′
SELECT YEAR(ColumnName) AS ColumnNameYear
FROM TableName
GROUP BY YEAR(ColumnName)
HAVING (YEAR(ColumnName) = 2010) OR
(YEAR(ColumnName) = 2009)
Hope you find it useful.
And I’m sure there are many more ways of coding this much simplier but I’m a tester and not a coder and for me it works.
Posted by admin on Jul 7, 2009 in
Testing,
Uncategorized

Playing with Search engines.
As most of you know I spend virtually all of my working day testing search engines. I thought that today I would take a small look one of the new big kids on the block Bing which is the new search engine from Microsoft.
As I’m a Test Manager I won’t be be comparing basic searches but I’ll be looking for weird results and also looking for possible defects.
One of the great things about Bing is that it’s very similar to Google in that they share the same search structure, so if I type into Bing that I want to look for The Test Manager the URL will look a little something like http://www.bing.com/search?q=The+Test+Manager.com&go=&form=QBRE&filt=all&qs=n . Now if I want the exact same search in google all I need to do is to change the domain name from bing.com to google.com keeping the rest of the URL so the query now reads. http://www.google.com/search?q=The+Test+Manager.com&go=&form=QBRE&filt=all&qs=n .
So lets start looking for interesting data. Read more…
Posted by admin on Jun 28, 2009 in
Testing
The one thing a tester has to be able to do is to correctly evaluate risk. This can be done when choosing the priority or severity of a defect or to a Test Manager having to decide how to correctly decide what defects are going to be added or removed from a deployment during the triage stage.
The reason for the picture on the left is that Pigs kill people each year than sharks do. An interesting fact that is not very widely known.
So it’s strange that more people fear sharks. Its this fear that messes with our ability to correctly evaluate risk.
I had a conversation about the shark/pig statistics above with a work colleague and their reply was that they ” had never heard of a pig killing on the news yet they had heard of shark kills on the news”.
This sort of proved my point. News is exactly that a rare event that happens. We don’t hear that over 60 million people go about their daily lives each day in the UK without any major events happening, however when a stabbing or a shooting happens then it makes the news because its a very rare event. We also on average spend more time of our lives in waters where sharks frequent than we do on farms.
People should realise that if something happens that makes the news then usually, they don’t need to worry about it. By definition, ‘news’ means that it hardly ever happens. If a risk is in the news, then it’s probably not worth worrying about. When something is no longer reported—automobile deaths, domestic violence—when it’s so common that it’s not news, then you should start worrying.
Posted by admin on Jun 26, 2009 in
code,
Testing

Lets Break some code
The title is a little misleading as the one thing I think that testers do not do, is to break developers code.
Instead we should working with them to help find as many potential issues before our customers do.
(think of it as a department that carries out a specialised peer review)
However as a tester you need to have a few tricks up your sleeve which enable you to quickly punish an application.
The following strings will usually cause most web-enabled applications to perform strange functions or just plain fall over in a heap.
Each separate line is a separate test.
I have created a bespoke parameter fuzzer which I load my list into and 99% of the time I get a fail in a web-application.
You can also use my URL Encoder / Decoder to look a little deeper into the char-sets being used.
Read more…