Never as easy as it seems

In any organization there is what is best? what is right? and what actually happens.

What I have been seeing lately is alot of internal politics which seems to directly stand in the way of what everyone knows is right. Being who I am I stay out of it but this carries its issues. To be seen as suitable for a higher post within my organization I need to get involved in this politics directly.

This has just been a lesson to me to be clear to myself what I need from my job and to strive for that and not just doing my job well. Age old rule that you need to being already doing the job to get the job.

Risk based testing..what is it?

As testers we use risk-based testing every day to ensure that project and product risks are are being identified and addressed. This is accomplished by drawing on the knowledge of business representatives, designers and testers to identify early any risks, establish focus areas to be tested and agree mitigating actions that can be taken to deal them.

These risks are then added into the Test Plan with the established level of risk. The risk level can be calculated by multiplying an estimated probability and impact, the estimated values should be approved by the stakeholders. These risks and their importance are regularly reviewed with stakeholders and mitigating actions to deal with those risks are identified. Testing activities are then targeted at the high risk areas first to prevent these risks being realized and minimize potential cost, quality and time implications.

Take a break..

It doesn't matter how good you are or how easy you take it some times you just need a break. Take the holiday step away from the plate and let the whole world come back into perspective. Sometimes it is good to remind yourself what your priorities are and while you are on holiday is a great time for that.

If you haven't guessed I am on holiday avoiding work and putting my feet up, Looking after my little girl. Nice to have the time to think why do I work and whats it all for.

All I say is .. If you are on holiday ENJOY IT!! save the worry of what is going on in work, for when you are in work. It is unlikely to go anywhere and you are not being paid for the worry.

2 weeks work in 2 days

The software is late to test and needs to be sorted in 2 days and not the original 10. Something needs to give in order for the work to be completed on time and what is it? The example that I heard from a man 40 years in testing is this. If a 2 litre jug is the amount of work needed and a glass is the amount of time we have start pouring. It doesnt matter how much water you pour the water wont all fit in the glass.

With the testing what is needed is a test case, documenting what we are aiming at doing. If the time available is changed then the prioritization within the test case can be quickly utilised and the work done can be de-scoped. If we have tests that range from risk 1 - 9 then it might be that within 2 days we can only run the risk 9 tests, this can then be agreed as an acceptable approach with the stakeholders. It will mean that an informed decision can be made on whether the coverage provided is acceptable or not.

Accessability testing pt .1

pt .1 - Blind or partially blind users

This is a really subjective thing to test and depends what you are looking at checking for. The main thing for web pages is to try using a magnifier and reader with your web pages and that way you will understand the issues that partially blind or fully blind users might encounter. Then you can look at making your site as easy for them to use as possible.

My recommendation to anyone looking at this area would be to view a website like www.bbc.co.uk with a reader first and then try some other sites. This will show how BBC do it right and how wrong some other sites get it.

Work to life balance.

Its a funny world and I am not sure that everyone gets the work to life balance right. To be brutally honest, Im not sure if even I get the work to life balance right. The world today leads people to work as hard as they can training body and mind to work like a machine. To be able to excel within your job you need to be better than those around you.

Whilst thinking about that it is important to consider that people need time out and arnt machines. Take a break, Let go! and allow your mind time to work through problems. Some of the best ideas and most complex problems I have resolved have been sorted when taking a break and not thinking about it. If you have an exam to cram for and something solid to learn burning the candle at both ends can help... this is not always the best thing for working.

Requirement trade off

When testing against releases the process is ongoing stepping from the execution in one software release and into the planning and preparation for testing another release. With everyone working to tight deadlines and us working alongside the software developers often we find that many of the details and requirements are not available at the planning stages. I try to implement the following to ensure that by the time software is ready to test we have the required scripting completed and the requirements/design is available. Firstly i evaluate what should be in the release based on what has been approved and then i review the requirements. I then identify what i believe to be testable requirements and weak areas that will need further review and highlight these areas back to the business analysts. I will then produce test scenarios, scripts and cases to cover the testable areas and repeat this process up until the software is submitted for system testing. If the requirements still are not acceptable then a decision is taken to either reject the release or proceed with a risk. If proceeding with a risk then this should be formally noted against the project.

