Windows application and design.

"Why are you buying a windows phone! are u crazy! There are not much applications dude!!"
This would be a response from a friend whom you inform about you buying a windows phone.


But you would be surprised to know that Nokia windows phone market sales are increasing enormously with more and more people buying windows phone. Normally when u buy a new phone 1st thing you would confirm with many techies is about free useful applications in store. If u ask me now (I ain't a techie :P) I would suggest you to buy an Android phone because there are lot of free applications and games to download. But if you want a phone for which has excellent look and performance i would suggest Windows phone. Transition are so smooth that you would love your phone a lot. The only con of buying windows phone in present date is lack of application you would find when compared with other two platforms


Even though it's a con I recently found out how windows phone marketing team is trying to increase their market by linking Bollywood industry with their apps exclusively released in windows platform first. Take for example Dhoom3 and Krissh3. Both the games were a massive hit on Windows platform. In future I would not be surprised to see people developing apps for windows platform first.


Coming to designing part, when compared to Android and iOS layouts, windows want the application design simple and effective. This actually helps in reducing the effort for windows testing. So here are the list of things to keep in mind while designing windows application.



1. You need to make sure proper color combinations are used.
2. Alignment needs to be very accurate enough i.e there should not be any alignment issues.
3. Should support all resolutions of windows phones.
4. Style of the selected state of button should be kept consistent
5. Content in the application should appear properly i.e there should not be any text clipping.
6. Pin to Start feature should be implemented for all the sizes in tile.
7. All the texts are localized if other languages than English are supported.
8. Provide a refresh button in app bar to refresh the content of the screen.
9. Make use of Panoramic view or Pivot where ever suitable.
10. Use more of Horizontal scrolling to display the next content if there are couple of content in the list.


Additionally make sure to

1. Display a No network alert in screen or an alert when network gets disconnected.
2. Check for memory leaks in application ( Ask for debug build from developer )
3. Check if you can scroll to bottom of the screen without content being clipped.
4. Check if image quality is good i.e image should not be pixelated.
5. Check with analysis tool in Visual studio to check the response time, battery consumption and performance of the application

Things required to be a good defect reporter.

Do you find yourself in a situation where developers ask you each and every time to reproduce the bug which was reported?? Are they not understanding the defect?

Being in a quality testing department, a quality tester should be good in communication and writing skills. Development team should never come back to a tester asking him to reproduce the bug (Even once). If this is achieved by you in every defect then you are a 100 percent good defect reporter.

A good bug reporter should always keep these things in mind while logging defect.

1) Defect Summary: Defect summary should be kept short and sweet. Just by looking at the summary the developer should understand what the bug is all about. I frequently see testers being very vague in providing proper defect summary. If the defect cannot be explained in Defect summary then use following sentence : "Application crashes if following sequence is performed in so and so screen". and explain the defect by providing proper steps in description.

2) Severity: Severity plays an important role while logging the defect. Developers would plan fixing of the defects depending on the severity. As a tester we need to always be a good judge in marking the severity. Many companies have following severity in bug tracker depending on the following criteria

- Critical: If the system crashes or certain functionality is not working or there is loss in data.

- High: If feature doesn't work as per the business requirements or there is no possible way to proceed to next step of testing.
- Medium:Highly visible usability and UI issues and if there is a possible workaround.
- Low: Cosmetic flaws

So make sure the defect is logged with correct severity.

3) Build information: Make sure build number or release number is entered properly to further reduce the confusion. 

4) Device Information / OS information : Make sure proper device model and OS is mentioned. If the same defect exists in other devices or OS then mention those devices too.

5) Assign defect: It is better to know who is handling what module as project starts so that assigning the defect becomes easier. If you don't know who is handling the module assign the defect to project owner so that the PO can assign the defect to concern person.

6) Steps: Make sure the steps are mentioned properly, right from the start till end. Each and every step is very important to be written, be it a simple tap or some unusual sequence. If there are any screenshots attached, make sure you mention the screenshot name in steps itself. Have expected and actually result properly mentioned. If any additional info is required, mention those points too.

