App Crash! Testing around and inside the crash

In day and out, I come across testers, programmers, managers, and management having efforts on fixing all the crashes. Yes, all the crashes.  In a way I see, if the app did not crash, I will not know the areas that is not being handled well enough.  My testing focus areas will also have tasks noted in such areas to test and learn as much as possible. I do that task provided I can make/given time for it as it is unplanned task.

The common checks to handle crash!?

I learn, an exception if unhandled at runtime, it leads to crash.  There are multiple exception that app can witness which we never thought of during development.  In my initial days of testing, I was in assumption, if we can have -- null checks, index check, illegal argument check, and state check for an activity, we have handled most of the exceptions.  I learned, I'm wrong! How many checks can I write in the code.  I'm not a programmer by job.  I'm a tester. 

I see these checks are not enough and few more got added to my test strategies eventually -- race conditions, unexpected data, wrong data, environment factors, and many more. The collection of these checks is continuing to grow.  Do I cover all these possible crash inducer collections in my testing?  No, I can't and I won't have that luxury of time as well.  Technically, I will learn and prioritize what to use and when.

How the check looks in code, to me?

I write code for automation, which I need to assist my testing.  Here I did write such checks.  At a point of time, I saw, the automation code was full of checks.  Is that a right way?  Definitely not!  A professional and skilled programmer might not do that.  If a programmer has to have such check in each layers of the app architecture, will that sound good?  Personally as a tester, I will not design my tests that way.  As I'm not a programmer, I'm not aware of the pros and cons of doing so. At least I know that is not a better practice to have checks in each layer of architecture of the app.

By handling the exception in my automation code, I print stacktrace of exception.  But will I learn from it to be a better tester?  That's the question I have asked and continue to ask myself.  The exception fix I'm doing, is it stopping me from learning the problem which I have introduced by the actions I'm doing on the app? Is that exception blocking me from learning the underlying problem in my automation code and app?  If yes, then I have a fundamental problem which I have to work upon is my thought.

Why it crashes?

Why at all the app gets into crash? I learn, if the app gets into a state it was not designed for, it will and should crash. As a tester, I will have to learn this state (and such states) at the earliest when I experience crash and on reading the crash stacktrace. I will be happy and not make a fuss about it, if I see a crash for first.  

I learn what is the priority and impact of the crash?  Should I invest my time and test investigate further to provide as much as details to programmer?  Or should I report it with good enough details and continue my testing?  I will answer this question to me.  All I wish is, I don't want the user of the app to experience the crash.  If there is a crash, as a member from development team my intent is to keep it to minimal number having little or no impact.  I see the crash is a great source of learning about my work in the app.

I used to be fussy about crash years back be it on desktop applications, database, web applications and mobile apps.  Now, I have come to point, I love them and it is absolutely okay for an app to crash and it should crash.  What I do post crash in fixing, that tells the bigger story.  In my work, the crashes have made the app better because the team was serious about those crashes.

What on having the crash?

Should the user lose the data what she or he entered on experiencing the crash?  I personally, don't want this to happen for me.  If it happens, I will be annoyed!  That said, how to handle it?  That's something we will have to sit with the programmers and team, for discussion.  

At what point in app, encountering the crash, should we close the app and start over again. At what point in app, it is okay to note the crash and pull the stacktrace, and let continue the user using the app with data entered intact. At what point in app, I should not show UI in view on entering crash and what to show, then resume over safely from there on.  Personally I feel this is a team effort and not just a programmer's effort in making it happen.  

Few testing strategies hack to uncover crash

Here are few things I do and I ask my fellow testers to do when testing mobile apps:

1. Using the test data which will check the data integrity in app at -- entry point, during processing and post processing.
2. Identifying the states of the app and passing the invalid states in app at -- entry point, during processing and post processing.
3. Identify the input which is not from a tester and user. Classify the input on which I don't have control. For example -- the incoming intent; the app responding to APIs (default values, entered values and processed values); the app receiving the response from APIs; the device state; app's activity life cycle state and data/state exchange, and many more as this.
4. Depending on Android or iOS app, much more strategies can be narrowed down to be specific and work.  At the end, what time I'm left with in the test cycle and what do business want, directs me on what to do.

Debugging and Investigation skills

There are libraries which collects the crash on exception along with other details as -- device info, user info and network info.  I have been with programmers and had difficulty in reproducing the crash and experience it in development environment.  This said, are the logs enough to fix crash?  May be, so we handle the exception and continue the flow of app in runtime.  But did we solve the root problem that caused the crash?  No!  This is where, I feel, the skill of a tester comes in and it is very much needed.

