Category Archives: Software Quality

Product Engineering

Product Engineering and User Experience process.

Software Engineering, Software Quality, Basanta Moharana

What is Product Engineering?

Product engineering is known as the process to develop or design, system or a device such that the product is treated as an item for sale or to be used by various people. When a product is being developed, there is a lot of work and technology involved in the development process. This overall process is called as product engineering. Product engineering is usually called as an activity dealing with issues of cost, reproducibility, quality, performance, reliability, serviceability and user features. If the process goes through a proper creative way the outcome is awesome.

The term product engineering is; developing the concept and the design of the product and development of its mechanical, electronics and software components. For example: developing a smartphone. Now-a-days smartphones are very popular in the market and a lot of new and old companies in the way of competition, give away better product feature to customers. A product like smartphone includes a set of different features like designing the body, it’s hardware components, packaging it in a small space, developing the electronics that controls the various components and lastly developing the software which will operate all the features of smartphone known as the Operating System.

Here are some skills taken care for product engineering process
– Product statistical methods and tools
– Hi-tech manufacturing process
– Product reliability and user research
– Computer-aided design and simulation programs
– Strong knowledge product platform which the product will use
– Strong analytic work methodology and problem solving skills

In software industry, the term Product Engineering is used as development process of a software or an application. From making of prototype to final release of the application process, it is called as product engineering of the application.

Product engineering of an application. Points that everyone should follow:
– Prototyping of the complete application. (Visual Concept)
– Structural designing or User Interface designing.
– UI or Front end development. (What browser or compiler will read?)
– Backed or functional development. (Through which user will carry out work.)
– End user testing and bug fixing.
– Final product delivery.
This depicts the entire process for a successful web, desktop or mobile app.

What is user experience?

User experience is combination of two words, “user” and “experience”. The experience of a user towards a product or an application is called as User Experience. UX or User Experience in other term can be explained as the emotion of a user when he/she uses it. It may be good or bad. The good experience of user towards a product plays a vital role in the product’s success.

Let me give you a simple example. “One day at night you came to know that you have to reach office early in the morning at 7AM the next day to attend a meeting. For that you set your alarm at 6AM and go to bed. When you wake up in the morning and see that it is already 6.30 AM and the alarm hasn’t rung. You found that, the alarm is off due to battery drain out. You rush to the coffee vending machine for a cup of coffee but only to find out that there is no coffee. You could trace out that the machine is not connected to the power source. In the process you have already lost some time.

Then you get ready for office in 10 mins. While going to office by your car you face a lot of traffic for some unexpected reason. Then you notice that you are running out of fuel. So, you have to drive to a nearby petrol pump only to find out that the petrol pump does not have a card swipe machine. You rush to a nearby ATM and withdraw money. Finally, after fighting out so many obstacles, you reach office only to find out that the lift you use to take daily to reach to 5th floor does not work. Then you are forced to take the stairs and when you reach you find that the meeting is over and your colleagues have started work.
If everything would have fallen in place, you would have never missed the meeting.

The software or system that misguides you and does not help you achieve your goal is an example of bad user experience. Example – Google mail is most popular web application than other mail client for its good user experience. I personally like Google+ than Facebook because of its user friendly features and faster response. Looks doesn’t matter in the process of user experience. Please look at the two images which is called Donald Norman (design and usability engineer) Coffee Mug.

User experience has a vital role in software product engineering. Deep user research is key to success for better user experience. Taxi for Sure – A Driver app developed by a start-up company in Bangalore is a very famous app for taxi drivers. People use it for daily for hiring taxis. This free mobile app is very popular due to its user experience.

Key concept for better user experience.
– Deep user research. Feel the user motion
– Minimal and clean design of application
– Less page loading time
– Quick navigation through the functionalities
– Readable typography
– Minimum page refresh
– Avoid long loading graphics
– Graphical representation of functionality, by which user can understand the function easily without reading long text description.
– End user testing with exact devices.

Happy Designing 🙂

 

 

 

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

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
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Why Automation – Is it worth?

