REAL ESTATE SOFTWARE MARKET 2015 TO GROW AT CAGR OF 5.04% BY 2019

Global Real Estate Software Market 2014-2018, has been prepared based on an in-depth market analysis with inputs from industry experts. The report covers the Americas, and the EMEA and APAC regions; it also covers the Global Real Estate Software market landscape and its growth prospects in the coming years. The report also includes a discussion of the key vendors operating in this market.

Global Real Estate Software market to grow at a CAGR of 5.04 percent over the period 2013-2018.

One of the key factors contributing to this market growth is the easy access to real estate data. The Global Real Estate Software market has also been witnessing the growing demand of real estate software in the corporate end-user segment. However, the issues pertaining to data security and privacy could pose a challenge to the growth of this market.

Commenting on the report, an analyst team said: “Several corporations including those from Communication, Financial Services, Energy, and Healthcare, use real estate software to manage their real estate portfolios including manufacturing locations, distribution locations, R&D locations, and regional offices. In the last few years, these corporations have begun focusing more on real estate software technology. The demand for real estate software is growing in the corporations in order to reduce the overall cost of real estate and also to perform better property site searches.

Request For Sample Report Here: http://www.marketresearchstore.com/report/global-real-estate-software-market-20142018-1058#requestSample

Geography is one of the most important factors for any property site search, whether it is an office space, where the commute times of the executives have to be considered, or the location of a R&D facility, or the location of a warehouse that needs quick access to a highway. The corporate real estate end-user segment is highly fragmented in terms of its requirements and requires specific solutions for each requirement. In addition, creating appealing workspaces with ergonomic design is a top priority for leading real estate corporations. Real estate vendors provide IWMS to corporations in order to effectively manage key metrics, such as total square footage and vacancy status for workspace creation.”

According to the report, one of the major drivers is the easy access to real estate data. Due to the presence of a large amount of data, enterprises need software to automatically track the performance and behavior of the information stored in their IT systems. They require the software to manage online sales and purchases of properties and thus improve their overall operational efficiency.

Further, the report states that one of the major challenges in this market is the issue pertaining to data security and piracy. Enterprises are very skeptical about sharing their confidential data since most of the real estate data deals with financial planning, budgeting, and contract management. In addition, most of the providers in this space are SaaS/web-based solution providers. In a SaaS-based model, there is always the risk of information leakage, which could result in unauthorized access and misuse of organizational data.

Access Full Industry Report @ http://www.marketresearchstore.com/report/global-real-estate-software-market-20142018-1058

The study was conducted using an objective combination of primary and secondary information including inputs from key participants in the industry. The report contains a comprehensive market and vendor landscape in addition to a SWOT analysis of the key vendors.

The key vendors dominating this market space are Accruent Inc., Argus Financial Software, MRI Software LLC, RealPage, Inc., and Yardi Systems Inc.

Other vendors mentioned in the report are AMSI Property Management, CoStar Group, Fiserv Inc., IBM Tririga, Oracle Corp, Trulia, and Zillow.

Read more »

Q-COE – ANOTHER BOOST FOR MALAYSIA’S REGIONAL SOFTWARE TESTING HOPES

The Malaysia Software Testing Board (MSTB) has unveiled a Quality Centre of Excellence (Q-CoE) for software quality during the opening of the recent Software Testing Industry Stakeholders Consultation (STST) 2015 held in Kuala Lumpur.

MSTB president Mastura Abu Samah said the Q-CoE will “be a manifestation of knowledge capital garnered from projects and activities carried out under the Malaysia Software Testing Hub (MSTH) initiative”, which have been augmented through collaborations with various international partners such as University of Memphis, USA, German Testing Board, Japan’s Association of Software Test Engineering, Korea Testing Laboratory and University of Duisburg-Essen, Germany.

Mastura said the Q-CoE was a natural progression in MSTH implementation after focusing on building up the soft structure necessary to enable growth of Malaysia’s software testing industry.

The centre will engage all stakeholders of Malaysia’s software testing ecosystem and it is expected to play a role in driving the development and growth of Malaysia’s software testing industry through knowledge-centric strategies and approaches

“Over the last five years, discussions at STST have help propelled significant movement in growing awareness and demand for Independent Verification and Validation (IVV) services in Malaysia,” Mastura  said, adding that such constructive engagement continues at this year’s forum.

STST 2015 featured keynotes from Professor Dr Jasbir Dhaliwal and Associate Professor Dr Robin Poston, both from University of Memphis, USA, as well as Dr Suhazimah Dzazali, deputy director general (ICT) of the Malaysian Administrative Modernisation and Management Planning Unit (MAMPU).

