Full Disclosure – How not to write a Forms Authentication Process

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

Ligatt Authentication_ByPass

Show me where that PC is

Tips and Tricks to landing your Dream Job in Testing or QA

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

Verifying that the Text from a DataSource Exists in a WebTest Response 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.

/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

Browser Support Testing Standards (document for Web Testers & Test Managers)

Testing Different Browsers

This is a document I originally wrote a few years back.

It’s a living document meaning that it’s constantly being updated and it’s never finished.

I’ve removed all references to the company I work for and have instead listed in bold text the places where you should insert your company name or your companies website name or the stats gathering tool which you use.

It should all hopefully be all rather self explanatory however if you need help in fleshing it out a bit just send me a mail or reply in the comments and I’ll be glad to help you.

I hope you find it useful.

Browser Support Testing Standards

Author(s)

Martin Hall

Contents

Introduction,  – Test Items, – Not To Be Tested, – Approach, – Test Applications And Resources, – Resources, – Communication, – Defect Logging, – Pass/Fail Criteria, – Suspend/Resume Criteria, – Test Deliverables

Revision History

1. Introduction

1.2.1 As testers we accept that the nature of the internet medium is such that web pages cannot be produced in such a way as to be uniformly rendered in all browsers, so as to provide a consistent experience for all users. We accept that small variations in this experience are acceptable within the ‘Levels of Support’. (See appendix 1 for details)

1.2.2. Web browsers will be assigned a ‘Level of Support’ by the insert your company name here Test Manager, in the Browser Support Table. (See appendix 2 for details of how these levels of support are decided).

1.2.3 Web browser support levels will be amended on a regular basis depending on the statistics that come from the Insert the name of your statistics system here (Webtrends for example).

2. ‘Levels of Support’ definitions

2.1. Support Level 1 – supported web browser – Support definition

2.1.1. All content and functionality MUST work.

2.1.2. Variations to presentation of content MUST be minimised.

2.1.3. Where CSS layout is used, the CSS MUST be rendered by supported web browsers, so that a fully-styled version of the page is presented to the user.

2.1.4. Variations between browsers are inevitable. In these situations, when deciding which browsers should offer a better experience than other browsers (i.e. which would be the closest to the original design), you MUST base your decision on which outcome would maximise the ‘Objectives of Web Browser Support’.

2.1.5. Pages SHOULD be developed to maximise the user experience for users of the web browser with the highest proportion of users (IE7 Windows PC at this time) UNLESS this would greatly compromise the ‘Objectives of Web Browser Support’.

2.2. Support Level 2 – partially-supported web browser – Support definition:

2.2.1. All core content MUST be readable and usable

2.2.2. Navigation functionality MUST work.

2.2.3. Any degradation to (client-side) application functionality SHOULD be graceful degradation.

2.2.4. Any degradation to presentation SHOULD NOT obscure content.

2.2.5. Where CSS layout is used, you MAY choose provide a non-styled version of the page to partially-supported browser.

2.3. Support Level 3 – unsupported web browser – Support definition:

2.3.1. No support or testing necessary.

2.3.2. All web browsers not specifically listed in the support table are unsupported.

2.3.3 There is no need to code or make any alterations for unsupported browsers.

IE = Internet Explorer,

FF = Firefox,

Chrome = Google chrome,

Safari = Apple Safari,

Opera = Opera

Appendix

Appendix 1 – Background

Although we are a UK based and UK targeted company Web pages are available to viewers across the internet, anywhere in the world, using a wide variety of web browsers. These web browsers are developed by a number of different organisations with a variety of motives (some commercial), each of which interpret the source code used to produce web pages slightly differently. As a result, any single web page will not be uniformly rendered by all web browsers, to produce a consistent user experience as intended by the producer.

While this has improved over time, standardisation of web browsers is still to be achieved. The quest for standardising source code and the manner in which web browsers interpret it, has been led by the W3C (World Wide Web Consortium), an organisation whose stated role is to try to “lead the Web to its full potential”. The support amongst the community of web developers for standardisation has come to be known as the ‘Web Standards’ movement.

This insert your company name here standards document exists so as to produce web pages that can be viewed (as consistently as can reasonably be achieved) by the greatest number of people possible.

HTML and CSS for separation of meaning from presentation

Because of the lack of web standards in the past, the only way to provide a consistent user experience was to use only the small range of source code features which worked across all web browsers. Specifically, the inconsistent rendering of CSS meant that CSS was not used much. HTML, which was more consistent, was used for both meaning and presentation; although its intended purpose was semantic rather than presentational.

With the advance of web standards, this has changed. HTML should thus be used to mark-up web content, to give it semantic meaning; while CSS should be used to define the presentation of content.

Not only is this how HTML and CSS are intended to be used (as outlined by the W3C), but it brings a wealth of advantages that considerably improve the potential to improve public value at insert your company name here; especially in terms of reducing costs and improving usability, e.g. accessibility. The use of HTML and CSS in this manner is often referred to as ‘standards compliant code’.

Web browsers employ varying degrees of compliance to W3C recommendations (web standards) and consequently insert UI Developers name often has to employ hacks and work-arounds* to meet the above Browsers Support Levels so that our content can be viewed by the widest possible audience, while providing the optimum user experience. However, these hacks and work-arounds cost time and money, for supporting older, less standards-compliant browsers.

This insert company name standard defines which web browsers are supported by the insert company name, based on these and other contributory factors, to optimise value for users of the insert company website name website.

• A hack is something that is not valid
• a work-around is valid, but requires additional code

Appendix 2 – Objectives of Web Browser Support

When considering which ‘Level of Support’ a web browser should be assigned, the following are some of the issues that are considered.

1. Firstly we should check our insert statistics tools name stats to see the browsers that our current customers use and make sure we are proving content that all of our current users can view. Any browser used by more than 3% of our customers is added to the SHOULD TEST list and any browser which is used by more than 5% of our customers is added to the MUST TEST list.

• Web standards are good for the web and meeting these standards offers value for money. Meaning that we will not have to recode a page because of incompatibilities.
• Insert company name customers use a variety of web browsers. Our aim should be to provide the best possible experience to the largest number of people.
• All of our customers are considered to be valuable.
• Some people use accessibility tools (Elderly or Disabled) – these people benefit greatly from web pages that are standards compliant.

1. Insert company name should not, where possible, provide a service that gives a competitive advantage to any particular product or service. (E.g. we should not add to any page ‘works best in x browser’).
2. Insert company website name represents insert company name. The companies image is considered to be of importance and, therefore, as a main communication point with our potential customers we should be displaying content that works well and has a nice look and feel to as many who view as possible.

Martin Hall

Testing Presentation (Why we need testers)

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.

The Developer Jigsaw (or Why we need more testers)

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.

Increase All Data in an SQL DateTime Column by a Year.

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.

Playing with Search Engines Part 1 = Bing

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…

Evaluating Risk

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.

Lets Break Something

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…