What definately should not happen is that the developer says to you we dont have the requirements but this is what it is supposed to do. If you take this information and then use it as a test basis then how do you know if that is the product that was requested initially. Ultimately what this will lead to is poorly defined requirements and a request that started out for a 'rope swing' and ended up being a 'crane'.

New testers starting out

My team have in recent times gained a couple new testers. This has highlighted to me some of the simple things that you forget as you become more experienced. Basic principles that are of use to someone completely new to testing.

1. KISS - Keep It Simple Stupid : if you are going to write test scripts keep them simple and write them so that anyone can follow them.


2. Review - When planning test scripts run the scenarios then at least have these peer reviewed i.e. get someone to look through what you are planning and comment on it. Once the scripts are complete i would recommend that for visability these are reviewed by business, technical and test representatives before script execution.


3. Dont debate it log it - When you find a defect then dont try and work out why or debate whether it is or not LOG IT. If you have found a difference between the actual and expected outcomes then the ideal person to resolve this issue is the developer and not the tester.


4. Picture says a thousand words - Where possible attach a screen shot of any issues, this gives more detail than just some text and might provide information to the developers that was not previously noticed. This also provides evidence that the issue was encountered as described.


5. Break it down - Break the scripting down into bite sized chunks in this way it will be much more reusable especially if you have a tool that will allow parameterisation.


6. Assume nothing - When you are testing an application it should not be based on what you think it should do. This information should have been clearly provided in advance in the documentation. If you dont have all of the requirements and design information required then this should be raised as an issue.

Unit test recording

I am in the process of working with some developers in ensuring that they produce an acceptable level of unit test evidence. This can cause issues as we dont wish to add a large overhead to the unit testing process by mandating the use of test scripts and formal test execution but at the same time require some record that the unit testing has been performed.

What is being trialled so far with some development acceptance is a simple document asking for information on the :
Introductory Information

• System - Software application that is being worked on.
• Project - Project Name and Code
• Change - What is being tested? could be the whole system or could be a small new feature.

Tabulated

• Tester - Person performing the unit testing (Ideally not the developer of the code.)
• Test ID - Identification for individual test
• Input - Quick summary of what action is required (e.g. click all close buttons)
• Expected Output - Quick summary of what is expected (e.g. application should close successfully with no exceptions or memory leaks)
• Test passed - Y/N
• Issues - Any issues outstanding.

This it is hoped will help prevent certain areas of unit testing being missed and greatly increase the overall quality of the end solutions.

Office Politics

Isn't it strange how when working within a company, everyone should be working together and separate teams should be effectively communicating, they just DON'T. I think a key issue here is office politics and this is within testing as much as any other area.

What relevance is this? you might be thinking.

My day began with fireworks over what team should be testing a piece of work and ended with finger pointing over who was responsible for the test environment when not enough resources have been scheduled for adequate resource.

To me it stresses that approach is everything when dealing with issues and that the power of talking to someone face to face should never be under estimated. If the communication initially had taken place sat around a table and been recorded then the responsibility in both cases would have been clearly laid out.

To deal with office politics and different team agendas
1/ Get everyone (especially those that have differing approaches) around the table in a meeting.
2/ Make it clear to all of the people attending what will be discussed and what is expected by the end of the meeting.
3/ Ensure that everyone agrees the way forward and that this approach is minuted and issued at the end to all attendes.

Once completed then by definition someone has assumed responsibility for this. Later in the process there should not then be any contention over resourcing etc. For these issues the documents production and agreement is essential as this ensures that everyone is clear of their responsibility.