“I urge all stakeholders to leverage on the STST 2015 platform to provide input for refinements and new plans. It is prudent to highlight our needs and interests, and make recommendations that will contribute towards growth of the industry. Opportunities are there and if we play our cards right, each of us will stand to prosper in our own right,” she added.

STST is organised by the MSTB, in collaboration with the Economic Planning Unit (EPU) of the Prime Minister’s Department, Standards Malaysia and MAMPU. The STST forum was introduced in 2010 under the patronage of the MSTH and serves as platform for stakeholders’ consultation on software testing industry development programmes initiated under MSTH.

Read more »

Today's Resume tip

Today's Resume tip ...

I was going thru a set of resumes for test engineer position. Following are few things that I really find un-appealing and takes off my interest. I suggest to my fellow test professionals (others in general) - watch out for these (irritants) and if you are convinced that what I am saying makes sense - Clear your resume TODAY....

1. Open your resume in Word and search (Ctrl F) for words like "Involved", "Participated" etc. and delete the sentences containing them. The recruiter is not interested in what all are you were involved or participated - but he/she would like see "what you achieved" by doing that. Here is a way to rate your resume - Give one negative mark every time you encounter such word in your resume. How much did your resume score? Now do you understand why you are not getting enough interview calls?

2. I will not press very hard for this one - but if you do it is better. Get rid of words like "was Responsible for" or any variant of "Responsibility". What attracts recruiter is action word - "Achieved zero Downtime for systems I was responsible for" v/s "I was responsible for maintaining systems and ensure that downtime was low”. Notice the power of action. You will be delivering the same message but in a power packed way. That catches eyes of who "matter" in getting you a new "dream "Job. It is very important that you load your resume with these power packed action words, lots of them - especially in first 1-2 pages.

3. This one is the most "useless" part of resume if it is present. Writing paragraphs about the application that you tested with the names, versions, modules, detailed functionalities. Looks like a copy paste from functional specifications or SRS (System Requirement Specification) of the software product that tested. Watch out, some times this might land you in legal issues with your employer dragging you to court for leaking strategic product information to public - via your resume. This is big TURN OFF for the reader - especially a recruiter who would process and see thousands of resumes in a day.

Don’t forget the thumb rule – 1 page of resume for every 2 years of experience. So a person with 8-10 years of experience should not have a resume that exceeds 5 pages. Less and crisp is better and easier to read.

Enough? Open your resume and sanitize it TODAY.
May God bless you with job offers and interview calls pouring all the way !!!

Read more »

CONTEXT-DRIVEN TESTING AT A CROSSROADS

CONTEXT-DRIVEN TESTING AT A CROSSROADS

Cem Kaner, who controls www.context-driven-testing.com, has announced an interesting change in his view of the Context-Driven School. He says he prefers to think of it in terms of the Context-Driven approach, not a school of thought. This is a significant change from his original view, which was that CDT is a different paradigm.
That means I’m the last of the founders of the Context-Driven School, as such, who remain true to the original vision. I will bear its torch along with any fellow travelers who wish to pursue a similar program.
Polarization? No. Paradigm!
One of the things that concerns Cem is the polarization of the craft. He doesn’t like it, anymore. I suppose he wants more listening to people who have different views about whether there are best practices or not. To me, that’s unwise. It empties the concept of much of its power. And frankly, it makes a mockery of what we have stood for. To me, that would be like a Newtonian physicist in the 1690′s wistfully wishing to “share ideas” with the Aristotelians. There’s no point. The Aristotelians were on a completely different path.
For me, Context-Driven thinking is delightfully about listening to people and talking to people about practices and dynamics of software testing. But this must happen within the humanist framework that we laid out in the seven principles of the Context-Driven school. That’s our world.
Polarization is beside the point. Polarization is a natural consequence of the fact that our world view is simply different. We are a different paradigm. Our paradigm cannot be explained or contained by any other testing paradigm, such as the Factory School, or the Analytical School. We must have the stomach to keep moving along with our program regardless of the huddled masses who Don’t Get It.
Why Is This Division Happening Now?
Cem’s change of position is happening partly because, after 16 years, he and I are no longer collaborators. Due to a simmering personal dispute (nothing to do with testing) that blew up last year, we no longer can stand to be in the same room with each other. Alas, I don’t think this will change. What that means, professionally, is that the conversations that we once had– the passionate arguments– which led to mutual accommodations and syntheses, no longer happen. This is too bad, because the Factory schoolers, who greatly outnumber us, will make good rhetoric out of any appearance of confusion between Cem and I about our visions of testing.
Meanwhile, I will say this about Cem: He’s a great man. His contributions to testing have been enormous. I disagree with him on some aspects of testing, but by and large he does great work. I’m sure if he weren’t so furious with me and I were able to talk to him without feeling an overpowering urge to kick holes in walls (I mean that literally), we would still be able to develop testing ideas together. However, I trust that whatever he does will be worth looking at. And I do have many other bright collaborators, so I’m going to be fine.
The Context-Driven School continues, because I, and those like me, are compelled to pursue excellence wherever it leads us, even if that means breaking with “conventional” software testing thinkers. I wish Cem luck as he consorts with those guys, but I fear his time will be, for the most part, wasted.

