How to create a file with exact amount of bytes to test the boundary value

Once I need to create a file with exact amount of bytes (file size) to test the boundary value of a file upload event in my project. Requirement is to be able to upload a file < or = 100MB. So I tried to create a file to test this scenario.

To create a file less than 100MB is very simple. But, according to the QA principles, we need to check the boundary value of that feature with the file size 99MB, 100MB and 101MB won't be an easy task as we have to create 3 files with exact amount of bytes. We called it as Boundary Value Analysis.

Then I found a nice command line to create such files without wasting our valuable time.

What you need to do is just create a .bat file with following command line and execute it.

fsutil file createnew filename length 

Ex: Let say if you need to create a file with 100 MB (1024 * 1024 * 100)

fsutil file createnew 100MB_File 104857600

Usability Engineering Basics - Part 3 (First)

In this time, I thought writing some words about usability engineering as I promise you some months back. If we need to highlight real usability issues which customers have, we need to conduct a practical usability test with appropriate infrastructure and tools. Then we can collect data to be analyzed and get the correct actions upon solving any usability issues. So we called it as Moderated Usability Test and let’s discuss how we can plan and do it.

1. Planning a Moderated Usability Test

Planning a test should be the first part and it is very vital when we conducting this kind of complex test. And the testing scope will get differ upon the usability requirements.

What you should test?

First, as usability engineer we need to decide what the functionalities that we are going to take are. In this case, we can collect valuable information from BA, design and development teams and select features that are new, often used, error prone and specially critical. After that we should prioritize them and write scenarios which represents typical user work flow. Scenarios should be:

• Small. Time is costly during usability testing.
• To the point. The meaning of the scenario should have a specific DOD.
• Realistic. The scenario should be a normal activity that the average user do.
• Scenario should be on user’s context. Selected scenarios should be related to the user’s context and we need to understand the participant’s connection with the system.

Following is an example for a scenario:

You need to add a contact with first name, last name and contact image in your company’s CRM web application. Add those information and click on “Save” button. Make sure to let me know when you are done.

Who is going to evaluate the Application?

Who you choose to evaluate the application will have a massive effect on the outcome of the test. Imagine that you’re creating an application that reconcile accounts. Your customers are people who deal with account reconciliation. That is a huge group of people. Narrow your focus to a particular user profile.

While you’re creating the user profiles, you may realize that you have two or more equally important subgroups like people who control the system (Business Admin) and people who use the system (Normail User).

Test with proper participants – Rule of thumb is testing no more than 5 users and running small tests as you can afford.

According to the industry standards, the common curve for usability test is as follows:

If we try to read the curve, as soon as you collect data from a first 3 users, you have already captured almost 50% of the usability issues. After you have usability insights from 5^th user almost all of the usability issues were captured and no need to spend more time and money. In other words, as you add more and more users, you learn less and less because you will keep seeing the same things again and again.

Who is going to Observe and how?

When talk about the observation, we have 2 main observation types. First one is ‘Obtrusive observation’ method and the other one is ‘Unobtrusive observation’ method which concentrate on observing what the test user does and refrain as much as possible from influencing her/him by explaining the design or asking questions. In ‘Unobtrusive observation’ method, we can have following combination as observers:

•         At least 2 developers.
•         At least 1 tester
•        And a BA

Where Are You Going to Test?

Now we know, what we are planning to test and who is going to evaluate the system. Now we have another question about the place which we going to conduct the test. The location of the test can be as simple as a meeting room or as complex as a purpose-built facility. If we need to conduct an advanced usability test we need video or audio recording equipment for analysis. Conduct formal tests in an environment that simulates normal use as much as possible. Usability tool like Morae is a good example for a usability tool which we can use to do such tests with advanced data analysis and presentation of results.

In coming articles, I’ll continue this and hope to address topics such as “How we going to create a script”, “Run the tests” and “How we gonna analyze results and prepare the report”.

An approach to build a team beyond Cross Functional

Few years back, I met one of my uncles who lives in Australia. We had a nice chat about our families, etc. After a while he asked me details about my job. I said I am a Software QA engineer. He was surprised and asked, what my responsibilities are. I then listed out my responsibilities one by one. He then asked, “other than the normal QA work, do you have other responsibilities to help each other and to add value to your project?” I answered that I did not. Then told me that he too was a QA person in the pharmaceutical industry. And other than his usual day to day responsibilities he works on other areas to help different people and to add value to the process/team. He described that main advantage is that the people in the team has knowledge about the other persons work and hence can help out when that person is unable to attend to it. (Maybe she/he on leave or sick).

In this article, I will not going to explain anything about product performance engineering but how to build an ‘Extended Cross-functional Team’

First of all, ‘what is Cross Functional Team’?

According to the Wikipedia “A cross functional team is a team composed of at least three members from diverse functional entities work ing together towards a common goal. This team will have members with different functional experiences and abilities, and who will likely come from different departments within the organization”.

In software industry, we have the same experience while working for a project. Say for an ex: we have a Oracle expert, SQL DB expert, Security expert, Product Performance Expert, Automation expert, Overall QA expert(s), Overall Dev expert(s) and Domain expert(s). It seems a nice cross functional team. But let say Automation expert is on leave for his/her wedding and suddenly there is an issue in the automated suite. Imagine the situation, do we have a resource to fix that in our team. The answer is NO as our test automation resource is on leave.

But see, if that team had a resource which have a basic knowledge about the test suite, then he can have a look and fix or he can give a call to the guy who knows the entire process and find a solution as quickly as possible. So that is the main reason why we talk about Extended Cross-functional Team which beyond normal Cross-functional Team.

How we need to build an ‘Extended Cross-functional Team’?

In order to build this extended teams, we need to target the individuals who worked in a project. After a lot of effort, experts came up with a model called T model which we can use as a basic guide.

Model is as follows:

Main idea behind this model is explained by the vertical and horizontal lines. Thick vertical line represent the core competences that the resource has (Or in other words, a lot about a bit). Thin horizontal line represent his/her other capabilities or areas that has basic knowledge (Or in other words, a bit about a lot).

As a QA or Dev engineer, we have to select this according to following 2 facts: 

1. Core area (Vertical line of the T model) will be decided upon the project requirements and skill set. Ex: Dev team members should be worked in .Net / MS SQL platform. Build should be tested by QA members.
2. Other areas (Horizontal line of the T model) will be decided by the Team or individual. Ex: One of the members like to learn performance testing and he/she will add as the backup for performance engineering area. Team decide member A should work on Oracle side in order to backup related areas (In this case individual can disagree with the team decision and ask for a different area).

As a team, can we just do this?

Yes but not efficient. Then, we have to come up with some statistics to adjust the gaps. In order to do so, we have to do a gap analysis about the current competences and build the resources to bridge the gap.

 

In this scenario, we can create a table as follows to see the areas that we have to fill.

Color scheme is as follows:

	Expert
	Have good experience
	Know about the area but need guidance
	Do not know anything

Now you can see how the domain, tech, DB and nonfunctional areas are distributed among the team members. Specially CS (Domain), .Net, C ++, N JS (Tech) and ST (Nonfunctional) have a huge gap. So the team lead can use this valuable data to create an action plan on how to fill this gap from existing team members and create a perfect ‘Extended Cross-functional Team’.

Hope this will help you.