Tag Archives: Quality

How to Approach Automation?

Software Quality, , , , , , , , , ,

Test Automation

Automation, in true sense, relieves the person from manual efforts by regulating the repetitive tasks to an extent. Automation is the preferred choice in most industries and software may also be brought into the circle of automation, but without deviating from its actual definition. Automation should not become a costly affair for an engineer to perform.

So, here comes the big question:  “How to approach Automation? “

That brings us to the basics of Automation, i.e. what and when to automate. It is not possible to automate everything in software; however test scenarios those are time consuming and executed repeatedly can be considered for automation. GUI items, Business Critical test cases, connections with database, data validation generally make good automation stuff. Test automation should be done when the projects are large and critical to business, requires frequent regression testing, requirements are not changing frequently, load and performance tests needs to be included, and most importantly project build is stable.

It is required to follow a proper approach to create and execute automation test script so as to increase the efficiency in automating the software. Firstly, define the scope of automation, taking in view the test scenarios to be tested, technical feasibility, complexity and priority of selected tests. After defining the scope, test tool selection should be made depending upon the software interface and technology used. A proper framework is needed to execute automation scripts, so the framework implementation on the selected test tool should be undertaken.

Automation Steps

Tests always run in well-configured environment that supports the tool. Hence, configure the environment correctly and then related test data preparation should be done, to avoid any risks due to invalid data giving inaccurate results.

Automated test development consists prioritizing of test cases to be automated, writing of automation scripts, mapping those scripts with test cases and creating elaborate test suite. Tests then can be run either by using the Test tool or Test Management tools with test data as input and generate test reports for the analysis of the result. Test execution should always be supported and monitored to ensure it is done as per the scope of the automation. Lastly, maintenance of the scripts is done. With every build, scripts need to be added, modified or deleted to make the automation efforts optimally effective.

Therefore, we can maximize the potential of efforts made into automation by strategically planning the automation process. It is always advisable to correct the shortcomings in any process as early as possible to avoid unprecedented repercussion if same is done in later stages, as evident in case of software development models.

Happy Testing !

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

It isn’t Hard to Hard-code!

Software Engineering, Software Quality, Thoughts, , , ,

Recently I came across an interesting programming situation.

Parts of a web-based system stopped working suddenly, with nothing significant having changed. After some finger-pointing and accusatory guessing, it was discovered that some scripts on server side had been shifted from /root/1level to a deeper nested folder, let’s say /root/1level/2level. So far so good.

What happened next? Why would that make a system stop working?

Code needed to find path for some processing. The code split on first backslash to find file name, implicitly assuming that the file would always be one-level deep from root. When the file was shifted into a deeper folder, the path extraction stopped working.

There can be arguments about whether the admin should have shifted files into a deeper folder without informing developer, or why this should not have been done at all, and so on. But I consider this a clear elementary programming mistake of the hard-coding variety.

Hard-coding does not mean just typing in numeric or string literals into code, although that is the obvious college-level hard-coding. X = 420 or sEndDate = “1/1/2022”. It also means any type of inflexibility embedded right into the code and program. Hard-coding means not understanding the need for flexibility and not writing elegant code that can adapt to its surroundings.

Hard-coding is called “hard” coding because anything hard cannot be molded to suit the need at hand, because it is inflexible. Like when you put in an assumption that your file is one-level deep,, which makes it inflexible to run when its level changes.

What would be the right way to deal with this?

Step 1: extract path in a loop, so that you can handle any level of folder-nesting. You don’t assume you are N levels deep, because folder-level is not something that can be assumed! Instead you traverse the path to find how deep you are.

Step 2: Back-slash? Welcome to multiple OSs! The file-separator character itself is hard-coding. In every language worth its salt that runs on multiple OSs, you have operators to find environment variables including file-path separators. On Unix/Linux you are “/”, on Windows you are “\” or “/”. On Mac you had “:” long back during MacOS, and now you have “/” on OS X with its Unix core. And then I was on some Solaris/RISC machines decades back which used “.”.

Should you hard-code assumptions about N-level nesting and separators? Absolutely not.

Does it need extra time to write flexible code? Absolutely not. The amount of time you spend later in not writing tight right code in the first place, so much of debugging and frustration and rework – it would all be avoided if it were first-time right. And to write above path-extraction code in a loop with separator detection rather than hard-coding – you are talking about couple extra minutes. Take one less leak and you can find time to do the right thing!

Is it rocket science that an average programmer cannot do? Absolutely not. Once you decide to do things like this, it is pretty easy actually.

Then why do people not do it?

Because of mediocrity. A mediocre mind is happy with sub-standard work that somehow passes through. Because of lack of involvement. When you are pushed into a “career”, you are least concerned with your quality of work. As long as the next raise comes around, who cares! You are not a craftsperson to take pride in work, you are just a code jockey.

This, ladies and gentlemen, is the difference between a good software engineer and someone who just gets things to work. A good software engineer anticipates need for change and does things first-time right. A good software engineer thinks ahead and does things in flow during first-code which take very little additional time to do. A good software engineer does not hard-code, either directly as literals or indirectly as implicit assumptions.