Read more »

A study on Test Coaching in India

As I am exploring the options of coaching testers in organizations through workshops that exercise a testers mind (that includes me too), I had a learning that I value and I am sharing with you here.

I never received any training as a tester in all the companies I have worked for but did train few people as an employee of a company. I have seen e-mails from the HR - Training, announcing coaching on programming languages from external people who have a reputation of handling the class well.

Does this happen to testing too?

Yes, it does but what is being taught is a traditional approach and concepts of testing. Many Indian testers think there is nothing beyond "SDLC, V Model testing, Types of Testing and Testing definitions" to learn in testing.

I wouldn't say the above training is not good enough but instead I would say, "there is more important thing that a tester should be trained on, *acquiring new skills* to test any product". ( provided you would want your testers to do a skilled testing)

We define, a good tester as someone who knows all the definitions and is able to clear a few certification programs.

Certifications arise for a commercial value and I am not sure how much value it holds except that it can fetch you a job if the person who interviews you also holds the same certification. I know a person in India, who has 14 brainbench certifications on fields like Software Testing, Project Management.... and I am not sure what this certificate means. Does it mean you know something about the syllabus or you know most of the things in the course.

When experts like Cem Kaner, James Bach, Jerry Weinberg, Michael Bolton, Mike Kelly, Jon Bach, Mike Kelly, Elizabeth Hendrikson... might say, "there is lots to learn", I am not sure if the certification really matters when you yourself know you are a good enough tester.

In the last one year, the awareness to become a skilled tester is rising amongst testers in India and by the end of 2007, "skilled testing" is the way any Indian tester would want to think about testing.

Who is helping testers to become high skilled?

There are 5 people -

• Tester
• Manager
• HR
• Training and Development department
• Test Coach

I could see testers who have interacted with me or are my blog readers, proposing my workshop to their teams and across organization. The chain reaction came from their managers by proposing the same to the HR and or Training and Development department. Now the HR is going to play an important role in providing the workshop to the testers in their organization.

I am sure all the above 5 people would work hard enough to grow skilled testing within you and me. James Bach once coached testers in Wipro and Mindtree during his visit to India in 2003 and since then many testers in India have been awaiting his next visit. Michael Bolton too presented Rapid Software Testing in India last year and now he is going to speak in the international testing conference, Hyderabad - Dec 8 and 9. Shrinivas Kulkarni has spoken in a lot of conferences worldwide and to me he looks someone has been living with automation for a long time and that is cool to live with what you are passionate about.

Its mercury rising, Catch up with the heat!

I love to share my experiences and learning with you all. Now that I am becoming an independent test consultant, it helps me do this much better and efficient. Help me to help you ;)

Read more »

A test is an action which produces discoveries that can be used to evaluate product quality.

I like that this definition identifies action, discovery, and evaluation as being core to testing. However, I'm thinking of pushing, or rather constraining, this just a bit further.

What if we were to say that the evaluation is the action and discovery is the goal?

A test would then be the sapient part of validation or investigation -- the thinking and learning that cannot be automated. All those other things we do to test are really support activities that help us evaluate.

Test is not a document. Test is not code. Test is not executing a program. Test is not applying a procedural decision rule. Test is not anything that can be done by a machine. Test is the act of evaluating that requires sapience.

Test is thinking and learning that leads to discovery. We may test by evaluating existing data. We may test by running experiments that produce new data. We may take the output of automated checks to test. We may provide what we learn as input to coding new automated checks. The test is the action we perform in our minds.

This may come across as nitpicking vocabulary. That's not my intent. My goal is not to limit anyone's definition of test, but rather to shed a different light on what I believe sets testing apart from checking, and gives both checking and testing value.

