What a developer/programmer always have to say!

1. Have you installed a proper build!

2. I haven’t touched that module for weeks
3. It worked for me yesterday
4. This is not possible!
5. Must be a hardware issue.
6. I think this OS doesn’t support that.
7. I cant test everything. I need time for that
8. It works.
9. Somebody must have altered my code!
10. Why do you do it that way?
11. Check with the specs.
12. Code is not committed.
13. Is there any particular sequence?
14. It works in my simulator. Check it out
15. I am busy
16. Thats a minor bug
17. I have not noticed this before!
18. I have noticed this before!
19. User wouldn’t do that
20. Must be from designers end.
21. I will fix it when i have time.

22. Reduce the severity

23. Why do you log such simple bugs. Please mail such simple bugs.
24. Will check with supervisor.

25. Check with Requirements.

List goes on and on :P So What else does your developer say other than these 25 points ?

Why some bugs are never found in testing phase.

Yes! Its true some bugs are never found during testing phase. Why cannot we track some bugs while an end user can identify it in app store build? This question would be a serious set back to testing career. So here you go for the solution.

1) Test every single detail in the screen.
You must be thinking, "you are kidding me, i test every single detail" but i say a big NO. We do not check with every single detail in the screen sometimes. Example: Details like pressed state for the button, pressed state audio, disabled state buttons. So be 100% sure that every single part of the screen is being tested.

2) Smoke Test

Create a smoke test plan for every project. By running SmTP you will be confident that main features are working as intended and then you can start performing system or ad-hoc testing

3) Run Test suite plan (TSP)
When you write test suite plan make sure you don't miss a single step/case. We always write positive test case and don't bother to write about negative test cases. So make sure you write both positive and negative test cases. By doing this you will be sure enough that every single module is being tested thoroughly.

4) Stop thinking like a quality tester, use application as an end user.
 If your company allows you to take company devices home, take the build and use the application as a normal user. I bet you will find some bugs and you will be surprised to find out that you never found those bugs while testing.

5) Ask for time if you have not completed testing.
Sometimes due to the tight schedule you would be forced to test quickly. Due to the pressure you will be completely fooled by some bugs as you will be in hurry to test the application. So if you feel like you need time, do talk to your supervisor and let him know that you require some extra time to test the application. If still not permitted run STP and if all modules are working raise a green flag for release and continue testing the application.

6) Test in all devices and OS 
Make sure you test application in all devices and OS present in your company. You may feel its tedious task but you will surely find some awesome bugs :)

7) Released build not tested*
Make sure your developer has not changed the code after u have approved for the release candidate build. Sometimes developers change code in the last minute and would never inform it to you as they feel its a minor change (I have personally experienced this). So do sit with the developer and make sure the build which you have tested is getting released in store to be in the safer side.

Max supported OS for apple devices

1) iPhone
- iPhone 1 - 3.1.3
- iPhone 3G - 4.2.1
- iPhone 3GS - 6.1.3
- iPhone 4 - 7.0
- iPhone 4s - 7.0
- iPhone 5 - 7.0

2) iPod
- iPod 1G - 3.1.3
- iPod 2G - 4.2.1
- iPod 3G - 5.1.1
- iPod 4G - 6.1.3
- iPod 5G - 7.0

3) iPad
- iPad 1 - 5.1.1
- iPad 2 - 7.0
- iPad 3 - 7.0
- iPad 4 - 7.0
- iPad mini - 7.0

How do you convince a developer to fix a defect!

I know this would be a question every quality tester would have in their mind. I had the same question in my mind when i started my career. I believe these points below would be helpful to you (may be).

