One more expected result to your test case

One of the most common test cases that we see is

Test Step: 

1. Launch the url of the app under test
2. Enter valid credentials in the login and password fields
3. Click Login

Expected result: User should be able to login

Alright, you just have one expected result.  Is that all there is to it?

The answer is a big NO.

As testers we need to have a 360 degree view.  One part of which is to look at the logs just for the login test written above

The expected results could contain the standard apis, and any ‘stuff’ that should  be running in the backgound for the login feature.

Unfortunately, most of us look at logs only when we see a bug.

Automation can definitely help for a lot of test cases.

Manually, for High priority cases to start off with.

 

 

Debunking the myth: There is only one system!

I have always been intrigued by a question –  Are there hidden systems?

I would say, sometimes – Yes

Why is this useful to a tester? It serves as one more layer of perception which could explain an existing feature, or a hidden functionality.

Lets talk of a real life example.  One of my colleagues went to get his blood tested in a lab.  He paid for the tests and got a receipt, which had an id number on it. He took this receipt and went to the lab assistant who would collect the blood samples.  The lab assistant collected blood in a vial and marked a number on it, the same number was then written on the receipt also.  This number was different from the receipt number, which made my friend ask “Why 2 numbers?”  To which the lab assistant said, that is for  “our reference”.  This new id used by the assistant was all that was needed to track the blood sample, ever since it was collected, to storing it, till the point of creating the reports.  In the event, my friend wanted to know the results of his blood test he had to make a phone call to the lab and provide the receipt number and answer a few questions before he could get his results.

Now the point in telling you the whole story is that, Have you ever wondered what could happen to an entity in a system, once it has been assigned a unique id? For all you know it may not be as unique as you think.  Whenever you come across a system do not rule out another system (internal or invisible or ghost or whatever you may call it) which may be using a whole new id to keep track of whatever the hidden system is supposed to do before it spews the result out to the “visible” system.  Even if you consider modelling this entire workflow of a person going to the lab for a test up to the point of collecting his reports, there are different systems that may have to interact and each system may have its own id and recognition methods for a particular instance.  Many a time we tend to overlook this, thinking that there is only one system at work.

 

 

Mobile testers could end up breaking their fingers

What would be common between testing a desktop application and a mobile application?

Mobile testing is the new trend in software testing as millions of applications are being developed for all kinds of platforms.  The interfaces are touchscreen and the keyboard? congested.  So when a user wants to enter text for an email he has to struggle with different things such as switching from numbers to alpha characters, finger overlap leading to entering the wrong character on the keyboard.  Irritating huh?  Guys, the screen is just 3.7 inches to a little more in most handsets how else do you expect a keyboard NOT to be congested.  Me thinks there is a workaround for this.  Voice typing.  Interfaces to phones also contain a voice to text converter wherein the text appears on the screen as the user says it.  This could greatly reduce the frustration involved in writing.  Moreover the world is moving towards Natural User Interfaces for all we know.  So guys lets come up with ways to test a mobile phone using voice to text converter. Watch for my blogs on this.

Best practices – a bane or boon?

Many a time I have wondered what these best practices really serve.  Is it a “one size fits all ?” or is it a way to earn money from unsuspecting customers, or is it a process like taking a daily walk, eat fresh fruit and vegetables which seems to keep a human healthy.  The answer, according to me is that all the above statements can be true.  As testing becomes context sensitive, one must customize the processes according to the context/situation.  Unfortunately there are some managements which do not understand Context sensitive testing and end up listening to the consultants who they just hired, and that would be to involve unnecessary processes which only end up as a time consuming task, and leaves the tester with little time to do what they were hired for, and that is “Testing”.  Of course the other option is to always ask the testers to “Stretch” themselves on weekends, and extra hours on weekdays too.  This kind of over-activity makes the tester frustrated and she plans to quit.  Some colleagues of mine, I know, are even giving up on the entire testing career due to this. This the result of poor expectation management.  Unfortunately a very important process like expectation management is completely overlooked in the desperation to get projects.

Interview Consulting

How many times have you been to  an interview (by invitation only) , only to find hundreds of candidates waiting for the interview which has only a few panel members to interview you? Well the answer is almost always.
How many times has it been that, in the situation mentioned above, most candidates leave as it takes too long?  The answer is almost always
How many times has it been in a situation mentioned above that, you find out that your CV has not been screened and you have been asked to leave as your skills do not match, that too after waiting for  more than a few hours on a weekend, when you needed time for yourself? The answer is almost always.

The above mentioned issues affect all kinds of companies Large, Medium and Small.  The problem is getting hold of several panels that can handle crowds that run into anywhere from a few hundreds to more than a thousand candidates on a  given day. On such a day some elimination tactic is used and unfortunately some really good candidates get eliminated.   This tactic is ad hoc and no clear guidelines for either selection or elimination. It’s really depressing!