If a check fails in a forest and no one is around to hear it, does it make a sound?

The true value of our checking and testing is in the mind of a sapient tester. What value is there in all the things we call checks and tests without a tester (whatever their role or title) evaluating information and learning?

Read more »

Database Testing

As a tester, you have to test the ‘Examination Results’ module of the website of a university. Consider the whole application has been integrated and it is in ‘Ready for Testing’ state. ‘Examination Module’ is linked with ‘Registration’, ‘Courses’ and ‘Finance’ modules. Assume that you have adequate information of the application and you created a comprehensive list of test scenarios. Now you have to design, document and execute these test cases. In ‘Actions/Steps’ section of the test cases, you must mention the acceptable data as input for the test. The data mentioned in test cases must be selected properly. The accuracy of ‘Actual Results’ column of TC Document is primarily dependent upon the test data. So, step to prepare the input test data is significantly important. Thus, here is my rundown on ”DB Testing – Test Data Preparation Strategies”.

Properties of Test Data:

The test data should be selected precisely and it must possess the following four qualities:

1. Realistic: By realistic, it means the data should be accurate in the context of real life e.g. in order to test ‘Age’ field, all the values should be positive and 18 or above. It is quite obvious that the candidates for an admission in the university are usually 18 years old (this might be defined in requirements).

2. Practically valid: This is similar to realistic but not the same. This property is more related to the business logic of AUT e.g. value 60 is realistic in age field but practically invalid for a candidate of Graduation or even Masters Programs. In this case, a valid range would be 18-25 years (this might be defined in requirements).

3. Versatile to cover scenarios: There may be several subsequent conditions in a single scenario, so choose the data shrewdly to cover maximum aspects of a single scenario with minimum set of data, e.g. while creating test data for result module, do not only consider the case of regular students who are smoothly completing their program. Give attention to the students who are repeating the same course and belong to different semesters or even different programs. The data set may look like this:

Sr#	Student_ID	Program_ID	Course_ID	Grade
1	BCS-Fall2011-Morning-01	BCS-F11	CS-401	A
2	BCS-Spring2011-Evening-14	BCS-S11	CS-401	B+
3	MIT-Fall2010-Afternoon-09	MIT-F10	CS-401	A-
…	…	…	…	…

There might be several other interesting and tricky sub-conditions. E.g. the limitation of years to complete a degree program, passing a prerequisite course for registering a course, maximum no. of courses a student may enroll in a single semester etc. etc. Make sure to cover all these scenarios wisely with finite set of data.

4. Exceptional data (if applicable/required): There may be certain exceptional scenarios that are less frequent but demand high importance when occur, e.g. disabled students related issues.

Test data preparation techniques:

We have briefly discussed the important properties of test data and it also elaborates how test data selection is important while database testing. Now let’s discuss the ‘techniques to prepare test data’.

There are only two ways to prepare test data:

Method 1. Insert New Data:

Get a clean DB and insert all the data as specified in your test cases. Once, all your required and desired data has been entered, start executing your test cases and fill ‘Pass/Fail’ columns by comparing the ‘Actual Output’ with ‘Expected Output’.  Sounds simple, right? But wait, it’s not that simple.

Few essential and critical concerns are as follows:

1. Empty instance of database may not be available
2. Inserted test data may be insufficient for testing some cases like performance and load testing.
3. Inserting the required test data into blank DB is not an easy job due to the database table dependencies. Because of this inevitable restriction, data insertion can become difficult task for tester.
4. Insertion of limited test data (just according to the test cases needs) may hide some issues that could be found only with the large data set.
5. For data insertion, complex queries and/or procedures may be required, and for this sufficient assistance or help from the DB developer(s) would be necessary.

Above mentioned five issues are the most important and the most obvious drawbacks of this technique for test data preparation. But if there are some advantages as well:

1. Execution of TCs becomes more efficient as the DB has the required data only.
2. Bugs isolation requires no time as only the data specified in test cases present in the DB.
3. Less time required for testing and results comparison.
4. Clutter-free test process

Method 2. Choose sample data subset from actual DB data:

This is the feasible and more practical technique for test data preparation. However it requires sound technical skills and demands detailed knowledge of DB Schema and SQL. In this method you need to copy and use production data by replacing some field values by dummy values. This is the best data subset for your testing as it represents the production data.  But this may not be feasible all the time due to data security and privacy issues.