7) Screenshot: Always make a habit of attaching a screenshot to the defect as it gives more clarity about the defect. Using an annotation, mark the area in the screenshot where glitch or UI issue is found. If there are multiple screenshots then make sure that proper name is given to each screenshot. Its better to have a build number along with the screenshot so that if there are similar bugs found in next build then the screenshot could be named with the present build number to reduce confusion.

Let me know if I have missed anything. Cheers. 

How do you install application to your iOS device using Xcode organizer ?

Applications can be installed to the iOS device by using Xcode. You can even install applications which are downloaded from iTunes too. First thing you need to do is download Xcode 4.5.2 for your Mac system. 

Steps to install

1) Open Xcode application in Mac system through Dock

2) Click on the Windows list in Xcode system bar

3) Select Organizer ( Short cut: Cmd Shift 2)

4) Organizer window would open

5) Click on Provisioning Profiles in Library section 

6) Simply drag the provision profile provided by the developer to the library window to add the provision profile or click on import to get the required provision profile.

7) Now Click on the device which is connected ( Green Dot ) in Devices section 

8) Click on Application

9) Drag and drop the application from Finder to window or you can tap on Add to get the required file from finder.

10) Progress indicator would appear indicating about application being installed.

11) Check in device to confirm if application is being installed.

Note: 

- If valid provision profile is not installed, a alert message would be displayed at end during installation

Adios

Test Cases for Sign in and Sign up.

1. Username

a. Requirements Check

- Check with requirements if special character could be used for username else Special character keys in textfield should be disabled i.e. if user taps on any special character key in keyboard no operation should be performed (dead key). If special character keys are not disabled then "Special characters are not allowed" alert message has to be displayed when used as username.

- Check with requirement for minimum number of characters allowed for username. If user enters less than the minimum number of character then proper alert message has to be displayed.

- Check if username is case sensitive or case insensitive. If its case sensitive then if 1 person has a username 'Christ' then if another person signs up using 'cHrist', alert message has to be displayed.

- Check with requirements if 'space' could be used for username. 

b. Test cases 

- Use username which already exists.

- Don't enter any character in username field.

- Use other language character such as Arabic or Chinese.

- Use hidden special characters. 

Ex : If u tap and hold character L in keyboard you would get a special character. If special characters are disabled as per requirements then developers should make sure to disable hidden special characters also. Try experimenting with different hidden keys :)

- Test for Case sensitive

- Use less than minimum number of character.

- Use more than maximum number of characters.

- Use space key in-between letters

- Copy paste a special character from Note or Safari.

- Finally a positive test case use correct username :)

2. Password 

a. Requirements Check.

- Check with the requirements for minimum character and maximum character which could be used for password field. Mostly it would be 6 for min and 32 for maximum. 

- Password field should be shown in Asterisk (****) as you type.  

b. Test Cases

- Use less than minimum number of character.

- Use more than maximum number of characters.

- Copy text to password field (Shouldn't work) 

- Use special characters, numbers and letters.

3. Email Address

a. Requirements 

- Check with minimum and maximum number of characters which could be used for email address.

- Only letters numbers period and underscore should be allowed for Sign up. Its better for developers to disable rest all keys in keyboard.

- Email Address should always start with letter.

b. Test Cases

- Use special character like @! as email address.

- Use wrong email address.

- Use valid Email Address

4. Others 

- Forgot password feature should be used. If customer has not asked for it, insist customer to have this feature.

- Clear button should be present so as the user could clear the textfield by tapping clear button.

- It better to disable Copy and Paste option in textfield.

- Its better to have remember me check box so that it would remember the email address.

- Sign in / Sign up button should be enabled only if all textfield are filed. If requirements is such that all button should be enabled then if user taps on Sign in / Sign up button proper alert message has to be displayed.

- Appropriate alert message has to be  displayed if any error is found. Each error should have a separate alert message. 

5 reasons why a developer cannot test his own application better than a tester!

1. Attachment with source code
- As everyone know developers are emotionally attached to their code which makes them not to test like a tester. "A developer would never degrade his own baby" :P Its just like how we tester are emotionally attached to a bug. Don't we get angry when a developer counters us telling that the bug reported is never a bug? :D

2. Concentrates only on positive cases 
- Most developers would normally think only about positive and straight forward scenarios whereas testers mentality would be always in breaking the code and concentrating more on negative test cases.

3. Lack of End user experience
- Testers would normally check many applications & game and would exactly know what is required, as they would have already experienced checking similar kind of application whereas most developers wouldn't ( If a developer is reading this he would surely crib about not having time to check other applications Gotcha! )

4. Not much exposure to bugs: 
- A tester would have experience in testing many application and would know when a code could break whereas a developer wouldn't have much exposure to bug which make a developer fail in testing.

5. Tight schedule: 
- Most companies wouldn't give sufficient time to developers which leads them to not test the whole application.

So what do you think can a developer test his own application better than a tester ?

Myths of Game testing.

1) You just play around, nothing technical!

Fact: While testing games, it is important to know what logic the developer has used which in turn helps you to find an unusual sequence.

2) You get to play games before it is released!

Fact: Its true that you get to play it before release but the amount of time spent to test the game really makes you sick about the game and sometimes even to hate the game

3) You have lot of fun while testing!
Fact: Though you would feel good about it initially but, would you have fun circling round a same F1 circuit for 100 times! No right!

4) You get paid for playing games!
Fact: You spend most of the time creating test documents, logging defects, regressing defects, testing with localization, testing in different devices.. the list will go on!

5) You can change whatever you want in game!
Fact: This is not true at all! Even if you feel that certain features are required for easy gameplay your ideas would either be rejected by development team because of time constraint or by customer if he feels it is not so cool!

What do we normally do when we are free from work!

1. Check social networking sites
2. Window shop in online stores
3. Watch videos in Youtube
4. Read some technical blog for about 2 minutes and then again stick to point number 1 2 and 3
5. Read 2 pages of C / C++ / Java
6. Forward mails
7. Check if any new girl has joined in internal website
8. Stare at the monitor
9. Read some cricket / football news
10. Read political news
11. Tweet the news
13. Disturb a developer / designer
14. Search for a device to play games
15. Wander around to see if anyone is free as you.
16. Point out some mistake in some other project.
17. Chat with a girl in the wing
18. Create some funny face in Photo booth
19. Plan 4 weekend trip
20. WIKIPEDIA

So what do you do when u r free from work ??? 

P.S

I just forgot to add point number 12 :P If you dint figure this out, you really need to concentrate while reading my blog :D

How to enjoy testing and give a defect free product.

Recently our team figured out that we are able to produce more and more bugs and simultaneously enjoy what we do. Here you go!

We started to have competition on who would log most number of valid defects. Initially my teammates were really uncomfortable to log very minor defects. But i constantly told my teammates, even though the defects are small, these are the defects which would be found by producers and customers and we are blamed for not finding those defects. So as we started competing against each other, we had a quality product where we were damn confident the not even a minor glitch was left behind and simultaneously we enjoyed testing due to this competitive behavior. Recently we were assigned to individual project where 1 QC was assigned to test the 1 application but even after that we used to compare our defect count and try to find more defect.
So what do you think about this idea ?

P.S

This post was written in 2011.

List of Windows phones and Tablets (Nokia Lumia and others)