However, I am of the opinion that such companies should use an idea called interview consulting.  Interview consulting could involve people with some years of experience in the relevant field who can freelance as interviewers also.  These people can be advised by the HR for the expectations that need to be met and guidelines they could use.  This can reduce the logjam faced by the candidates at the interviews.

Learn Software Testing in just 30 days! Fast track options available

The trainer has been in the IT industry for more than 9 years, most of which have been in Software testing.
Location: Bangalore
Training type: Open House – everyone is welcome
Contact ezeetester@gmail.com
blog: https://ezeetester.wordpress.com

1. Software Development Life cycle -Different types and their impact on testing
2. Types of systems
3. Risk Management
4. Manual testing of products
5. Test Processes – Understanding requirements,Test plans, Designing test cases – various methodologies, reporting results
6. Hands on training on all of these
7. Test strategies and test levels- Regression testing, Integration testing, System testing,
8. Estimation techniques
9. Defect life cycle
10. Writing effective defect reports
11. Virtual management
12. Bug advocacy
13. Need for multiple methods of communication
14. Preparation for interviews

Case studies based on real life situations in testing projects.

Preference will be given to people who have access to a system.

Does the future of testing move to iPads and mobiles?

The PC age is over, or is it?

Most of you who have been looking  into newspapers, periodicals etc. are already aware of the waves that tablets are making.  At the same time you have sophisticated phones coming up every now and then.  The future will require testers who can test applications on the mobile phones and tablets.  Meanwhile, what would happen to the grand old PCs and laptops.  The answer is all of them are here to stay and co exist.  I for one would any day prefer a PC to write and read content, because that’s what it is meant for, serving different purposes.  For a quickie message, chat, viewing movie clips and games you will probably prefer a tablet or mobile phone.  Tablets have other uses too they are also being considered to work as menus in restaurants.  Can you use a PC here?  Well definitely, but it would consume space and look out of the place in the days to come.  So what is all of this in it for a tester?   Testing needs to be done more in terms of accessibility and GUI, as these would have a heavy bearing on the kind of users who would opt for visually pleasing and easier navigation.  Yes speech to text conversion and vice versa also could become an important feature in these devices as writing on tablets or mobiles can be a big pain.  This clearly shows testing could move from the more rudimentary forms of testing to sophisticated levels in which testing would be done on speech to text conversion, and vice versa.  Testing could also move to 3g and 4g networks too!

Where are positions for a Test Manager?

In an earlier post I had mentioned that off-shoring testing may not remain a low cost option after all.  If you look at the positions being offered for testers with very good people skills and more than 7 years experience, you may find very few test managers.  Although these experienced testers earn slightly higher than their juniors, they have to contend doing  the same kind of work.  They also get fancy titles but no challenging work.  Then how would a tester grow from this point?  One way suggested  is to move up the corporate ladder.  The question is how? and in what direction?  There are some possibilities.  Unfortunately, only “some”.  As they say it gets ” lonely at the top”.  Why is it lonely?  Some organizations have cut down on the need for a Test manager by letting the project manager take care of Test Management also, this reduces the need for a Test manager, and hence cost savings.

Is Attrition rate related to certain facilities being knocked off?

In a recent incident, I came across a situation where the office of a company A (name withheld), stopped providing facilities to a city (lets call it some_city), but continued providing the same facility to other parts in the country. In fact it was a very basic facility to track the candidate’s status on the web. This led to lot of people in some_city using the telephones which were ever busy. This led me to wonder why would a company A do this? Company A cannot afford to upgrade its website for residents of some_city because of too many people moving in and out of different addresses in the same city, these are the same people who have been switching jobs too. A fact that is not done on such a huge scale in other cities including metros. The answer was simple no upgrade, no performance testing, no skulduggery, and most of all no expenditure. Anyone who needs help can call or visit in person. Yes, the load is being re directed towards phones and personal visits but the very thought of calling and waiting or visiting the office is making a majority of them willing to postpone availing the facility.

Error, defect, and failure

Many a time,  I come across this question from people who are experienced in testing.  The difference between error, defect and failure is distinct, as they happen in different stages of a software development life cycle.

An error is introduced by the developer during the coding phase of the Software Development Life Cycle (SDLC)

This error if undetected, creeps into the testing phase and is referred to as a defect/bug

Finally when this defect/bug creeps into the Production phase or live phase – it is a failure.

The production phase is the phase where the end user or the user for whom the software was intended to, starts to use the product. Ex: If you bought a new software (available in a CD format) you install it on your machine, and start using it;  You find that, after a while, the software crashes or some functionality of the software does not work – this is a failure.  Had this issue been caught by the tester it would be a defect/bug.

Had this issue been caught at the development phase it would have been an error.

An analogy in failure can be shown in  the automobile industry, when a customer was driving a Tata Nano, and it caught fire in the middle of the road.