This skill defines me what I'm as a tester and value I bring to the system.

When My Team Member was Fired, I Could Not Accept My Salary Hike

In one of my job, I was assisting people who had started their career in Software Testing and few others who were into Software Testing for a while.  Before going further, let me say what I have experienced being with people. 

Through my childhood, I have come across people who are from different backgrounds, economy status, habitat, culture, abilities, and personal personalities.  I see all are special and good in what and how they are.  Where they came from have the influence in how they interact, respond and get going.  Anything can get better if there is a will in the journey is what I'm witnessing.  With this learning of me, I could easily learn how I should interact with a person, on listening to her/him for some time. I just tune up or tune down to the frequency of them, and get it going smoothly.  Once we have a better understanding of common objectives, the credible rapport for each others and mutual understanding on communication we have built, we will take it forward. This works! It is working for me.

I have worked with people and nation whose language is not the English and have difficulty in communication (spoken, written and understanding) using the English. The lack of English communication has not stopped from doing the brilliant job. I can say it standing anywhere and to anyone, anytime!

I, myself have difficulty with the English. I'm said -- you are bad in English; I was made fun for my English; I was taken to extent by saying -- I will tell how you are and who you are to whole world for what I wrote and what I did in my practice.  I'm okay with that!  I continued observing and I saw where can I get better in which I have control.  I use the English words and grammar, which I'm aware of and I continue to learn.  I have a pride in it as I see my efforts are consistent and I see result.  If you are understanding what I'm writing here and what I want to express, isn't that appreciable?

Few might say, what would the English speaking people say on hearing, reading and listening to this English.  Fair! But, that should not make me or anyone to be small and worthless, and it will not make.  I say, who have that thought, are just too narrow in seeing the perspectives and differences of social culture, yes of course in appreciating it as well.

Coming back to the current blog post title line, one of my fellow team member was asked to leave job because that person's English was not good.  I was said, enough chances were given for that person and no improvement in English and communication, so the decision.  I sometime, got the thought is this a English learning school?  I felt, that person's English was okay to communicate but the actual problem was, that person is not opening up to speak with particular person and few others. That person did talk with me and to other teams, openly.  If one have cleared a Under Graduate Degree of an University by writing the exams in the English, it tells, there is something else, the problem is not the English speaking or writing.  There is a barrier for that person which has to be broken, and it has to be broken from both ends. It can take time, and it will happen one fine day.

We talk of traps and we will fall into traps because we are managers and not the leaders most times in our roles, thoughts, stands and work.  The leaders too fall in trap, but a leader will be a problem solver and can see the trap and act upon it.  For a manager who wants to do the things right, it can be a tough one to handle. To a leader who wants to have the right things, can remove the blockers and solve though it is tough one.

I don't stick on to say whether it was right or wrong for asking that person to leave the job saying the English or not speaking up.  At the end, it is one of kind of personality among several other personalities of human beings.  Also I feel, that slowness in opening up to speak and get going is not okay in the business world.  The push had to come from both ends, but it did not.  The management went ahead without seeking what a leader of that team thinks about this problem.  Not sure if the manager knew what was the problem here with that person.  Or may be the manager was not considered at all by the upper management in that decision.

Soon, one day, I was called to collect my hike letter.  I was not blank here.  I said, I don't deserve this hike. I was asked why so.  I said, "One of my team member was asked to leave job. I was mentoring and assisting that person. It was said no improvement in that person while I could see the good progress.  If management does not see the progress in that person, then I have a relation to it.  I have not progressed in one my roles and responsibilities better.  I have not done my job well with that person who lost the job. I have lost a team member who could have been an asset to organization."   I thanked the management in the room and I asked if I can leave and walked back to my desk.  I don't know what impression it gave to people in the management on me.  I was clear in my decision.  I believe, I'm a leader and I stand for it when I lead me or my team. I will be a voice for them and for the job we do in solving the testing problems.

Though my financial condition was not good, I strongly moved with that decision. I feel happy about how I have responded to it and took the accountability not just responsibility being a leader.  Few months later, being out of job that person continued the software testing practice; won the 1st place in a testing competition that is open to the testers across globe and have testers participating from several countries. Please don't take it as, that person won 1st place because I was assisting in practice; no; I don't claim it that way in any means. That person practices and has skills, so the win.  That person is not into the Software Testing career, today. 

I led that person by assisting the practice of a fresher.  A fresher losing the job for no progress in my leadership, is my failure. I have a leader in me who resonates in pride for that decision of not accepting the hike, with humble respect to the management.  I was not just responsible being a leader, I was accountable for them in that role, that day.