This strategy deserves one separate post which we’ll discuss in next article ‘Database gray-box testing’ and precautions to take while testing database.

Read more »

Story of how a hang becomes a crash (because testers love reporting crashes)

Story of how a hang becomes a crash (because testers love reporting crashes)

I am doing my first exploratory testing workshop for 2011 and first from Moolya Software Testing Pvt Ltd. and I am excited about it. . If you are in India and plan to attend it, please do it quickly. I usually don't take a lot of participants although I know I'd gain more money out of more participants. Ever since I announced it yesterday, there are 4 seats that got filled within 5 hours.


Now, I am going to tell you a story that I had been hiding for quite a while. Not intentionally hiding but was planning to blog about it and the time is right now :)


I provide many applications to test in my workshop. At the end of a testing session, I check with the participants if they found any crashes with the application. Not to be surprised, a room full of testers, they do report crashes.


I ask them to reproduce it with me watching what they do and here is a shocking information; most of what they report as crash weren't crashes at all. What you are about to read is also a great example of confirmation bias that I have witnessed.


Here is what they are doing: They are performing an input constraint attack or providing a large set of characters as an input to a field and hits the "Submit" button. They wait for 10 seconds to see what the application does and on seeing the application in not responding state, kill the application and report that as a crash. 


Awesome! Isn't it?


Now, I got conscious of the fact that testers seem to be reporting a hang as a crash and was keen in looking at live projects during my consulting assignments. I get access to the bug tracking system during my consulting (wow) and I see patterns of such reports. 


I go filter out some of the crash reports from the bug tracking system and try to attempt what the tester did to report that type of a crash and bang, that's a hang.


I have made this point to testers who attend my workshop in order to help them be more conscious of what they are seeing versus what they are reporting versus what they are eager to report versus what they should be reporting. 


It seems to me that testers have an anxiety to report crashes. There's nothing wrong in it but it goes horribly wrong when you report a crash by fooling yourselves and the people around you. I recently blogged about the Obsessive Checking if being mentioned disorder that I was suffering from and here is a relevant excerpt from it, "Months later, I started replacing every word by my name till I saw my name on others post. So, I may have read a few posts without actually learning anything from it because all I saw is "Pradeep" & "Tester Tested" on those posts."


Now, why is that relevant to this post? I see that the testers I have witnessed who report hangs as crashes also appear to have a similar problem of obsession towards reporting crashes that they appear to not see a hang but see a crash. I would love if you ask if these testers ever report a hang? Yes, they do. If an application recovers before they kill, that's a hang.


I understand that an application might have hanged because it has crashed but how do you know? Oh yeah, allowing the GUI to fool you and me?


Here is an excerpt ( and tweaked to hide confidential information ) from an issue that I reported on Sep 30, 2010 @ 12: 13 PM IST (thank you Jira) while testing a new OS that is soon to be launched. No, not Chrome OS.


"I opened Media Player application and made an attempt to subscribe to a podcast. 
The application appeared to hang and it also did not allow me to close using the X mark on top right corner.


In an attempt to kill it, I navigated to XXXXX (product name masked) and tried closing it from there. However, the XXXX is open and Media player still seems to be remaining in the hung state.


From that point, I might be forced to reboot the system to get out of it or can escape by waiting for a longer time that I waited for Media Player to recover (>5 mins). No user to my knowledge would wait for more than 5 mins to see the Media Player function. Even a reboot appears to be a faster option" 

Now, if that was the Description, here is the summary :

"Unable to kill a XXXX when the application in it appears to hang or is busy"

• Why I posted the above? Is it because I wanted people to note the usage of the word "appears"?
• Why did I make a few words in it bold? Is it to highlight it?

Long ago, well, not so long ago, I blogged about how teaching testing is helping me test better. The above post and the bug report I posted, is another example of how teaching testers has helped me do it a lil better.


Now if you are going to be sitting at my workshop and be worried if you are going to make mistakes that I am going to highlight, please be informed that you are paying to my workshop to get into the safest environment to fail. No managers watching you. No clients frowning at you. No appraisals being done. Just your own dream of personal excellence aching you for not being there yet but being happy that you know why you are not there. Its a wonderful feeling.

Read more »

Indian testers STEALING a testers creativity - STOP THEM

Indian testers STEALING a testers creativity - STOP THEM

Hi Reader,

It is very disappointing to note that my article Technology that failed in India (Testing Bowl of the world) is under circulation among Indian testers through e-mails.

Now, why am I disappointed about my article being circulated all over India?