Someone who is just a programmer does not do any of the above, and just somehow gets things to work – never sure when it will fall apart.

Now you decide what you want to do.

 

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Common Sense vs Bureaucracy

Thoughts, ,

An organization gets bureaucratic with age. Meaningless rules and policies are thrown around, often ignoring common sense. I came across an instance recently, and wondered what we were thinking.

One of our years-old, loyal clients worked with a specific team for few months. Things were done and sealed, and when they shifted their back-end from a local server to the cloud (who isn’t doing that nowadays?) some things stopped working. The client reached out to the technical lead they had interacted with.

He was met with a curt “the developer is working on something else” – and of course policies forbid us from having him help on anything else. No remorse, no work-around, no investigation, no solution. More importantly – no empathy or understanding of the customer situation.

Obviously the irate client voiced his displeasure. Things were done and all it took was a couple hours. But it left a very bad taste in the mouth.

Why was this necessary? What was on the minds of people? That once a project is over we are not responsible? That a customer should be made to pay for every small thing? That avoiding a headache is better than understanding what the problem was? That policies are useful to throw around as excuses?

Why am I relating age to this? Well, think of a young group of hungry people. Would they dare to imagine saying a curt “No” to a loyal past (and potentially future) client? Or would they go out of their way to fix the problem at hand?

Often, clients prefer Mindfire due to our age (almost 15 years!), our stability and proven delivery. Buf if we lose common sense – the hunger to do the right thing – clients should go to younger hungrier (albeit riskier) companies!

Of course we don’t want one customer to pay for time that goes toward solving someone else’s problem. But isn’t it common sense that if something has gone down, a solution has to be found promptly? But do we have strait-jacketed developers who won’t put in an extra couple hours (night? weekend?) to help a situation? Or will the current customer say no to some hours being transparently redirected, with appropriate discounting if necessary?

Solutions are hidden in plain sight. Excuses are also conjured out of the same thin air.

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
Software QA Engineers

QA Persona

Software Quality, , , ,

Does designation define personality or  personality defines designation ?  Confused? Either ways you think, you are absolutely correct. Every professional in this world has some sort of personality that differentiates him/her from the crowd. The reason for this may vary, either they have made themselves to appear so or their profession demands it. In this modern IT market, software QA engineers are the demand of the growth made in this field. They need to possess most or all of the following traits to be highly successful in this field.

“WHY” factor

QA TestingI strongly believe that ‘if you have the strong sense of WHY, you can create a beautiful result. Always possess a mind of valid WHY, you should not merely accept anything served in your plate. Try always to clear your WHY card, if that is done you can come up with productive ideas and solutions. You should not pretend as if you are through to any concepts or knowledge transferred, just to leave an fair impression. You should understand that you are here to add value to the project. Ask yourself until you get familiar with every aspect of the project you are assigned with. Remember this simple WHY as the capability to unearth a whole lot of information.

Assumptions:

QA Testing

A software QA engineer never assumes anything while performing his task. So he never make an ASS out of U and ME because that is how it is spelled. Since childhood we are used to assume some facts in order to proceed with the problems, even the world’s greatest theorems are formulated on assuming some facts. Let me figure out the things a layman assumes while filling up a simple registration page

  • Name text box should contain only alphabets
  • Mail ID should be in a proper format([email protected])
  • Fields marked with asterisk(*) are mandatory to be filled.
  • Address line should be separated by using comma or space.

A layman simply applies the common sense which is still not common to find. But just think if the application accepts invalid email ID, mandatory fields can be left blank or if the date of birth accepts future date and many more. This all can lead to troublesome situations. A product is made for the market and you cant expect that he will have the required common sense to use the product. Thus a big question mark arises for the quality of the product, you need to put yourself into various categories of user’s shoes so that you can test the product in all aspects.

Down to Earth

A software QA Engineer is supposed to be unpretentious, approachable and genuine. S/he understands that s/he is the voice of the end users. S/he is here to make the software better. There are often situations when s/he needs to go against a team of developers. If s/he stops reporting a set of bugs with a assumed notion that development team wont put an eye upon them, then it may lead to troublesome situations in a long run. So in order to deal with such situations he needs to possess strong convincing skills so that he can convince the developers and sometimes clients for the changes to be made in the project.

Eagle’s eye

QA TestingThis analogy works well with software QA engineer,he needs to possess eagle’s eye to become super star in the field of Quality Assurance. Many a times most severe bugs surpass our eyesight if we just have an overlook of a product or application and thus risking the product’s quality. As an QA engineer we need to deeply investigate the project in every aspect. We need to uncover the hidden bugs which can have an severe impact later on if it is not fixed in the initial phase of the development cycle. So he needs to be in proper sync with the development cycle so that bugs cannot be carried forward.

Strong Communication:

A software QA engineer needs to communicate with various individuals involved in software development cycle in day to day agenda. S/he is involved in communicating the bugs discovered, the enhancements required etc not only to the development team but also to the client. In his day to day curriculum he needs to prepare Test Cases, File and report bugs. So he needs to be strong in written communication. If in any situation there is a deviation from this then it may lead to Communication Gap and thus ultimately risking the product’s quality.