Closing Notes:

• People are not same; different people have different personalities.
• All problems are not same; different problems have different complexities, patterns, and personalities.
• For an organization, it is very important to have management and leadership go in parallel knowing what has to be accomplished.
• The Management and Leadership are assumed and seen to be the one and same; no they are not.
• Manager act and moves in ownership of "I'm responsible". Leader steers and drives in the ownership of "I'm responsible and accountable".  It is easy to look as being accountable and not just responsible for all of us in what we do and deliver either as individually or as a team. No the reality is, it is apparent, when the deck opens up for accountability; that is when we see categories forming for the  'responsible' and 'accountable' in the team and organization.  If felt, accountable, you will have the voice and it can be heard on the floor.  Where as when just responsible, still you will have voice and it is heard on the floor, but not as the voice that stands out on the floor in crowd.
• Management team can have a good leader while being a manager. Likewise a leadership can have a good manager while being a leader.
• Management and Leadership are two sides of an eye. Which side of an eye is visible to your people and to you, will tell about the influences on your people from you.
• Most managers, to-become managers, just-promoted-as-manager and the management in an organization -- all of them learns the management from the environment where they come from and from their managers who managed them. Now you know what example you are setting by leading.
• A leader can go unnoticed most times because a leader creates a system which is not dependent on her or him at any time.
• Stand for your team and people, assist in the possible ways.
• Don't be a shield of defense being a leader to team; let team face the music. Drop in and assist when and where it is needed, and let the team swing to music while you lead them.
• As a leader, help your team to be relevant, to be aware, and to be open.
• As a leader, communicate upon knowing what's the frequency on the other side; get down and pull up the frequency than shutting down the channel.
• In software industry, the engineers take up the management role these days. The engineers who got promoted to management, might not have the idea of management and leadership. It takes practice and skills of the management and leadership to be a manager and a leader. Think back, how much it has taken for an engineer to be a skilled engineer over the time in gaining those engineering skills.  None were that effective in the engineering skills right immediately passing out of the engineering college or the university.
• The management can fail to see the progress; change/progress happening in the practice and changes on the floors.  The leadership team has to enable and assist the management teams in learning to communicate, assess, and respond. 
• Leaders, you need both managers and leaders to move in any directions. Managers are good at certain things and so the leaders.  Both are needed for an organization.  Don't just have environment that creates the managers with no leader in them. Have the environment that incubates, fosters and supports the growing of upcoming Leaders.

Challenges in Building the Skilled Software Testing Team and Testing Leadership

In testers meet, I was asked, "I happen to see overlooking the value of building the testing team and contributions team make to shipment. Do you see same in your work? How to solve it?"

Before I went ahead to discuss on this, I had silent in me.  I see certain problems are in the culture and mindset for first.  Bringing a change here is not that easy - culture and mindset. It also applies to testing teams. It also holds good to any others (or teams) interacting with the testing team.

Taking the analogy of skilled carpentry work (say, "pepperfry") - we will see how this exists not just in testing but anywhere. But in testing, it is not changing after decades too. That's the problem causing unbearable costs and not the actual problem. It's not being attempted to understand by who needs the testing, in my opinion for today.

A skilled and experienced carpenter can do her/his work quickly and with values, right? How many carpenters exist today who can do job at least to level of saying this is the minimal must value and job, I need without the supervision and initial assistance from skilled carpenters.  If seen, the assistance in carpentry work is not for weeks or months.  It takes longer time depending on the skills, mindset, passion and attitude of person learning the carpentry.  Now comes the context - there is a list of orders coming in; the skilled carpenter has people who started carpentry and the people who can do job on consistent supervision for 'x' period of time. If the skilled carpenter puts her/his time in doing the work day in-out to deliver the orders alone, may be orders delivery will be met but with diminished values in work eventually? How long the skilled carpenter can do this i.e. all alone? The skilled carpenter should not assist her/his fellow carpenters and help herself/himself or people who will be hiring them for job?  I learn, the skilled carpenter will assist and give her/his more time in closely watching her/his fellow carpenters while chipping out the core part of the orders.  What if the fellow carpenters quit and join elsewhere? That cannot be stopped by any means. Due to people quitting does one has to lower the standards of one's work? Do the furniture brands say we lower our standards of product as we find carpenters quitting the job? NO!

Relate the same to Software Testing and Automation.  Including me, we have people in software testing -- who knows jargons; who knows how to use what they know in shallow or not know at all; and starters. Here we will have serious people who are interested and also not interested.  Considering the current time (future as well hopefully) of people or team who needs the testing team, isn't that a skilled tester job to build a team on which they can sustain and rely in coming days?