The people who are forwarding it are changing their own name and forwarding it. Now, if you are a Tester Tested reader and want to encourage me to share such learning I had, you should take this seriously and pass it on to all those who have got the mail and also to those who are about to get the mail.

If Indian testers play such a spoil sport, its going to hamper the growth of Indian Testing community.

Hey come on, its my brain child. I cant let you steal the credit!

I am writing this pretty strong as I cannot find and catch all those Indian testers who are displaying the act of plagiarism.

This blog of mine has been encouraging so many Indian testers and if you disappoint me by plagiarism, I am sure you are making me hesitant to share my future learning.

I am not sure how serious you are going to take this since you are not affected yet. I just hope Indian testers themselves do not become a barrier to other Indian testers to achieve something that India can be proud of.

This is what Michael Bolton had to say on hearing this - "A tester without integrity is a tester without credibility--and a tester without credibility won't have a career for long."

He also mentioned that such an incident happened to Cem Kaner and the community of testers there in US and Canada took it up strongly to the person who plagiarised and the author had to step down from the association and the online magazine was held.

This is India, I cannot expect an immediate revolution, yet I am hopeful.

Read more »

Traditional Testing

Traditional Software Testing Process - The cash cow demystified

So, I don't need to tell you that most of the software testing in the world is outsourced. I live in Bangalore and I assume a considerable amount of the world's outsourced testing projects are here. I meet testers from most of these organizations and hear the same process of testing software although called by different names their organization executives named them.

Most testers I meet lament about the process (or sucked within it for survival ) and approach they are forced to follow and try talking to their management about better ideas and better ways to test. Those executives don't seem to listen much nor willing to change.

Wondering why they wouldn't?

They have hit a cash cow.

Mark Crowther and I were discussing about Code Coverage & Requirements Based Testing in Test Republic and some how drove me to write about the way most businessmen are fooling their customers through the process they love to follow.

So, here it goes with editing and expansion. Assuming Mark from UK or maybe even you outsourced a testing project to me:

• I would spend a couple of days analyzing your requirement document and bill you for X hours per person involved in my team.
• I would spend a couple of days writing a test plan document ( but not refer to it ) and bill you for 2X hours per person involved in my team for preparing it.
• I would spend a month or two writing test case document ( and refer only to it ) and bill you for 10X hours per person involved in my team for preparing it.
• I would then again create a traceability matrix ( just to fool you and your boss about our coverage ) and bill you for 5X hours per person involved in my team for preparing it.
• So far, total of 18X hours per person involved in the team is the billing.
• Assuming X is 50 hours and there are about 10 members in my team, that's 18 * 50 * 10 = 9000 hours of billing with no single bug found yet. ( Mark wrote about it, too )
  
• If you are paying $20 an hour per person on an average, you would have actually given me a business of $180,000 without me or my team finding any bug yet.
• So after investing $1,80,000 on me and my team, you would want some benefits of that. So, you wouldn't pull the project out or move it to another vendor because more or less he would do the same and you would end up paying another $180,000
  
• Then comes the test case execution cycles for our documented 10,000 tests out of a possible hundred million tests
  
• For every new bug that you find out of the releases I make, my team would spend documenting the new test case, getting it reviewed and resulting in slower testing for you and more money for me.
• So assuming running 10,000 tests take 2 weeks for a team of 10 members to execute. Also assuming least 50 cycles of testing, you would have paid me about $140,000 for a coverage whose value might be not worth of the money.
• Of course there is additional documentation of missed test cases and other template filling activities that will be billed to you.
• To fool you further, I would instruct my team to use some expensive license based tools ( what else will I do with the money you are pumping in ) to give you a sense of faster testing ( by foolishly comparing it with human speed of testing ) and call it "Automation Testing". It turns out that these tools could have helped me find bugs that are of not a great value to you but hey, we want to see test case pass more than fail.
• Your coverage isn't improving much because we have converted manual tests to automated tests ( although its not the same test ) but to show you the speed of our tools.
  
• So think about adding another $25,000 and giving you an illusion of an ROI of $100,000 while pumping multiples of $100,000 from your bank account to mine.
  
• The CMM, TMM, Six Sigma, ISTQB scams are built around this eco-system to enable more money flow for hardly any value. Who knows there could be a cut for the people who know all this and yet do it.
  

Why wouldn't a businessman be glad about the traditional approaches to test software?

Are you asking about what happens to the users of the product?

• Lets bother about the users of your product later during our maintenance billing phase. Don't you know SDLC ends in Maintenance Phase? If we do everything right in the previous stages then how do we prove we follow SDLC when there is hardly any work in maintenance phase?
  