Software Engineering, Software Quality, , , ,

Automation Testing

Automated testing is need of the hour. Possibilities of the automation, apart from custom manual testing, are being analyzed for every other application now-a-days. It is preferred to manual testing due to several factors such as improved accuracy of tests, wider test coverage, more reliable results and above all, it saves time and cost rapidly.

Testing manually, on the other hand, is time consuming and error prone, hence can result in defects being left out. Having said that, I would like to analyze the positives of automated testing over manual as is generally said. Basically, it’s not always advisable to automate the AUT (Application under test) as opposed to prevalent myth about automation.

Automation can be accurate in giving reliable results with wider test coverage while saving time and cost, but this may not always be the case with all AUTs. Imagine the AUT with ever-evolving requirements and dynamic webpages. Here, Automation may be accurate with wider test coverage but will consume much more time and cost giving unreliable results due to system instability. In case of UI based AUT, if design changes frequently the automation is strictly discouraged. Further, choosing an inappropriate tool can lead to reduced efficiency as tool selection largely depends upon the technology used in the AUT.

It can be said that automation is the best way to increase the effectiveness, efficiency and test coverage of testing but only when proper analysis of AUT is made before shifting to it, else certainly a bad idea if its objective is not clear. Also, deciding on what to automate is most vital task before planning any automation process to follow. It is not possible to automate everything ; nevertheless modules that are stable and are manually tested at least once should be taken for automation. Test Cases that are executed repeatedly and consume time could be a priority, making the automation best suited for regression testing or retesting of the fixed issues. Descriptive test cases that are clearly explained are automatable and not the vague ones. Apart from regression, it can test stress, load and performance of the AUT.

Hence, Automation should be taken up only after analyzing the AUT and determining if the automation will actually be time and cost effective or otherwise.

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
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
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
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Experience of Web & Database Testing Workshop

Software, Software Quality, Thoughts, , , , ,

Knowledge as we know is not limited. We cannot say we have gained all the knowledge that we had to . Each day is a learning process, each person we meet we learn something from them, each work we do we learn something and the list is endless. And when it comes to our career , we would always want to have the best of our knowledge be it through learning , through training , etc.

Recently I had the opportunity to attend the 2 day workshop on Web and Database testing. Since the trainer was a senior industry veteran, with almost 20 years of experience, everyone was looking forward to attend and learn something new from the training. It was a 2 days training session with 25 QAs attending. There were many interesting topics covered in this session .

Continue reading Experience of Web & Database Testing Workshop →

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
Why Do You Do Things You Do?

Few things to consider before testing any application

Software Quality, Thoughts, , , , ,

I have a wall-pWhy Do You Do Things You Do?aper on my desktop which says: – “Why Do You Do The Things You Do” which forced me to write something like this which i feel should be considered before testing any application: –

1. Learning: – Analyze your test results thoroughly. Do not confuse yourself with ‘pass’ or ‘fail’ but finding the root reason of ‘fail’ or ‘pass’ will give you an idea for the solution of the problem. Testers knowledge increases by sending solutions for the problem

2. 100% of anything is not possible so having 100% test coverage is not possible but we can try to touch 99% of perfection.

Continue reading Few things to consider before testing any application →

Spread the love
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
ISQTB Certification

Tips for ISTQB Certification Exam

Software Quality, Thoughts, , , , Sudeep Pattnaik

ISQTB CertificationWhen we think of certifications, most of us think that “Do I really need a certification?”, “Is it worth putting the labour and money(a good amount most of the times) for just a piece of paper from some XYZ organisation?” , “Will it help me at a later stage of my career?” These thoughts flood sometimes our brains so much and leave us so confused that we take a lot of time only to decide that whether we should go for a certification or not, leave the preparation part aside.

All of us during our careers might have surely felt the need of certification in some way or the other. The need may be as simple as gaining more knowledge or as complecated as the determination to become one of the best certified resources available in the field.

Continue reading Tips for ISTQB Certification Exam →

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