This long activity i.e. building of testing team can take years. And in my experience when had a people with right attitude, consistent efforts and passion - it can take close to 2 to 2.5 years for one.  In these 2 to 2.5 years, we can see people tackling the testing problems if practiced well. But people do change job in 2 years or so, now should I invest in it?  This is one of the invest-cost-value problems which has made Software Testing to take back seat.

It has gone to least priority when considering of having the skilled testers and testing team. Because, practicing testing is not done by most. Later saying this is testing to people boarding the team/org do this and getting the lower returns and values for team & org. Eventually blame the testing and testers. One simple example, we are aware of Design Patterns in programming and know several books/authors who has authored.  Do we know the Test Designs and design techniques apart from black box, white box, grey box, and any books or authors who have authored on same? Blinking of brain starts here!  I feel there is no need of better example than this.

Everyone has experience but that does not mean they are practitioners.  This is the trouble with people boarding into practice of testing. They happen to hear and work upon hearing - just do this, like this, this much, and as this. Write your test cases, automate all, bug reports and everything here. If that can be said in ease, it can be done in much more ease. Why hiring of the testers and having testing team?  Now you know the trouble and pain points of building the testing team and testers?

The expectation from the skilled (carpenter) tester is X+1, but the people who gave the job/orders see it is y-X and not far close to X.  This is the exact case with people or team hiring the testers and wanting to see the "proportional" value right away in the product and to the organization.  It can be achieved, if considered just the skilled (carpenter) tester and for a shorter period of time. But is that the expectation of people who pay for the all carpenters (testers) doing the job in a business?

To see the value of a test, it can happen in a release or few releases. To see the value of testing being done or not done, it can take few releases.  To see the value of having the skilled testing and their work, on which people rely, it will take years.  I see same applies to programming team as well. But in programming space we have people who practices it and then assist boarding people.

In the testing space, we don't have practicing people to assist the boarding people and existing people, in the right way.  This contributes to laggard and continue giving a low mark to the testing team and testers.

Now is it -- problem of the industry; problem of the org; problem of the people or teams wanting to have testing teams; problem of the testers itself?  Whatever, the impacted entities are -- industry, people or team who want to have skilled team and of course testers too.  Help the testers, testing teams and testing practices you have in your org. By this, you are investing. When investing know if it is done in a right way and on right stuffs. Otherwise, the investment made today in testing can become blocker cost.

If a skilled (carpenter) tester is working on building the future carpenters by giving her/his assistance, it is not a simple job! That's the bigger value. Doesn’t the business find returns one day out of this assistance? I say it is not simple job.

The skilled (tester) carpenter knows that he/she is not doing in full what she/he has to do in a given context while continuing to assist other carpenter.  But negotiate in open mind with stakeholders by bringing the understandable and mutually agreeing communication - what is expected immediately out of carpentry work given or the orders that came in.  If this is done, half-the-problem is solved when you have skilled testers.  Often, this will not happen and skilled tester too fail here. 

The communication of expectation for a carpentry work coming from different people; to whom should the carpenter look upon and deliver the asked delivering the work?  We testers and testing team have this problem as well in getting our work set and delivered.

How to solve?

1.   It needs a leadership in testing at org and in teams.  The test leadership, if they are testing practitioners it is good and boon. But hands-on practitioners might find time constraint to be in management and hands-on delivery. Yet this is do-able in my experience.

2.      Testers need to pull up themselves and bring the change in-out.

3.     Culture and mindset problem, needs better way of solving and not the software testing way i.e. how software testing solves problems.  Unless having the faith in software testing and how it solves the problem, it cannot be used as a relativity in learning to learn and solve the problems.

4.   At the bottom, skilled practitioners will be on the hit list most times. Unavoidable! But that should not put down the Software Testing community and practitioners growing. One day you will be recognized, remembered and highly valued for what you have done.  Just make sure you don’t incur big costs personally by doing this activity. Balancing is the key here and it comes only by incurring the costs while doing this activity

If not bothered about

·        need to transform into skilled testing practitioners;

·        org not having/wanting the efficient testing teams;

·    continuing the shallow and low returns testing & automation, which is highly accepted, paid better for doing that and you don’t care a penny anymore about it,

then do not attempt solving this problem for you, your team, and your org. It will never be solved. It will just increase the troubles to all.  One day it will be realized and it will be picked to solve by stakeholders upon having the costs.

Note: I admire how the "pepperfry" crafts its furniture. I wonder why the same cannot be achieved by carpenters who do carpentry while constructing the house. I'm left with many thoughts on this and I try in discussing them with a tester in me.