While you are reading this, you shouldn't be thinking of this happening only in India but in most parts of the world and even within places like United States and Europe. There are smart businessmen everywhere. At one end they pay us but at the other end use us to make more money. We need money and they need us to make that. Don't make smart businessmen exclusive to India and leave your own country out of it.

I hope those who outsource start pushing for services that doesn't fool them. Who would actually listen to this argument is testers turned businessmen and testers turned outsourcing heads and testers turned business leaders.

Whenever I visit a testing services company and see a testimonial of a customer who talks about the great ROI they got and faster testing, I wonder what a heavy price they paid to believe so.

Exploratory Testing ++ , Context Driven Testing ++ , Rapid Software Testing ++ or else YourMoney --

Don't want to be fooled by outsourcing software testing? One of those who could be of help to you among many folks I know, is myself.

Read more »

What all scenarios can be taken up for Login functionality testing?

A) As a user I want to log into the system so that I can get access to restricted functionality
•There should be a login form on the home page
•User enters email and password and clicks "Login"
•If the details are correct, they are logged in and the home page is redisplayed without the login form
•Their email address should then be shown at the top of every page "Logged in as ..."
•If either of email/password are missing or incorrect, and error message should be shown "Invalid email or password." (the same error message is used to avoid revealing information about which users exist in the database).
•If a login fails, the password field should be cleared but the email field left.
•Once logged in, the session should timeout after 30 minutes of inactivity
•Users who are either deactivated, rejected, or pending approval should not be able to log in (covered in other stories below also).
•If an account is deactivated or locked, logging in with an invalid password should display "Invalid email or password" (NOT "your account is not active")
•Attempting to access any page that requires login (while not logged in) should redirect the user to the login page. After successfully logging in they should be redirected to the page they originally requested.
(B) As a user I want to apply for access so that I can login into the system
Users who do not yet have access need to be able to request access. Allowing them to request access themselves has the benefit that they get to choose their own password so administrators do not have to deal with secure password distribution.

•There should be a "Sign Up" link shown on the home page when a user is not logged in
•It should take the user to a Sign Up form where they must enter:
•Email (must a valid email address, which will be used as their login id)
•Password (at least 6 characters, max 20, must include at least one of each of upper/lower/number/symbol)
•Password confirmation - must match password exactly
•First name
•Last name
•All are mandatory fields. Email/first/last should be limited to 255 characters, both in the form and on the server side. Password should be limited to 20.
•After correctly entering all fields and clicking "Submit Request", they should be taken back to the home page with a message "Thanks for requesting an account. You will receive an email when your request has been approved."
•At this point they should not yet be able to log in. If they try to log in they should see "Your account is not active."
•If there's any validation errors on the form, it is redisplayed with informative error messages and the account is not created. The two password fields should be cleared out each time this happens.

Read more »

Ants solve problems that testers struggle to!

Ants solve problems that testers struggle to!