These are the traits which I find most important to be there in an QA engineer. S/he is supposed to wear several hats while working. S/he is the Quality manager, customer service, tech savvy user, non tech savvy user, angry user, lazy user and last but not least the quality assurance engineer. Many a times s/he has to change her/his thoughts mid-stream, and adopt a different point of view in order to get the job done properly. To most extent a company’s brand solely lies upon her/him. So, above all s/he has to work keeping in mind the company’s image.

 

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
Testing at Mindfire

When in Testing do as the Testers do!!!

Software Quality, , , , ,

Its high time to bridge a gap between theoretical knowledge and real world implementation.
If you are new to testing domain and just trying googling out the real meaning and approach of testing below are few points which I feel will be handy for a beginner.

– Prepare test cases or a checklist for the project you are assigned in. Include all the test scenarios you can think of. Yes you are thinking right!

 

P.S. All the positive and negative scenarios. 🙂

For beginners – Test a simple ’email log in’ page!
What all scenarios you guys can think of!Yes you are going on right track.. whatever weired comes to your mind..Just do not stop playing around.

P.S. Let the application crash!!! 🙂

– Start performing tests , find and report bugs but hang on always remember there’s no end to bugs i.e. you can never say ‘This application is bug free’!!

P.S. Cant help it! 🙁

– Step into Customer’s shoes ; feel like a lay man and you will be amazed to see the number of bugs you come across.

P.S. Do not end up stepping on toes! 🙁

– Be Creative in your approach ; while writing test cases or preparing a check list. Do not assume.

P.S. Assumptions is the mother of all mistakes! 😉

– Start Suggesting ; Dig into the details and get to know the product’s functionality and general behaviour. This will enable you to add value and suggest new features and enhancements to your product.

P.S. A smart move it is! 😉

Last but not the least..

– Follow Processes ; Stick to the organisation standards and guidelines and process of QA testing.

P.S. Follow the process and find as many bugs you can..after all we are a part of software QA testing team !! 🙂

Happy Testing!!! 😀

Author – Anisha Nayak

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

“Quality” in simple terms

Software Quality, , , , , , , Atma Prakash Ojha

One small thing that we miss sometimes is the need to keep in mind the end user of the software products we build or the existing products we service. Our client would not in all cases be the final user of the products – for example say our client is into building games in Facebook. He can play the games but the reason he is building this game is to sell it as a business, in that case the end user would be someone we do not know. If we keep this end user’s need in mind and build an application which will delight him once he uses it – we can pat our backs and feel good that we delivered a good “quality” product.
Author – Atma Prakash Ojha
” Quality ” – What does this term mean ?

Most of the time we make “quality” synonymous with “CMM” or “ISO” or some other industry accepted certification. The point is these are certifications by independent bodies to let others know that we have certain level of expertise/standard but without these too we can be good. How many of us are certified in the current technologies that we work in ? Does that mean we are not good – NO.

I will not define quality here but rather through some examples try to explain what it is.

You and your friends are planning to go out for dinner to a good place and out of 4-5 options you short list you zero in on 1 option and go there – right ?

Lets analyze what all parameters you would have used to decide on any one particular restaurant.

1st food should be good.
Meaning – you want that the “Quality” of the food should be good. Here quality means two things – first the stuff used for preparing food are fresh and good – no stale or sub standard stuff is used . Second the taste of the food should be good.
If I draw a co-relation to what our situation is – first our client would expect that the technical competence we have is good – that our people are very good in the areas that they work in. Second is our people have enough aptitude to understand the business of the client,i.e his requirement , and code accordingly. Difference here is – some people might know a technology theoretically – every syntax and options available but cannot comprehend a real life business scenario and put it into coding.

2nd thing that you evaluate about the restaurants is the ambiance – it should be good to eat and enjoy.

Here quality means quality of the place. The seating arrangement, the waiters, the plates used for serving etc – everything which is not your primary need (food) but something which will make you feel good and nice.
In our case – This would mean having good communication skills, so that the client feels comfortable talking to us. Communication skill has two main areas – Verbal and Written.
Both of these should be good in us to be a true professional – someone with whom people would love to deal with.

With these 2 things you would have decided to go to a particular restaurant. Imagine there comes up another place in town which in addition to all these also does the following. It discusses with you about your mood and the reason for the outing and accordingly serves food or decorates the place. This would delight you to such an extent that you may always want to go to that place.

In our case – we can check with our client who our end customers would be and accordingly make the product suit their need. For example say our client is building a social networking site for senior citizens ( retired government officials, army personnel, etc ) . Then in such a website having bigger buttons will be good, or building an application in such a way that it is not too deep rather is more horizontal in terms of page spread, i.e to get to a page too many links are not followed – every parent page should have maximum 3 level below pages not more.
Imagine we actually giving such suggestions to our client and implementing it in the final product. Not only our client but our end user will also be impressed to a point where they might just want to work with us for ever.

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •