With increasing use of agile methodology, reducing budgets and ever chaning requirements I personally reckon ET (exploratory testing) is now more often required.
We all do ET. Sometimes the deadlines are so tight that we have to go to the extent that we do all the testing but have no documentation available to prove what or how much was tested. SBTM helps to fix that problem.
In my earlier post I mentioned that we are trying to integrate SBTM (Session Based Test Management) with our existing infrastructure.
Well finally we’ve done it and also managed to get a sign-off from our PM (project manager) and other team leads on fully implementing on a high-profile 9 month project.
To give an idea here is how we have done it:
- Tester creates his/her session reports on enterprise wiki – so that it is viewable by any and everyone.
- We have a linux web server where we ported all the SBTM scripts provided by James Bach – made some mods to it to read wiki pages
- Call the main script which creates all the reports and voila they’re ready to view and analyse further
Screenshots for the above are also viewable here.
Thanks to James Bach for SBTM scripts and Brian Osman for further instigating the thought of implementing ET and SBTM.
Clickjacking is a malicious technique of tricking Web users into revealing confidential information or taking control of their computer while clicking on seemingly innocuous Web pages. (Source: http://en.wikipedia.org/wiki/Clickjacking)
[Image Source]
Here is a simple example where clicking anywhere on the screen (except header and footer) takes the user to another website. http://www.collegehumor.com/video:1928558
Prevention
Currently it seems like there is only one way of protecting against such attacks and that is by using the ‘NoScript‘ add-on for Firefox.
One more quick example of a phishing email.
As per the tip in my previous post: checkout the domain name.
It is actually replaced by an IP address
OWASP (Open Web Application Security Project) recently released OWASP Top 10 – 2010 rc1, their new Top Ten List of website vulnerabilities.
At number eight (8) there is a new entry – A8 – UnvalidatedRedirects and Forwards (NEW). I thought I’ll briefly talk about it as it recently happened with me.
I received the following email from a friend on Facebook (FB). When a user on FB sends an email with a link, FB prefixes the link with its own URL: http://www.facebook.com/<sometext>/<original link>
As any normal user I clicked on the link thinking what it must be.
The link redirected me to the following page:
What this page was trying to do was: it displayed the message “Content requires Adobe Flash Player 10.37…”.
If the user clicked on ‘Install’ it downloaded a “setup.exe” file.
On double-clicking it, it would have tried to infect your PC.
If you look at the page closely there are number of issues in there to help the user identify that it is a phishing page.
- The title of the page (on top left) is spelt wrongly – YuoTube
- User has used Facebook’s icon as the website icon
- The link/URL is neither Facebook.com nor Youtube.com, in fact it is just an IP address
- Message “…Contect requires Flash Player…” is itself embeded inside a flash video. As in flash is already installed and running on the page.
Hacker has tried to make the page look as similar as possible to Youtube, but it fails big time. Above are some of the quick noticable items, but this page actually nowhere close to a real Youtube page.
TIP: The best way to identify if it is a phishing site or not is by noting the domain name of the website. If the domain name does not sound familiar to the site you were supposed to be at then there is something wrong.
There have been numerous debates on the topic of Testing v/s Quality Assurance (QA). Like: QA has bigger scope than testing, testing is more effective, QA helps find issues earlier, etc.
As per my understanding the commonly accepted argument is that ‘testing’ is something that comes at the end of the SDLC. It is the process of executing manual or automated, functional or non-functional testing. It is (mostly) conducted by specialised testers. Testers may be involved in the process from beginning, they might or might not have much input to make, but the actual testing only occurs at the end. If the development is iterative then multiple iterations of testing. But the bottom line is that testing always occurs at the end when developer passes on the piece of development to tester for testing.
Whereas QA is from the day the project is initiated. Depending on your environment, if there is lot of ‘business as usual’ (BAU) or maintenance stuff happening then I would like to say it is the on going process.
In our Applications team we believe in ‘QA’. We understand the importance of it and the advantages of implementing it. In order to achieve that the QA team recently released the new QA process where we have ‘quality control’ measures at various stages of SDLC. Various roles within the team have been given the responsibility of QA at different stages. An example of which is that Solutions Analysts (SA) are responsible to QA a Business Analyst’s (BA) work and a Developer will QA a SA’s work. As in the person next in the SDLC process QAs the work of the person before him.
Some of the advantages of QA are:
- Transperancy
- Early involvement of people
- Early feedback
- Find issues early
- Lesser cost of fixing issues
- Quicker delivery
Below is the QA process that we have come up with. It is just a high-level representation of the actual process, which is like 38 steps long. This process has inputs from the QA team, BA team, all the managers of our group and the Project Management office.
I am a big fan of Exploratory Testing and I certainly agree with the author (of the following post) that it requires lot of self-discipline. Whether it is while planning, testing, analyzing or logging issues.
The only issue I have with exploratory testing is business continuity – what happens if someone else after you needs to come and do the job? I’d say the the tester should maintain at least some documentation to allow that.
Image Source
Some people when you say you do exploratory testing immediately think ad-hoc testing. I suppose because there is less emphasis on obvious structure and at the end there is little tangible evidence of testing performed.
But in my view, there’s a lot more to exploratory testing than wandering aimlessly through an application looking for bugs. As well as mentally challenging, it requires a lot of self-discipline.
Here’s why you need self discipline:
1) You need self-discipline to test the parts that are not as interesting to you, or not as fun. It’s easy to overlook and ‘forget’ them when other parts are more appealing.
2) You need self discipline to give each bug the time it deserves before racing off to find new ones. Time to analyze, examine and understand. Only then, can you go and look for new bugs.
3) You need self-discipline to write up bugs when they are found, instead of leaving them until later or when you feel like it.
In my view, in exploratory testing, as in many other ways of testing, its the mission and the stakeholder that count and their needs must come first.
What’s different is that instead of relying on documents and reports, you need discipline to make sure you meet those goals.
Source
Recent Comments