Serial No.	Device Name	Operating System	RAM	Storage
1	Nokia Lumia 520	Microsoft Windows Phone 8 , upgradeable to WP8 Amber	512MB	8GB
2	Nokia Lumia 521	Microsoft Windows Phone 8 , upgradeable to WP8 Amber	512MB	8GB
3	Nokia Lumia 525	Microsoft Windows Phone 8 Black	1GB	8GB
4	Nokia Lumia 610	Windows Phone 7.5	256MB	8GB
5	Nokia Lumia 620	Microsoft Windows Phone 8, upgradeable to WP8 Amber	512MB	8GB
6	Nokia Lumia 625	Microsoft Windows Phone 8, upgradeable to WP8 Amber	512MB	8GB
7	Nokia Lumia 720	Microsoft Windows Phone 8, upgradeable to WP8 Amber	512MB	8GB
8	Nokia Lumia 800	Microsoft Windows Phone 7.5 Mango, upgradable to v7.8	512MB	16GB
9	Nokia Lumia 810	Microsoft Windows Phone 8, upgradeable to WP8 Amber	1GB	8GB
10	Nokia Lumia 820	Microsoft Windows Phone 8, upgradeable to WP8 Amber	1GB	8GB
11	Nokia Lumia 822	Microsoft Windows Phone 8, upgradeable to WP8 Amber	1GB	16GB
12	Nokia Lumia 920	Microsoft Windows Phone 8, upgradeable to WP8 Amber	1GB	32GB
13	Nokia Lumia 925	Microsoft Windows Phone 8, upgradeable to WP8 Amber	1GB	16GB 32GB
14	Nokia Lumia 928	Microsoft Windows Phone 8, upgradeable to WP8 Amber	1GB	32GB
15	Nokia Lumia 929	Microsoft Windows Phone 8 Black	2GB	32GB
16	Nokia Lumia 1020	Microsoft Windows Phone 8, upgradeable to WP8 Black	2GB	32GB 64GB
17	Nokia Lumia 1320	Microsoft Windows Phone 8 Black	1GB	8GB
18	Nokia Lumia 1520	Microsoft Windows Phone 8 Black	2GB	32GB
19	Huawei Ascend W1	Windows Phone 8	512MB	4GB
20	Huawei Ascend W2	Windows Phone 8	512MB	8GB
21	Huawei Ascend W3	Windows Phone 8	1GB	-
22	Samsung ATIV S	Windows Phone 8	1GB	16/32GB
23	Samsung ATIV S Neo	Windows Phone 8	1GB	16GB
24	Samsung ATIV Odyssey 1930	Windows Phone 8	1GB	8GB
25	Samsung ATIV S I8750	Windows Phone 8	1GB	16/32GB
26	Acer Allegro	Microsoft Windows Phone 7.5 Mango	512MB	8GB
27	Htc 8S	Microsoft Windows Phone 8, upgradeable to WP8 Amber	512MB	4GB
28	Htc 8X	Microsoft Windows Phone 8, upgradeable to WP8 Amber	1GB	16GB
29	Htc 8XT	Windows Phone 8	1024MB	8GB
30	Htc Windows Phone 8X CDMA	Microsoft Windows Phone 8, upgradeable to WP8 Amber	1GB	16GB
31	Nokia Lumia 2520	Windows RT	2GB	32GB
32	Samsung ATIV Tab P8510	Windows 8	2MB	16/32GB
33	Acer W4-820-Z3742G03aii	Windows Phone 8.1	2GB	32GB
34	Acer W4-820-Z3742G06aii	Windows phone 8.1	2GB	64GB
35	Lenovo IdeaPad Yoga 13	Windows 8	4 to 8GB	128 or 226 GB
36	Lenovo IdeaPad Yoga 11	Windows RT	2GB	64GB
37	Lenovo IdeaPad Yoga 11S Ultrabook	Windows 8 , Windows 8 Pro	Upto 8GB DDR3L	256 GB SSD HDD
38	Lenovo IdeaPad Z500	Windows 8 64	4GB,6GB,8GB(DDR3)	HDD: 500GB.1TB
39	Lenovo IdeaPad Z580	Windows 8	4GB,6GB,8GB(DDR3)	HDD: 500GB.1TB
40	Microsoft Surface 2	Windows 8.1 pro 64-bit	2GB	32GB,64GB
41	Microsoft Surface	Windows RT upgradable to Windows RT 8.1	2GB	32GB,64GB
42	Microsoft Surface Pro 2	Windows 8.1 pro 64-bit	4GB,8GB	64Gb,128GB,256GB,512GB
43	Lenovo ThinkPad Helix	Windows 8 pro ,Windows 8	8GB DD3	128GB,180GB,256GB SSD SATA3
44	Lenovo ThinkPad DataSheet	Windows 8 pro ,Windows 8	8GB DD3	128GB,180GB,256GB SSD SATA3
45	Lenovo Lynx	Windows 8, Office Home & Student 2013	2GB DDR2	Upto 64GB eMMC

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 :)