When it comes to the profession, everyone wants to be the BEST in their respective areas. A designer strains his mind and tries to produce the best designs ever. An architect thinks big and tries to build the best architecture in the market. A software developer tries to write the best, optimised and standardized code. Even the person who sells paani poori on the road side tries to be the BEST in the business. From where this mentality of being BEST comes from? Why do we think of being the best in whatever we do? The answer is simple. It adds value to our career, knowledge and organization in which we work which in turn draws more business, business in terms of more customers for the paani poori waala, business in terms of more orders for the designer, business in terms of more assignment for the developer and business in terms of more clients for an organization. And all of us know business is directly proportional to money 🙂 :).
When I joined my first organisation and first project, I was put into testing by my manager. The idea behind making me a part of the testing team was to get me familiar with the functionalities in a better manner which would help me understand and work with the application better.
Slowly I started getting familiar with terms like System testing,Functional Testing,Load Testing,Regression Testing etc.But the testing term that made me curious was “Smoke Testing”. It was almost everyday when I used to hear the same term again and again and sentences like “Lets do the smoke testing”,”We have to finish the smoke in 20 mins”,”We have a new build in place,so we need to carry out a smoke testing” were common. I started getting more and more curious and thought why do they call it “Smoke Testing” when there is no smoke at all? Is it something related to cigarettes? And finally I got the answer through the most trusted/beloved/loyal/awesome friend of any software professional – GOOGLE 🙂 :). The description that why it is called Smoke Testing was as interesting as the name itself. They have taken this name from an ancient testing process where wooden boxes were tested for holes by filling them up with smoke.If smoke comes out from any leakage present in the box,they used to mend it. It also refers to tests made to closed systems of pipes to test for unseen leaks.
So when we go for this Important Testing Process everytime we have some change in the system or a new enhancement gets added, we should also know what are the things those should be tested during the smoke test. At the same time it is also important to decide what are to be put in the smoke testing process and what are to be excluded.
What is done and how a Smoke Test is implemented:
In general, to implement smoke tests/smoke testing procedures, the test team prepares a set of test cases those are executed everytime a new release or build is provided from the development team. These set of tests are used to test the major functional areas of the application. They generally do not test in detail/ in depth by going to the low level details of the system. Rather they are high level tests those test that the overall functionality is working fine.
It is a good practice to make the developement team aware of the functionalities tested during the Smoke Test process to ensure quality awareness.
Now how do you determine what to include and what to exclude in a smoke testing process? The following points might be helpful for taking the decision.
– First of all decide that what are the critical/main/important/’most frequently used by users’ functionalities those need to be working.
– Then look into the types of changes that have taken place since the last testing process/test cycle and what you need to cross check again to ensure that these changes as well as the other modules which might get affected by these changes are working fine. In testing terms we call it “to check whether any of the changes have any regression impact or not”.
– Finally, check some other areas in the system where a more detailed check is necessary which a tester should perform going beyond the steps mentinoed in the testcase. Of course this action needs to be prioritised as there might be a lack of time.
3 Major characteristics of Smoke Testing
– It generally follows an end-to-end testing process for the system. Testers should focus on stressing/loading the application to find the errors/bugs which may result in malfunctioning of the application further.
– Smoke Testing should not be exhaustive but it should be able to find out major defects.
– The main idea behind the Smoke Testing process is to make sure that the main functionalities of the application are working fine and the system is stable enough for further thorough testing process.
Advantages of Smoke Testing
1. It minimizes the risks associated with integration: It has always been a headache for developers and testers when 2 separate modules worked on by different people are combined/integrated. It happens quite often that the integrated code does not work properly.The daily build and smoke testing process manage to make the integration problems small and manageable and thus prevent problems with the integration process.
2. It reduces the risk of low quality: Timely smoke tests ensure that the system does not run down or fall into a state where there would be quality problems which would take more time to be fixed.
3. Uncover major problems: The probability of finding bugs/major bugs increases with a well designed smoke test. It also helps a tester to uncover defects/bugs earlier in the testing cycle.
4. Saves money and time: With all the above 3 advantages,a good smoke test ensures that a lot of cost and time is saved.
1) Thorough analysis of the Test Results:
A good software QA testing professionals always tries to add some analysis to the bugs reported. Most of the times the error logs say a lot about the bug/defect. By adding that thing in the Bug Report, the tester makes it easy for the developer to fix the problem.
2) Try to attain maximum coverage:
Try to cover/test as many combinations as possible. Though it is not possible to attain 100% coverage every time, try to test the maximum combinations/scenarios those can be thought of and tested.
3) Go by the Golden Rule – “Divide and Conquer”:
To attain maximum test coverage divide the application to be tested into smaller modules and write separate test cases for each individual module. It helps in testing each module in detail and also ensures maximum test coverage.
4) Don’t forget negative scenarios:
Always write the test cases for the positive scenarios i.e. write the test cases to test that whether the system is working fine as per the specification under ideal conditions. After that, write test cases for Negative scenarios / invalid conditions. This will ensure that the system works properly when being given negative inputs and handles the errors/exceptions properly.
5) Think like a Tester – Where there is a TESTER there is a BUG 🙂
Start QA testing of the application with an intent of finding defects/bugs. Don’t come to a conclusion like there won’t be any bugs in the application. Think beforehand that there will not be any bugs in the application and you will actually end up finding no bugs.
6) Frame your test cases early:
Try to write the test cases in the Analysis and Design phase. This ensures that the test steps included in the test case cover all the requirements.
7) Get the Test case ready before the developer’s code for the functionalities:
Don’t wait for the release of the application for testing to write the test cases. You might think that you can log more bugs, but NO. Let the developers analyze your test steps to create a quality app. This actions would also help in saving the time spend on reworking on the test cases.
8) Take care of the notorious intruder – “Regression”:
Include some steps in the test case which refers to regression testing. This will ensure quick regression testing during the system testing itself thus saving the time for individual regression testing.
9) Make your application Huff and Puff – Test the “Performance”:
The Applications where the response time is a critical aspect should be tested thoroughly for performance. Try to find out methods to overload the application during the testing process to test the performance. “Load” and “Stress” the application as much as possible to test the performance of the application under unfavorable conditions.
10) One should not test the code written by him/her:
It is human tendency that we are sometimes unable to find out mistakes committed by us in case we check our own work. Therefore we should always encourage people (developers) to get their work checked by testers.
11) Think BIG. Go for some testing that is not mentioned in the requirements.
Try to test some scenarios those are not mentioned in the SRS or requirements specification. It would help in testing that the application does not do what it is not supposed to do.
12) Take the help from past experience/statistics/graphs/records/test results:
Referring to the past statistics helps a lot in determining the areas which are more prone towards defects. Using them while system testing or regression testing can be beneficial in determining the defect clusters.
13) Learn while you Work:
Whenever you encounter any new term during the testing process which is not familiar, just make a note of it. You can also note down the concepts you learn during the testing process. These data can be proved to be helpful during the preparation of Test Closure / Test Release report.
14) Make the TESTER an early bird – Involve a Tester from the beginning of the process:
It’s always advisable to involve testers from the early phases of the SDLC like Requirements Analysis and Design phase. This helps the software QA testing professionals get a more thorough idea about the application under test (AUT) and thus he can write better test cases with a better/detailed coverage.
15) Be the best by following the BEST PRACTICES:
Being a good tester, always try to follow the best practices. When possible share them too with other software QA testing professionals.
16) Be more social – Talk/Discuss with people/developers around you:
Discuss with the developers/Business Analysts to know more about the application. Whenever it is required, have a face to face discussion for resolving conflicts fast and to avoid misunderstandings. When you understand the requirement or resolve any conflict, make sure you have put it in a written format like emails. Do not keep anything verbal as it does not have any physical existence.
17) Prioritize your work:
Prioritize your QA testing work and plan the strategy accordingly. Don’t forget about risks while prioritizing.
18) Write an easy to understand and detailed bug report.
A good bug/defect report not only provides the bug’s symptoms but also provides the impact of the bug on the application. It is always better to do some analysis and add notes (if possible) for the possible causes of the bug. It helps the developer a lot while fixing the bug.
Author – Sudeep Pattnaik
When 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.
It was the night of 20th September 2011 and I was returning home after attending a party at a friend’s place in Saheed Nagar. My friend’s sister got a job in TCS which made him invite some of the close friends in our group for a party at their home only. My phone started ringing right from the evening.After at least 15 calls from different friends and explaining them that I had some work to finish,finally I left office at around 8 o’clock. All of my friends already reached and were having a great time. By the time the food was ready we started gossipping and rewinding the happy college days. Finally got the call from aunty “Dinner is Ready”. The food was prepared by my friend’s mom and sister and as it was utterly delicious,all of us had a nice dinner filled up till the neck.After a small chat when we decided to leave,it started raining heavily. At the request by uncle and Manas(my friend) few of us decided to wait till the rain stopped or at least slowed down a bit.Few lwft as they used to stay nearby.
It was the evening of 1st July 2011,when the daily official routine was heading towards an end,I just thought of checking my GPS hoping for a message from Soumyanwesh regarding salary. I was even happier to discover the message count showing “1”. But it was not a message from Soumyanwesh,it was not a message from the Finance Department nor a message related to salary.It was a message from a Mindfirean named Asish Tripathy and was related to the “Corporate Social Responsibility” what we term as CSR in short.