Ants can go into corners of tables and chair, which we humans might not be able to.
Ants can travel to any country without a passport or Visa (if they manage to slip into someone's baggage).
Ants can live anywhere and yet not pay rent or property tax.
Ants can eat junk food forever and live happily.

Doesn't all of them sound so obvious?

So, here is something that might not be so obvious about ants... Little creatures that we commonly refer to as ants have solved a problem that many testers today struggle to.

Have you heard a tester say, "I haven't tested this before / this is too complex / I don't know how to start testing it".

The important thing to note is that we might have heard it from our own mouth or heart and sometimes from others, too.

Here are some experiments that I did with ants to see how they respond to complexity:

Experiment 1
I took an ounce of sugar, placed it near a colony of ants and observed what happened to the sugar I placed after a while.

My experiment resulted in each ant carrying a crystal of sugar and moved them to their nest. Sugar is all gone!

Experiment 2

I placed a cake of size approximately 1000 times bigger than an ant in the same place and observed what happened to the cake.

This experiment resulted in each ant breaking the huge cake into smaller fragments and moved it to their nest bit by bit. Cake is all gone!
Experiment 3

I put a piece of solidified sugar candy near the same colony, which was hard to break for an ant.

This experiment resulted in ants trying to break the candy to smaller segments, but probably the smart ants realized it to be complex than their earlier two assignments I gave them and then they all co-ordinated together and carried the candy to their nest. Candy is all gone!

I bet I could place a mammoth of food for them and they, without bothering about the complexity of it, would try moving it to their nest or create more nests and colonies to accomodate it or work a strategy to get it to their nest or much it as much as they can till the mammoth lies there...

Ben Simo, a wonderful tester you might already know, recently wrote a post titled Solving Intractable Problems and ended it beautifully by saying, "Start with what you recognize" - which I now think is what ants do instead of saying, "That food(work) is not for us, it is for bigger (skilled) ants"

After having done these experiments I was ashamed of my behavior of hesitating to test a product (which I did a couple of years ago) just because something appeared to be too complex or I thought I didn't know about the product or technology.

No, I said, *I* was ashamed and I am not going to ask if you were ashamed because you might have not done that.

After all they are ants and they don't have the super brains we have and lets ignore them folks and continue to live as happy as we are, complaining that things are complex.

Silly ants, they don't even know they are dealing with complexity. I think they should be ashamed of it.

Read more »

Interview Tips

I interviewed few candidates for my company. A few tips.

Usually interviewers form an impression on whether the candidate is good or not within 5 minutes of seeing and talking to him/her.Rest of the time, they try to validate whether their impression is correct or wrong(atleast this is what I do).So its important you make a good impression in the first few minutes.

Dress code

Well dress you wear for the interview is not everything, but you dress well, it will help you to make a initial good impression. The color of the dress gives certain impression, it seems(I don't remember paying attention to the dress, the candidate wore, but it seems it would have affected my impression at a subconscious level.But what you loose dressing up well)

• Red:You wear it to attract other people's attention.If you are presenting something or you want others to pay attention to you, dress in red. This is not the best color to wear for interview.
• Blue:If you want other people to like you, dress in blue.
• White:It gives the impression that you are hardworking.Wear this. I mean not entirely in white but the predominant color should be white.Like a black trouser and white shirt should do.

Resume

• Whatever you mention in the resume, you must try to be thorough in it.
• Be honest of what you put in it.
• Try to keep it small,it should not be longer than 2 to 3 pages.
• One of the main reason of rejection is, something is mentioned in the resume and when asked questions about it, not able to answer them and in few cases saying that "I have done that 'something' long back and I don't remember anything".In many cases its true that you have used a tool or something a year back and you don't remember much about it, in that case before attending the interview, brush up atleast some basics regarding it, do some home work and prepare yourself to talk about it or don't mention about it in the resume, if it is not that important.

Topics to prepare, for a entry level testing job.

Testing fundamentals: Testing terminology, definitions etc.

Testing Processes: The testing processes used in your current/previous company.Knowledge of life cycle testing etc.

Testing tools: Given a problem, how to solve them using testing tools.

Testing deliverables: Able to write a test plan or test case for a given product or requirements

Analytical skills: Solving Puzzles

Programming skills(optional): Able to write pseudo code for a given problem.

Few more tips

Good Communication skills: obvious isn't it

Good Listening skills or understanding skills: Able to understand the questions posed by interviewer. Try your best to understand fully what the interviewer is blabbering in the first say.But if what he says is not clear, better to ask or try to confirm what you heard is correct before answering.

Confidence level: Watch your body language, keep eye contact, don't be over confident just be confident.

Two most important tips: You should have the right skills for the job.Also equally important is you SHOW or DISPLAY in front of the interviewer that you have the right skills.

Read more »

Exploratory testing

Exploratory testing is not defined by any specific example of exploratory testing.

Just as tap dancing does not characterize ballroom dancing, you can’t take any one example of exploratory testing and treat that as representative of the entire concept of ET.

If you were to hear me singing an aria by Mozart, that would be an example of opera singing. It would be an example of BAD opera singing, but it would truly be an example of the style. Similarly, I regularly talk to testers who go “oh yeah I’ve seen that exploratory testing stuff but it’s not structured… not documented… not x… not y… not whatever.” And my reply is “you probably haven’t seen skilled exploratory testing. Would you like to hear me sing an opera now? OR, I could show you a good example of ET in practice.”

Exploratory testing can be done in an unskilled, slapdash, silly way. Just as a unskilled driver behind the wheel of a car is still a driver who is driving a car, a poor tester can still be doing ET– albeit probably not very well.

The cool thing about ET is that, even done badly, it’s still a great way to find some bugs. Michael and I try to help you do much, much better than that.

The core idea of ET remains as it always has been. It’s been expressed in many different ways, but boils down to this: test design and test execution and learning mixed together in a mutually supportive way. Whenever you see that, and to the degree that you see that, you are seeing exploratory testing.

Read more »