1) Firstly you need to follow the process. If your company has a defect tracking tool, make maximum use of it. Log every single defect(even very low defect) in tracker so as to maintain a report of the defects found. Do not have any verbal communication because most of the developers will just forget about the defect or pretend to forget.
2) Make sure you have written the steps properly. When u log a defect in tracker, do read the steps twice and try analysing if the other person could understand the steps. Most developer will drop fixing few defects if they cannot analyse the steps.
3) When it comes to severity make sure it is properly marked. Some developers don't even look into low defects. If you feel that the defect needs to be fixed by next build mark it as medium.
4) This point may not be applicable to some but I feel this is the most important thing, being more friendly with your developer could lead him/her not fixing the defects. Working with developer who is a stranger is more useful than a developer who is a friend. Developer who is a friend would normally force you to forget about certain defects. So I feel bringing personal relationship to work is a strict NO NO. Have a strict work life. If you have a good friend as a developer in your project, make it clear to him that work is work, work cannot get compromised.
5) Have a chat with the developer and inform him the severity of the defect and why it needs to be fixed. But when you approach a developer make sure he/she is not in a bad mood. Always be modest by asking "Are you busy? Can I have a 10 mins chat with you about the defects"
We normally tend to forget that even developers would be busy (or they pretend to be busy) and we just start blabbering about the defect. Just imagine if someone comes up to you and informs you about how bad you look or how ugly you are, Bad isn't it :) So when you start with conversation make sure you tell these words "Can you check if this feature is working properly, I believe this sequence will crash the application. Please have a look, I will regenerate in front of you" Looks simple but very hard to execute. We normally tend to blame or put some allegation on developer as soon as we approach them
6) If your defect status is still New, make a note of those defects and call for a meeting with higher official or supervisor. Meetings and discussion solves most of the problem as developers are forced to listen to their supervisors. But when you conduct meeting make sure you have a super valid points noted down to put forward in a meeting. Normally when I feel I am losing my hold on meeting I convey this dialog " I know most of the users wouldn't perform this sequence, but 1 in 100's will surely do. You see I believe that every user is important.( Last sentence is purely fictional :P)
7) Some defects would be very hard to regenerate, Our normal tendency is to run to a developer and inform about the random crash or behavior. But as usual some developers will not give a damn to this as there is no sequence for the defect.
So i would recommend you to not rush to developer immediately. Firstly if its crashing quickly save the crash log, or if you find a glitch take a screenshot as a proof. Now try regenerating it by remembering the last 10 steps. For this you need to be 100% active while testing. If you are not able to find the sequence nth time don't lose hope. Note it down in a sticky and continue testing other features rather than sticking to 1 single defect.  Finally if you cannot find it just go to developer and follow kindness behavior mentioned in point no 5 and provide maximum information about the defect and log it in tracker.
8) If its still not fixed, just send a mail to developer with cc to producers, supervisors and team member just to be in a safer side, i.e if the same defect is reported by the user, you can just forward the mail back again :P Witty isn't it :)

"A best tester is not the one who logs maximum number of defect. The best tester is one who get most of the bugs fixed"

"Every bug is reproducible, if it has occurred once"

- Bharath Shenoy

P.S

Following are the dialogs which you can use on a developer to fix defects ( make it filmy :P )
- I just conveyed this defect to the manager and he has asked you to fix this defect. (A big Lie)
- I read in one of the technical blog that an application got bad review just for not integrating this feature.
- I was telling everyone that you are a good developer and you fix all the defects.
- Don't you want your application to be a 100 % bug free. We can boast about this with other teams.
- I was telling my fellow tester that you cannot fix this defect.
- My previous developer used to fix all the defects which I reported, good na :) :)

Adios

Basic use of DDMS tool

Dalvik Debug Monitor Server abbreviates to DDMS. DDMS is an android tool which works with both emulator and devices. I was introduced to DDMS tool by my senior colleague 2 years back as i was really surprised that until and unless you root the device you cannot take screenshots. Sounds real difficult for iOS tester. But being an apple fan boy i find testing android applications are more fun and challenging than any other platforms as it teaches you about a new tool every quarter month.

Why do you use DDMS tool ?
- An android tester would use this tool to take screenshot from device and to check log.

How do you take screenshot ?
- Connect your device to system. Select debug mode in phone USB settings. Now click on the device in the device selection panel and then hit CMD+S from keyboard to take screenshot.

How do you check with log?
- If your application crashes then in log section you can see a red color lines which normally signifies that it is a crash or a force quit message.

What else can you do with DDMS tool?
- You can check with real memory and memory heaps using the tool. But in order to check with memory heap, you need to ask your developer to provide a debug build. I will come up with a post on how to check with memory in future.

What should you do when a build is given for testing?

Note: Listed below are the procedure which I follow, I am not implying that it is the best practice

- Maintain a folder to copy the build. Always make folders like Project name_platform
ex: Codename_iOS or Codename_Android

- Check with build notes.

- Check if any new features are implemented.

- Run smoke test plan

- Start testing with new features which are implemented.

- Check with defects fixed in defect tracking tool. Regress those defects (This step is invalid for the first build given for testing)

- Run test suite plan if it is a milestone quality build.

- Start with system testing

- Note down all the defects in a text document. Save the document inside codename folder

- Create a folder named Screenshot inside the codename folder. Copy all the screenshots in the folder.

- Change the name of screenshot taken and save it in jpg format if required.

- Start logging the defects in tracker.

- After the defect is logged mark the defect written in text document to bold just to make sure all the defects are logged.

- Send mail to developer regarding the important defects which are required to be fixed by next build
- Leave for the day :)